[jboss-as7-dev] On security context and propagation

[Darran Lofthouse]

(Sorry this has turned into a longer reply but after reading the thread 
I am only replying once ;-) )

>> For JAAS I am not condoning using it beyond its capabilities, but with
>> (for example) EJB remote auth, the API would end up looking really a lot
>> like LoginContext anyway from our design discussions in Brno.  If the
>> API fits, might as well use it.

Yes when you look at the JAAS API it is a client side API and not a 
server side API - this is easily seen as a CallbakHandler is passed in 
to the LoginContext and then LoginModules to allow Callbacks to be 
passed back for interaction with the client.

Within AS what we currently have is a wrapper around this client API for 
use within a server - when dealing with a limited set of simple use 
cases to be fair this wrapper worked well.  However once you start to 
try and move beyond this you quickly hit the limits and end up with 
workaround after workaround.

If however we are talking about using the JAAS API client side for the 
purpose of obtaining the tokens we were talking about with the new 
authentication service and having available a populated Subject that we 
can use with a doAs to specify the user a request should be run as 
subsequently then yes I would say the API is a very good fit.

As an example we currently use the Krb5LoginModule with a JAAS 
LoginContext to obtain a Kerberos token, when we need to perform tasks 
as that user we make use of the populated Subject with a doAs - 
potentially we can have multiple tokens by having multiple populated 
Subjects and switch between them by choosing whichever one is most 
appropriate.

So for the authentication service providing a LoginModule on the client 
side could make a lot of sense, combined with CallbackHandlers and a bit 
of configuration this same implementation would be compatible with the 
fully authenticated switching of identities and also switching based on 
trust.

To continue on that slightly I know it has been raised elsewhere on this 
thread but as I am replying here.  I don't think anyone is now 
advocating propagating a full Subject from server to server and I agree 
- the safer option is for the client side of a call to request that the 
server side of a call runs the request as a specific user, a trust 
decision is made to see if that is allowed and then the identity of the 
run as user is loaded server side - so no sneaking in additional roles ;-)

This architecture would also be suitable for authentication mechanisms 
that have support for identity propagation built in e.g. using this we 
could do client to server to server and propagate a Kerberos identity 
along the whole call chain.

> To hell with JAAS.  Deprecate and eliminate that junk.
>
> Again, LoginModules are stateless and have no component injection model
> and there's no way to cache, lookup, or initialize global state other
> than static variables.
>
> Take a look at how we implement JDBC or LDAP LoginModule.  There is no
> caching done, so each and every time you execute these it results in a
> database or LDAP remote invocation.  Not very scalable for something
> like Basic Auth, or even EJB that re-auths every request.  So...then you
> have the AuthenticationManager which was layered on top of JAAS so it
> can cache verified credentials.  Great for username and password.  But
> what about something as simple as OTP where it is impossible to cache
> and re-verify the credential as its different every time?

Yes this is exactly why using JAAS server side has reached it's limit. 
Everything is based around the assumption that we have a static 
username/credential pair that is the same for every request which is not 
true for many authentication mechanisms.

Switching to an IDM based approached it will be the IDM's responsibility 
to cache interaction with the remote store instead of the current 
approach of caching successful authentication attempts - that way 
authentication can occur per request without necessarily having to hit 
the store for each request.

> What about multi-challenge protocols that Darren wants to implement?  Or
> protocols you'll need to hold state in between requests, like OAuth?
> JAAS is totally useless here.  Just give me a reference to the Identity
> Store and a filter/interceptor model at my protocol layer.  JAAS just
> gets in the way.  It sucks.  Deprecate it. Banish it to hell.

Server side I don't think anyone is currently advocating JAAS and 
neither am I ;-)

However a JAAS LoginModule client side combined with a CallbackHandler I 
think would be suited to multi-challenge authentication protocols for 
the purpose of something along the lines of an authentication service we 
previously discussed for switching identities for remote calls.

>

For the rest of this discussion using JAAS server side it not a 
pre-requisite to being able to use a Subject - in fact even the current 
domain management realms sparsely populate a Subject today without using 
JAAS.

So for entry to the server making use of HTTP and SASL based 
authentication backed by an IDM instead of JAAS and then converting the 
loaded identity into a Subject does sound good.

One point to keep in mind that is different from the JAAS population of 
Subjects however is that the IDM approach is not currently expecting to 
load roles pro-actively for an identity, instead it is expecting to 
respond to isCallerInRole type checks as and when role checks are 
required.  Applications however do have a finite set of roles used so 
there are options here.

Regards,
Darran Lofthouse.