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

(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. _____________________