Hi,
I am preparing a revised Id Store proposal to incorporate these latest
ideas.
Regards,
Alex
On 6/24/15 9:08 AM, arjan tijms wrote:
> Hi,
>
> On Wed, Jun 24, 2015 at 3:02 PM, Pedro Igor Silva<psilva_at_redhat.com> wrote:
>> What you described in "Alternative" looks fine to me. I think we are starting to define a baseline for further discussions about the Identity Store and other aspects related with IdM ...
> Great :) I think we're slowly getting there. Still a lot of details to
> decide about regarding the actual names of everything and such, but
> the broad lines are getting clearer. Thanks!
>
> Kind regards,
> Arjan
>
>
>
>> Kind regards.
>> Pedro Igor
>>
>> ----- Original Message -----
>>> From: "arjan tijms"<arjan.tijms_at_gmail.com>
>>> To: jsr375-experts_at_javaee-security-spec.java.net
>>> Cc: "Alex Kosowski"<alex.kosowski_at_oracle.com>
>>> Sent: Monday, June 22, 2015 12:45:01 PM
>>> Subject: [jsr375-experts] Re: Identity Store Proposal 2.0
>>>
>>> Hi,
>>>
>>> On Mon, Jun 22, 2015 at 4:02 PM, Pedro Igor Silva<psilva_at_redhat.com> wrote:
>>>
>>>> I think the size can be explained or even justified based on the different
>>>> requirements that we are considering in our proposals. Yours is basically
>>>> providing an authentication method and another to load roles. Where Alex
>>>> and mine is providing more capabilities. Maybe we should align these
>>>> requirements first ?
>>> Likely part of it is requirements, part of it is architecture.
>>>
>>> My view point on these concerns:
>>>
>>> Architecture:
>>>
>>> 1. Individual small orthogonal pieces vs a larger more capable piece
>>>
>>> As an example of this concern, let's consider JACC.
>>>
>>> Although at its core JACC is a very clever and useful system, it's
>>> (IMHO) hampered by the fact that some of the *required* interfaces are
>>> very "capable", e.g. PolicyConfiguration
>>> (https://docs.oracle.com/javaee/7/api/javax/security/jacc/PolicyConfiguration.html)
>>> does several distinct things:
>>>
>>> 1. A state machine that controls the life-cyle of this permission collector
>>> 2. Linking permissions of multiple modules and utilities
>>> 3. Collecting and managing permissions
>>> 4. Processing permissions after collecting
>>>
>>> (see
>>> http://arjan-tijms.omnifaces.org/2015/03/java-ee-authorization-jacc-revisited.html)
>>>
>>> In a lot of cases you only want to do item 4 on that list. Sometimes
>>> you may want to do either 1. or 3. But the size of the interface
>>> forces you to implement everything, which is often (I'd say almost
>>> always) just too much.
>>>
>>>
>>> Requirements:
>>>
>>> 1. Letting the authentication system (the container) input credentials
>>> and get back username/roles.
>>>
>>> This is IMHO the primary requirement. If you only have this, then you
>>> can let the user provide a custom identity store. Although this is
>>> very basic, it's currently missing in Java EE. Users have to reside to
>>> proprietary methods here when using the container's standard
>>> authentication mechanisms (FORM, BASIC, etc).
>>>
>>> 2. Letting the user create a custom identity store with a minimal
>>> amount of effort (easy of use)
>>>
>>> Only second to the actual functionality is the fact that above all it
>>> has to be simple. After all, we can actually today do everything we
>>> want using JASPIC and JACC directly, but those are not friendly APIs
>>> for application developers to use (especially beginning users). Maybe
>>> we have a different opinion here ;) My assertion is that having two
>>> variants of getCaller, in addition to two variants of getRoles, in
>>> addition to two variants of hasRole in addition to a getGroups and a
>>> getMember as well as a getPermissions is just way too much to ask a
>>> user to implement.
>>>
>>> 3. Standardize existing implementations (easy to implement)
>>>
>>> Every known container has its own mechanism for an identity store,
>>> where all of them implement the same {credential -> username/roles}
>>> function. A lot of them do exactly this and nothing more, some do a
>>> little more.
>>>
>>> If we want all existing containers to implement our standard identity
>>> store interface, then it's a very big advantage if this identity store
>>> does what all containers and their myriad of existing identity store
>>> implementations are already doing.
>>>
>>> 4. Standardize group to role mapping
>>>
>>> The requirement here, IMHO, is to have the option to map groups (in
>>> the meaning of external roles) if a given identity store is used for
>>> multiple applications to roles that are local for the application.
>>>
>>> Here it's almost always the case that a group to role mapper is
>>> separate from the identity store. When group to role mapping is needed
>>> the identity store is general, while the mapper is application
>>> specific. So while the requirement "standardize group to role mapping"
>>> is the same, I don't think it should be a part of the identity store.
>>>
>>> 5. Hierarchical roles (permissions)
>>>
>>> The problem here is that roles even though nothing in Java EE mandates
>>> this, are too often thought to be limited to being things like
>>> "manager" and not "can_access_accounts". So the requirements is to
>>> have an explicit construct that subdivides a "role" into smaller
>>> things, where those smaller things are not rarely called
>>> "permissions".
>>>
>>> I think the requirement itself is pretty much aligned here, but here
>>> too I think this should not be a function of the core identity store.
>>> Like group to role mapping, role to permission mapping is often
>>> application specific (in fact, web.xml is the most famous example, see
>>> http://arjan-tijms.omnifaces.org/2015/04/how-java-ee-translates-webxml.html).
>>>
>>>
>>> Alternative:
>>>
>>> Instead of having a single big identity store as a core requirement,
>>> having multiple smaller pieces with possibly a convenience single
>>> point of entry facade would likely accomplish pretty much the same
>>> thing.
>>>
>>> I'm thinking about:
>>>
>>> 1. Identity Store
>>> 2. Group to Role Mapper
>>> 3. Role to Permissions Mapper
>>> 4. (Optional) ReadWrite (CRUD) extended Identity Store
>>>
>>> As a convenience, a facade might combine those. I'm not entirely
>>> convinced this is needed, but it might be a compromise. The default
>>> facade would then be injected with- or lookup the constituent parts
>>> (via CDI), and a user could by using the default @Alternative
>>> mechanism from CDI replace one or more of these parts, and
>>> alternatively even the whole facade.
>>>
>>> In true divide and conquer fashion we'd best look at each part
>>> individually first, and then when each of those parts have been
>>> separately discussed and API for them proposed take a look at whether
>>> it makes sense to combine them.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>