[jboss-as7-dev] security APIs/SPIs really need a redesign

[David M. Lloyd]

On 09/22/2011 04:23 PM, Bill Burke wrote:
> I'll try to write a blog about this too, but, the security APIs/SPIs
> really need a rethink. [snip]

Not going to repeat, this is good stuff though.  Jumping right into it...

> #1 I suggest defining a Security Storage SPI.

YES.

> Something that is key/value/values based that is listable. i.e. something like:

Not sure about this exact implementation.  There are two angles to the 
problem.

First, there's management.  I think there is a desperate need to provide 
a user (or generic principal) management database which can be 
administered via the console or other mgmt API - users added/deleted, 
rights granted/removed, etc.  This includes the listing users requirement.

Second there's the API consumer.  As you point out, many authentication 
schemes require this kind of first-class access to the authentication 
database.  Anything challenge-response, for example; this includes 
anything using SASL (which in turn includes LDAP servers and Remoting, 
not to mention most modern TCP-based internet protocols).  Images, 
biometrics?, other stuff like that.

The catch is, these two aspects don't always overlap.  It may not be 
possible to manage all types of user store.  In particular AS might be a 
client for a specific authentication model (like PAM for example) 
without the ability to actually administer it in any way, even basic 
stuff like listing users.

So such an API needs two aspects - one which exists to perform the bare 
task of authentication, and one which provides all the management 
goodies that the particular store implementation can make available.

Some other significant factors - many authentication protocols 
(including Remoting's, it is turning out) are realm-based or are to the 
point where even the mechanism selection can depend on the realm or user 
name the user is attempting to authenticate to.  You hinted at this 
problem when you mentioned traditional auth. vs. OAuth, though in the 
web case, I believe the user presents the desired mechanism before 
trying to authenticate.  I recall that RADIUS authentication also falls 
into this category.

For example, imagine a mixed user-password database where some passwords 
are clear and some are one-way hashed.  Challenge-response password 
protocols generally require access to a clear password, so the 
authenticating server would have to find the user entry before 
determining whether a challenge-response authentication can proceed.

> #2  Deprecate JAAS and write our own SPIs/APIs.

I think JAAS still has a certain place - but that place has nothing to 
do with network authentication.  It still makes sense for example to 
authenticate to a Subject for example - it's already fully integrated 
into the Java Security Architecture so it doesn't behoove anyone to try 
and replicate this.

That said JAAS authentication should be restricted to cases where it 
really makes sense - where you want to authenticate as a new Principal 
in the context of an already-running thread on a local server (i.e. not 
over the network).

> #3 Decide where authentication happens.  Does it happen within a Tomcat
> Valve and persistent security information queried directly from the
> SecurityStore?  Do we have a Security domain and delegate to it for
> authentication? (In this case, the Security-Domain would need access to
> the request object).  I think I prefer a full delegation to a
> SecurityDomain as storage, the authentication mechanism, and
> configuration of the authentication mechanism pretty much go hand in hand.

The difficulty is that (depending on the implementation of the security 
store), choosing the store might depend on the requested mechanism or 
identity; or, choosing the mechanism might depend on the requested 
identity (and thus the corresponding security store)...

> #4 We need to make it fairly easy to develop security extensions.

That'd be nice.

> #5 Try to support legacy deployment options with the new model.

Seems doable.

> #6 Going along with #3, I really like the idea of adding a<auth-method>
> of JBOSS, or JBOSS-SECURITY-DOMAIN, so that authentication is handling
> fully by a JBoss subsystem.

Can you elaborate?

-- 
- DML