6:30 p.m.
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