Bill Barker wrote:
"André Warnier" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Louis wrote:
[...]
PrincipalAuthenticator is an implementation of a Tomcat Authenticator
that allows transparent authorization to happen for corporate Windows
users.
[...]
The JKConnector provides Tomcat the ability to sit behind an instance of
IIS and have requests passed to it for java applications. If NTLM
(Integrated Windows Authentication) is enabled on IIS and
tomcatAuthentication="false" on the tomcat side AJP connector, then IIS
will provide each request into tomcat with a Principal container the
user's DOMAIN\USERNAME. ie: javax.security.Principal(HOME\ME). This is a
fully authenticated credential when used in a trusted domain.
[...]
The PrincipalAuthenticator uses the Principal supplied by IIS to make
Tomcat ask the SecurityRealm what roles the user should have. It closes
the JAAS loop.
[...]
Hi.
I am unfamiliar with Tomcat Authenticator(s), therefor my questions below
may be naive or nonsensical. I apologise in advance if that is the case.
What you describe above for IIS, seems to me similar to the case where
Apache in front of mod_jk performs user authentication, and passes it on
to Tomcat through mod_jk. In that case also I believe that each request
in Tomcat ends up with a javax.security.Principal(user-id).
If the Apache authentication is based on NTLM (various add_on modules
allow that at Apache level), then the user-id is also of the form
Domain\User.
If I understand thus correctly what PrincipalAuthenticator does, it is not
to itself authenticate the Tomcat user, but associate this user with
Tomcat roles. Yes ?
And it would work just as well, whether the original authentication came
from IIS or from Apache, or any other source (e.g. the jCIFS servlet
filter). Is that correct ?
With the attribute tomcatAuthentication="false", the out-of-the-box Tomcat
will authenticate the user (i.e. assign a Principal), but without any roles.
That's effectively it. But to be precise, it's the front-end (Apache or
IIS) that authenticates the user, and setting
tomcatAuthentication="false" means tomcat will accept the Principal
supplied by the JK Connector.
This means that container-based security (i.e.
<security-constraint>...</security-constraint>) is almost useless in this
case.
This is Bang On, and is why I created the PrincipalAuthenticator.
Without it, <security-constraint>'s don't work.
Nor does request.isUserInRole("role"),
or struts' <logic:present role="myRole" >,
or roles="" on struts actions.
Other frameworks also have mechanisms for using container managed
security, and these are all nerfed when the authenticators bypass the
Authorization because they have already been given a Principal.
Next, the association between users and roles.
The way it is described above, it sounds like, at the Tomcat level, there
must still be some source of information that associates a given user-id
with a list of roles. How is that achieved, and how does the user-id part
of this get to be known by Tomcat ?
Does Tomcat need its own local list of NTLM user-id's associated to roles
?
Not being interested enough to look over the code ;), it sounds like this
finds the roles assigned to NTLM and assigns them to the user. In this
case, it sounds like it works a lot like the JNDIRealm except that it skips
the additional sign-on step (so the user doesn't have to send a
username/password, and is just logged in with their NTLM credentials).
The PrincipalAuthenticator doesn't actually get any Roles (permissions),
it just re-enables tomcat's ability to do so. (See Below)
As a more generic topic, does there exist any method by which the notion
of "role" in Tomcat parlance can be associated (preferably dynamically and
without a local store) with the notion of "user groups" in NTLM/Windows
Domain parlance ?
Nothing in Tomcat-out-of-the-box. You'll have to take it up with the OP if
he wants to add such an extension to his code.
The PrincipalAuthenticator does not directly lookup the user's roles
from the NT / Active Directory. What it does do is allow the container
to do so, while relying on transparent authentication.
The diagrams at my homepage do a better job of illustrating what happens
when Tomcat is put behind IIS/Apache:
http://www.laj.ca/projects/PrincipalAuthenticator/doc/uml/
but I'll take a stab at it here.
What happens when you use IIS or Apache and get the principal, is that
the normal tomcat Authenticator sequences short circuits. Basic, Form,
Client-Cert authentications all see the Principal object and skip over
the remainder of the JAAS sequence (which is Authorization, eg: getting
Roles). So normally, you're stuck with just a user Principal and no
permissions in the container managed space. You can still use this
Principal to programmatically check the permissions, but this is outside
of the normal Java API.
What the PrincipalAuthenticator does, is accepts the supplied Principal
as the credential used to retrieve the user's permissions. So if the
web-application uses PRINCIPAL (with IIS or Apache) instead of FORM or
BASIC, they get transparent authentication of the user, and the server's
defined SecurityRealm or LoginModule can attach the user's Roles
(permissions).
A tomcat SecurityRealm or jboss LoginModule can retrieve Roles from any
datasource. There are implementations already for querying LDAP, and
this can be used for getting NT/Active Directory permissions from an NT
Domain Server.
Here's some references that I'm familiar with:
http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JNDIRealm
https://www.jboss.org/community/docs/DOC-11253
In my shop we're not actually bouncing off of the NT permission
structure as the management feels it doesn't give granular enough
permissions for our applications (IT is picky about creating more
groups), so we have a different application for managing permissions
from a database.
I've done permission retrieval from ActiveDirectory via LDAP before. I
suppose an end-to-end example might be useful.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
