Hi Arjan,
I’m absolutely with you - +1 to all your points.
I would start with a “god facade” (easier to implement) and after it works I would split it into smaller parts with good names.
cheers,
adam
> On 22.06.2015, at 17:45, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> 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