Assaf Arkin wrote:
> > > JNDI does not authenticate the user. Once you get a reference you can
> > > use it multiple times with different users.
> > >
> > > JAAS takes care of authenticating if you use multiple servers with
> > > different credentials (see javax.security.auth.Subject to understand
> > > how).
>
> Let's make it aboslutely clear. No where in the specification does it
> support authentication for the JNDI environment naming context. And
> there's a reason for that, so don't expect to see JNDI authentication
> being supported in the future.
>
> The JNDI model does not authenticate the user making a call to a bean,
> but the user who gets a reference to a bean. So as far as security goes,
> it's one big security hole.
My vote.
>
>
> The JAAS model authenticates the user when the actual call is made,
> enforcing security.
Authentication and context propagation (for a method call) are tow different concerns:
-->Authentication is the act of getting security attribute from the user that sits
on
the machine. This could be done when starting the application client. JAAS helps here.
Or a
way for a programm to proove it identity to another programm (SSL).
-->Transmitting that security properties associated with a method call is handled
by the
communication protocol (like RMI, IIOP) and doesn't necessarily requires
authentication (we
could assume that client and server are both communicating over a secure canal). Even
when
this is not the case, securing the context being transmitted is handled by the
communication
protocol (COS Security)
>
>
> Of course the current JAAS 1.0 is incomplete in many ways, I grant you
> that. So think of it as the basis, with better guidelines coming along
> down the road.
I don't see where JAAS1.0 doesn't make what it should.
>
>
> > JAAS doesn't deal with sending security context to a server. JAAS can only
>associate a
> > thread with multiples principals. So JAAS can't kow to which server request is
>being
>
> <magic starts here>
>
> Security context is somehow propagated between client and server. It
> could be over IIOP (COS Security), it could be Kerberos, it could be
> HTTP/SHTTP (e.g. XML-RPC), etc.
>
> All these protocols allow sufficient information to be passed between
> client and server.
That is right.
> Assuming you have JAAS at both ends, you can
> reauthenticate as needed (typically only once per user).
That is right and logicaly true. But in the ejb server, you dont need JAAS for
authentication because the server itself can take care of quering it's authentication
database. The whole server is written by the same instance and a physical user doesn't
directly interact with the server. JAAS is needed at client side because the
application
client implements the user interface that takes care of gathering user input (name,
password) on behalf of the authentication subsystem (AuthenticationModule).
>
>
> <magic ends here>
>
> Example scenario. User logs into the Web server, HTTP authentication
> kicks in, authenticates the user against JAAS. JAAS now has a
> RoleCredential, CommonNamePrincipal, and Kerberos credential for that
> user.
>
> Web server makes call to EJB server over IIOP using Kerberos (just an
> example). The credentials are passed from the client to the server. EJB
> server uses Kerberos credentials to re-authenticate.
This re-authentication shouldn't be necessarily done through JAAS. The ejb server cann
simply query it realm (authentication database) to get the principal coresponding the
Kerberos credential. It can alternatively use the Kerberos credential to instantiate a
principal and associates it with the users thread (also simple, because you can encode
a
Kerberos credential into a string).
>
>
> More complex example scenario. User 'Betty' from 'Acme.com' logs into
> HTTP server and authenticates. An EJB bean is now called on a remote
> server by some other company (ASP.com) under the account 'Acme.com-RnD'.
> JAAS provides 'Betty' with the proper credentials to authenticate as
> 'Acme.com-RnD' (shared account) on ASP.com's EJB server.
>
--
Francis Pouatcha
MATHEMA Software GmbH
http://www.mathema.de
===========================================================================
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".
