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