I created this dashboard to track all the security related discussions
On 03/01/2013 05:22 AM, Darran Lofthouse wrote:
(Sorry this has turned into a longer reply but after reading the
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
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
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
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.