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
>>