> 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)
Not really. If you could take all the security context from machine A
and move it to machine B, you are right. But you can't. Machine A in my
network might have a security context that I don't want machine B (in
your network) to know about.
So in many cases security propagation actually involves authentication.
Simple example. Machine A attempts to use a URL on machine B. Machine A
propagates the context through HTTP basic authentication, opening SSL
connection, or SHTTP. In effect, machine A is authenticating and machine
B will authenticate the user locally when the method is invoked.
So you end up getting another authentication, which is your form of
context propagation.
The same also applies when you open up a JDBC connection. You carry the
security context by opening up the connection with the proper user
name/password.
> > 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.
See other thread discussing integration limitations. JAAS needs some
additional specifications to be useable in a J2EE environment.
Don't get me wrong. I like the JAAS model, I think it's very well done.
It just needs some more J2EE interfaces.
> 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).
How about if I want to use LDAP, X.500, Kerberos, PAM or simple text
files and your EJB server only supports an authentication database,
which I don't use.
What if JAAS allowed me to plug my authentication provider into your EJB
server?
> 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).
And exactly how does the EJB server do that?
If my Servlet container is using an LDAP LoginModule, and your EJB
server is using an simple file, do I need to drop LDAP on the Servlet
side? Do I need to export my LDAP into a file for the EJB server? Do I
need to wait for an upgrade?
Of course, I can always have millions of principals in my LDAP directory
server, and use two/three EJB serves. But I don't like that approach. I
would rather benefit from plug-n-play authentication.
arkin
>
> >
> >
> > 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".
--
----------------------------------------------------------------------
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".
