After a rather hectic end to last year have finally managed to get back
into reviewing mode ;-)
Within the WildFly Elytron project we are currently working to replace
the use of JAAS as the default 'identity store' equivalent with the
server and putting in a new API/SPI that can be used by authentication
mechanisms to validate requests. One of our biggest motivations to do
this is to move away from the concept of having an incoming credential
that can be validated - one thing we realise is that once you move
beyond simple username / password based authentication you quickly move
into the realm of validating responses to challenges - or to put this
another way there is no longer a credential exchanged that can be validated.
In the previous JAAS based approaches all requests would result in a
'credential' being passed to a JAAS login module to authenticate - over
time this ends up becoming quite a mess, items that are not credentials
end up being wrapped as though they are, HTTP or SASL mechanisms
specifics leak into your login module, conversational challenge /
response mechansisms become complex, caching solutions that assume a
principal and credential can be paired quickly break down.
The result of these experiences means that we have now found it
necessary to move to an architecture where we consider the
authentication mechanism having the responsibility to make the
authentication decision. Our new equivalent of the identity store is
now nothing more than a store - it is there so that authentication
mechanisms can query it to access information required to make their
decisions.
To complicate matters further some store implementations will only have
very limited access to the underlying store so what they can offer will
be limited.
Naming wise our identity store equivalent is currently called a
'SecurityRealm': -
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/auth/server/SecurityRealm.java
From the security realm it is possible to obtain an identity from that
store: -
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/auth/server/RealmIdentity.java
This gives us two different modes of operation that can be used with
authentication mechanisms, for mechanisms like Digest and SCRAM the
required representations of the users credential can be obtained and
used by the mechanism in it's decision making process. These mechanisms
are both conversational exchanging information with the remote party
that is authenticating - as an example Digest authentication can fail
because the nonce is not valid - however the response message indicates
if it would have succeeded had the client used an up to date nonce.
At the same time as I said above we have store implementations that
can't retrieve the required information and also there are some
mechanisms where delegating verification does make sense so we also have
a verifyEvidence method - by referring to it as evidence we are not
pretending it is a credential, but at the same time some evidence types
can be verified against credentials automatically if they can be obtained.
So in summary what we have discovered is that the verifyX approach to
authentication is only a clean fit with a subset of authentication
mechanisms, the ability to obtain information needed by some mechanisms
is only possible with a subset of possible store implementations. You
do end up in a situation where the combination of authentication
mechanisms in use need to be compatible with the capabilities of the
underlying store.
To close the loop with the authentication mechanism now taking on
responsibility for authentication decisions we then have an event
framework to allow for the decision to be passed back to the realm: -
https://github.com/wildfly-security/wildfly-elytron/tree/master/src/main/java/org/wildfly/security/auth/server/event
The next area that we have been trying to move onto is the separation of
the concept of the authenticated identity and the subsequent view of
that identity once in use within the context of a deployment. In EE
terms roles can be very specific to the deployment with different
deployments potentially having very different roles - it is also
possible that a call can propagate from deployment to deployment so the
same identity could be used in multiple places. We do have a later task
to work on Role/Permission assignment so I would suggest that roles
should possibly be left out of any identity store for the moment.
Within the Elytron effort we also started down the path of assuming a
separation between the groups loaded from the identity store and then
mapping to roles later, one thing we realised that may be worth
considering here is that we could take that one step further and our
initial identity after authentication can be represented as having
attributes instead of groups: -
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/authz/AuthorizationIdentity.java
An attribute can be used to represent group membership information from
the underlying store but at the same time other information can be
represented here to be taken into account for role mapping without
artificially pretending it is a group - as an example we could use an
attribute to hold an identities department as loaded from LDAP or maybe
their country or office location and use that to assign roles and
permissions.
So in general I think within WildFly Elytron we are going above and
beyond the scope of this JSR as we are putting in place a new generic
security framework of APIs and SPIs for use in the application server
whether it is being used for JEE or something else - however the biggest
lesson we have learned ourselves developing APIs and SPIs in this area
is that they need to be validated against the complex authentication
mechanisms - addressing plain text password validation first without the
other mechanisms we have found risks making it very hard to
retrospectively support those stronger mechanisms.
Regards,
Darran Lofthouse.