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

[Anil Saldhana]

On 02/28/2013 06:30 PM, Bill Burke wrote:
>
> On 2/28/2013 5:53 PM, David M. Lloyd wrote:
>> I think it's fair to say that a security token could be counted as a
>> "credential".  That's what I was envisioning for EJB remote invocation
>> in any case.  As long as the credential type is public you can easily
>> access them using the typed get*Credentials() methods on Subject; same
>> for typed Principals.It seems to me that roles could just as well be
>> Principals as well (in fact I think they are already modeled this way,
>> at least in some places), and so if they're mapped on to the Subject and
>> we use Subject.doAs to implement run-as, then isCallerInRole could be as
>> easy as Subject.getPrincipals().contians(xx) - though I would have to
>> read the code again to ensure that there aren't any security issues
>> there (shouldn't be as long as the Subject is read-only).
>>
> A security token is a credential, but it may have permission and role
> mappings within it.  Server receives the bearer token, verifies the
> signature, creates a Principal from the identity stored in the token,
> extracts role mappings from the token and associates it with the
> Subject.  The role mapping association is the API I'm talking about.
> (BTW, this type of protocol allows services to not have to ping a
> central auth server.  All they need is a public key to verify signatures)
>
> Then you have the case of propagation.  Lets say you have an RMI EJB
> invocation that needs to communicate securely with a RESTful service
> that uses this smart bearer token protocol.  Then you'll have to create
> a smart token with identity and permission and role mapping metadata
> that's stored within the Subject.
>
> BTW, I was wrong, this API does exist in the Picketlink Security Context
> (its just hidden and made useless by all the shit layers in JBossWeb).
>
> SecurityContexxt.getUtil();
> org.jboss.security.SecurityContextUtil
>
> Whether or not you want to re-use what exists in Picketlink is
> orthogonal, but I personally need an API like SecurityContextUtil.
> Anybody doing their own custom security will probably want this API as well.
SecurityContext was supposed to be our primary API. I just put all the 
extra methods operating
on the SC inside an util class.

What Bill is referring to is here:
http://anonsvn.jboss.org/repos/picketbox/trunk/security-spi/spi/src/main/java/org/jboss/security/SecurityContext.java
http://anonsvn.jboss.org/repos/picketbox/trunk/security-spi/spi/src/main/java/org/jboss/security/SecurityContextUtil.java

>
>> 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.
>>
> 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?
>
> 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.
>
The plan is to deprecate JAAS in AS8+  and bring in an IDM driven 
authentication if possible.