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