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

[Bill Burke]

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.

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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com