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

[Anil Saldhana]

I created this dashboard to track all the security related discussions 
with AS8++
https://community.jboss.org/wiki/JBossAS8SecurityDashboard


On 03/01/2013 05:22 AM, Darran Lofthouse wrote:
> (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.
> _____________________