Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of lajatca@gmail.com designates
 209.85.217.10 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=NVGdkOcLukPbK0AH0YI/aVlldN21HEJi3s1ZhRum8NBbd9PAyWiBSa011wVxSOW7D2
         ZNwY7sg1OnwdnUdVCPlhL/zbLTxKYDcTJKpGCVW0trwEqGD/HiEfL4gDxO0uPfVBKSIH
         XGy34fPoSkqrW3bOHktsSIrtavOTJD6mxRlpw=
Message-ID: <48FFC889.3010302@gmail.com>
Date: Wed, 22 Oct 2008 20:42:49 -0400
From: Louis <lajatca@gmail.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Announce: PrincipalAuthenticator 1.0 (for NTLM Authorization
 behind IIS)
References: <48FE2EFB.2000807@gmail.com> <48FE3506.5000103@ice-sa.com>
 <gdm6us$s2h$1@ger.gmane.org>
In-Reply-To: <gdm6us$s2h$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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