You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Louis <la...@gmail.com> on 2008/10/21 21:35:23 UTC
Announce: PrincipalAuthenticator 1.0 (for NTLM Authorization behind
IIS)
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.
This is usefull for identifying users in java applications without
forcing them to sign-in. Unfortunately, this short circuits the rest of
tomcat's normal authentication sequence (where it asks the SecurityRealm
what the user's roles are. eg: authorization).
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. Once the server is configured with an appropriate source
of permissions (SecurityRealm or LoginModule) developers can use the
typical 'request.isUserInRole("role")' calls and declarative security to
perform checks on users' permissions.
All an application must do to use this is declare their login-config as
such in the web.xml (on top of whatever binding is required to their
security config on the server)
|<login-config>
<auth-method>PRINCIPAL</auth-method>
</login-config>
The PrincipalAuthenticator is available as either ASF or LGPL licensed code (your choice).
http://www.laj.ca/projects/PrincipalAuthenticator/
|
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Announce: PrincipalAuthenticator 1.0 (for NTLM Authorization
behind IIS)
Posted by Louis <la...@gmail.com>.
Bill Barker wrote:
> "André Warnier" <aw...@ice-sa.com> wrote in message
> news:48FE3506.5000103@ice-sa.com...
>
>> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Announce: PrincipalAuthenticator 1.0 (for NTLM Authorization behind IIS)
Posted by Bill Barker <wb...@wilshire.com>.
"Andr� Warnier" <aw...@ice-sa.com> wrote in message
news:48FE3506.5000103@ice-sa.com...
> 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.
This means that container-based security (i.e.
<security-constraint>...</security-constraint>) is almost useless in this
case.
> 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).
> 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.
> Thanks in advance for any light on the above,
> Andr�
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Announce: PrincipalAuthenticator 1.0 (for NTLM Authorization
behind IIS)
Posted by Louis <la...@gmail.com>.
André Warnier wrote:
> 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).
Yes.
> 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 ?
Almost, it makes Tomcat check the application's SecurityRealm for the
user's Roles. If there's no SecurityRealm defined then the user still
gets no Roles.
The third uml on the docs page shows the Authenticator closing the JAAS
loop on tomcat.
http://www.laj.ca/projects/PrincipalAuthenticator/doc/uml/TomcatIISAuthenticatorSequence.png
(The diagrams a little out of date, the PrincipalAuthenticator is shown
as TomcatIISAuthenticatorValve)
> 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 ?
That is exactly right. This is why it's called a PrincipalAuthenticator.
The principal supplied by the JK connector can come from anywhere. It
can also be provided by a tomcat Valve acting before the Authenticator
is called.
The PrincipalAuthenticator has gone through a few names early on, but I
realized that the mechanism was actually fairly generic, and so I
refactored the names until settling on PrincipalAuthenticator.
> 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 ?
Tomcat doesn't need to necessarily maintain the list, but there are
SecurityRealms that work that way. Typically you would use a
DatabaseSecurityRealm that would lookup the user's Roles from a table
(or from an LDAP query. eg: ActiveDirectory).
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html
Since the Principal isn't supplied with a password or other credential,
we're relying on the providing service to be accurate. (ie: we assume
that IIS or Apache isn't lying to us, and has done it's job correctly).
As such, some Realms may require a little extra configuration or Java to
cough up the Roles without getting a password.
>
> 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 ?
Yes. This is a popular topic on the net. 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
>
> Thanks in advance for any light on the above,
> André
My Pleasure. It's great to see some interest in this.
-Louis
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Announce: PrincipalAuthenticator 1.0 (for NTLM Authorization
behind IIS)
Posted by André Warnier <aw...@ice-sa.com>.
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 ?
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 ?
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 ?
Thanks in advance for any light on the above,
André
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org