> (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.)
Actually it's also dealing with whom is running the code (1.3 adds
that), but it applies to applications, not application servers. In the
J2EE model the application has not permissions, everything is role
based.
> 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.
Precisely. And the same for Servlets, just different API names.
>
> 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.
A user may have multiple principals, a principal is synonymous to who's
running on behalf of that user. So -- it gets more hairy -- the same
user can have three different principals, one for Servlet, one for EJB,
one for JDBC. Two users can share the same principal all the way or part
of the way (e.g. use the same JDBC principal).
> 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.
JAAS pretty much hooks your EJB and Servlet containers into the
authentication engine. The authentication engine can return an
EJBPrinicpal and ServletPrinicipal, or J2EEPrincipal for both, etc.
> This all smells like two different camps went off and tried to design
> authentication architectures without talking to one another.
At the moment JAAS is more of an idea out there that has to be
integrated to EJB/Servlet to see if it works. From what I've done so
far, it seems to be doable.
Of course this raises the question, how will you EJB server tell JAAS
what prinicipal type it's looking for? How do you install the prinicipal
type into JAAS?
> 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?
No, JAAS prinicipal is an EJB principal, a JAAS subject is more top
level and can contain multiple principals (say one for EJB, one for
LDAP, one for ERP). It can also contain credentials which the back-end
needs, but your application doesn't care about.
> 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.
You just need to authenticate against the Servlet, the Servlet has to
carry that information all the way to EJB and beyond.
Once I get that working for Tomcat (probably two/three weeks) I'll
details on how it was done.
arkin
>
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
