Arkin wrote:
>Here is what I have working. The Servlet container (Tomcat) performs an
>authentication, using JAAS as the middle layer, and an LDAP login
>module. The LDAP login module returns a bunch of principals
>(LDAPPrincipal, CommonNamePrinicipal, UIDPrincipal) and a bunch of
>credentials (Permission, RoleCredentials, JDBCUserPassword, etc).
>What Tomcat needs is exactly one prinicipal and a way to determine if
>that principal is in a role (which I believe is a public credential).
>But Tomcat has no way of knowing which of the four prinicipals are right
>for it, and which credentials allows it to check isInRole().
>There is nothing broken with JAAS, it works perfectly (except for the
>1.3 dependency, I think it should also support 1.2), but there is no
>definition of what Tomcat should expect and what my LDAP LoginModule
>should provide, so the two cannot talk toghether.
When we designed and developed JAAS it was on a 1.2 JVM, then we hit a
snag and had to add an API thus it could not be aded to JDK 1.2 so then
it cam dependant on 1.3.
All of our 1.2.x JVMs will ship with JAAS as we do have a 1.2 version
(fixed the problem)
>If the two cannot talk together, I cannot benefit from the JAAS API and
>the ability to plug in different modules.
>This problem should be addressed in a JAAS J2EE extension. It's fairly
>simple to define these interfaces, document them, and implement them.
Not sure that this will happen as JSR 58 is broad,
>I agree with the JAAS design decisions. It's just that we need a common
>definition for a J2EE principal and public credentials to make it work.
Agree, we started with some platform Principals and credentials so now
its time to move on. We do have a J2EE Principal definition that we are
taking forward so that may help
>Not so much, and not at all in J2EE. In fact, in J2EE my application
>will be running without any permissions, and my resource managers will
>so PrivilegedAction all the time, so I find no use for that feature.
>I do believe that a Subject should be associated with the current
>thread, this can be done in two ways. One: using ThreadLocal. Two: using
>AccessController. Although the second is the recommended way, it does
>not work with Java 1.2. I would rather see an implementation that can
>use either approach to work both on 1.2 and 1.3.
I gather you will be doing a Subject.doas() where both the identity swap
and the dispatch is done. Why would you want to do both, why not let
container code do the dispatch ?
Thanks,
Anthony Nadalin
_______________________________
mailto:[EMAIL PROTECTED]
===========================================================================
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".
