Wow, I can't believe how difficult and messy this is.
As I see it, there are three authentication mechanisms that are sort of
"out there" in the enterprise Java world today. By authentication
mechanism, I mean API calls that you are supposed to be able to use to
determine who or what is calling your program.
(First, you have the security APIs in Java. I'm not interested in
these; these provide restrictions based on where the calling code came
from, not on who is *running* that code.)
So, first, you have the EJB access control system. A principal is the
fundamental unit--it's a standin, or a synonym, for a user's identity.
No claim is made at the EJB level about how many principals a user may
have, or if that's even a meaningful question. A principal may play
many roles. Declarative access control is placed on roles and methods.
Consequently, the only two calls that are available inside a bean, for
non-declarative access control, are: isCallerInRole(), which is a way of
testing whether the calling Principal is playing a specific role, and
getCallerPrincipal() which is a way of getting the principal itself so
you can do various tests on the user it represents or is synonymous
with.
Next, you have the servlet 2.2 access control system, which is virtually
identical in its API to the EJB system. Unfortunately, nothing except
Tomcat seems to support this API. The servlet 2.2 API has the same two
API calls, and, from a discussion I had earlier, apparently has some
other mechanism which I've been unable to track down for conveying
authentication information to the servlet container. No idea how you do
this, but apparently it's supposed to be possible. Again, nothing here
says explicitly that a Principal is synonymous with a user, or says that
a user may have many principals, or whether the relationship is one to
one.
Finally, we have the JAAS, which is the only one of these things that
appears to get it right, IMHO. You have a Subject which has many
Principals, each of which represents the process of authentication
having taken place. To put it another way, if you ever encounter a
Subject that has PrincipalX, then you know that the Subject passed the
authentication that was required to get PrincipalX. There is no mention
of roles in JAAS.
This all smells like two different camps went off and tried to design
authentication architectures without talking to one another.
That is, an EJB Principal is like a JAAS Subject, and an EJB Role is
like a JAAS Principal. In theory, JAAS is supposed to be The One That
Will Eventually Win. Can someone from Sun explain how EJB is designed
(or will be designed) to work with JAAS in the future?
Also, any code examples (I'm starving for 'em, folks) on how to do
single sign-on in a servlet 2.1 environment all the way down to the EJB
layer are heartily encouraged. I'm beginning to think this
rock-stupidly-simple problem is one that I'm the first to face, ever.
Cheers,
Laird
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
