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 aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4EDB8D94.1080001@ice-sa.com>
Date: Sun, 04 Dec 2011 16:11:16 +0100
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Do any of the Tomcat LDAP-type realms support "no password"
 authentication?
References: <20111204024416.F1IY4.212267.imail@eastrmwml106>
In-Reply-To: <20111204024416.F1IY4.212267.imail@eastrmwml106>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

ohaya@cox.net wrote:
> ---- "Caldarale wrote: 
>>> From: ohaya@cox.net [mailto:ohaya@cox.net] 
>>> Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
>>> In other words, even though my valve code can assert a user 
>>> into Tomcat, and even if that same user already exists in the
>>> Tomcat realm, the asserted user seems to be 'disassociated'
>>> from the same user in the Tomcat realm?  
>> Need to get some terminology correct here.  A Realm does not normally contain users, roles, or any other authentication or authorization _data_; rather, it is a Java class that embodies rules for examining the credentials supplied by a login attempt and comparing them to credentials and roles stored in some external location.  By default (and never meant to be used in production), the external location is the file tomcat-users.xml, and the Realm is UserDatabaseRealm (augmented by LockOutRealm to discourage probing).  Several other Realm classes are supplied with Tomcat, to allow access to credentials from LDAP servers, relational databases, JAAS, etc.
>>
>> I think what you need is essentially a Realm that does no authentication of its own (trusting httpd to do that), but does perform the authorization function.  It can then map the userid to whatever set of roles are appropriate for that user, and return the appropriate response when queried.  See the doc for details:
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
>>
>> It would seem likely that someone out there has written a Realm that performs the above functions in conjunction with httpd authentication.  (Note: you keep using the word "Apache" - which is a software organization with many products - when you're referring to httpd, a specific Apache product, as is Tomcat.)
>>
>>  - Chuck
>>
> 
> 
> Hi Chuck,
> 
> Corrections understood, and I'll try to be more careful.  As you point out, and as I mentioned earlier in the thread, it seems like I've come all the way around to the original subject "...Tomcat LDAP-type realms support "no password" authentication?".
> 
> I've been and still am looking around for something like that, but haven't found it yet.
> 
> I'm still puzzled by something though.  Even if I did find (or implement) a realm that was a "no password realm", how do I tie the two pieces that I end up with, the valve and the no-password realm, together?
> 
> In other words, I can pull the userID from the incoming header in the valve, but then I think that the valve code then needs to authenticate against the no-password realm.  Is that correct?
> 
> And, if so, how to do that?  
> 
> I've been looking for a way (API?) to programmatically "authenticate the user" against Tomcat, so that I could add that into my valve code, but haven't been find anything yet.
> 

I am answering here, but it also follows-up on other previous messages to the list, to try 
and keep this manageable.

I believe that now you have reached a fundamental issue which you need to resolve first, 
before looking at the technical details of how to do it.

The basic issue - and I may not be expressing this entirely using the correct terms - is 
that the notion of "role" is somewhat specific to the Java servlet world, and it does not 
entirely match what in other "scopes" is called a "user attribute" and in yet other scopes 
is called a "user group", or even "privileges" for users and/or groups.

I don't know how OAM works, nor on what kind of concept among the above its "permissions" 
(to use yet another related concept) are based.

But in your case, to be entirely consistent, you would have to do the following :
After the user is /authenticated/ (meaning that you just have a user-id which you can 
trust), comes the /authorization/ part. That is, the user wants to access this webapp in 
Tomcat; is he allowed to do that ?
And to be consistent, you would have to ask OAM. And OAM would answer yes or no, on the 
base of information that OAM has, and Tomcat doesn't.
Because if you do otherwise, then you are going to find yourself obliged to duplicate 
under Tomcat a whole management of "roles" and keep them in sync with whatever back-end 
OAM uses to determine this.

To be more explicit : suppose you protect an application by Tomcat's declarative style of 
security, and in the web.xml of that application, you indicate that this application can 
only be used by users which have the "roleX" in their list of roles.
Then whenever a user tries to access the application, Tomcat will make a "isUserInRole" 
call, to find out if the current user has the role "roleX".
And for that, Tomcat will need a Realm, and this Realm will need a back-end which it can 
check to answer that question. And if this back-end is independent from the OAM system, 
then somehow you will have to keep it synchronised.  Because tomorrow the user can be 
promoted or demoted, and not have access to this application anymore, and this will be 
managed by the people who manage the users in the OAM system.
And you may also need a translation table, because what in your application's web.xml is 
named as "roleX", may translate in OAM terms to something rather different.

So let me suggest another way, thinking a bit "out of the box" :

In fact, when you think about it, the only thing for which Tomcat needs these "roles", is 
to determine if the user has or not access to the application. (I doubt that inside the 
applications themselves, there are any "isUserInRole" calls; are there ?).

Now, you already use a front-end Apache httpd, and this front-end httpd already has an OAM 
plugin.  And this OAM plugin allows you to configure a Location such :

<Location /myapp>
   AuthType Oblix
   require valid_user
   SetHandler jakarta-servlet
   ...
</Location>

I have to suppose that there exists a way, within OAM, to indicate not only if this user 
is valid in general, but also to indicate íf this user has access or not to "/myapp".
If so, then nothing stops you from having as many <Location> sections in the front-end 
Apache httpd, as you have webapps in Tomcat, like :
<Location /myapp2>
<Location /myapp3>
etc..
And then, provided that the only way to access Tomcat is through the httpd font-end, you 
do not need any roles in Tomcat.
If the user is not allowed by OAM to access "/myapp2", then he will never get past the 
front-end, and the request will never even be forwarded to Tomcat.

And if you need the OAM /user-id/ within the Tomcat applications, then that is a different 
matter.   Maybe a simple servlet filter examining the OAM cookies, extracting the user-id 
and populating the userPrincipal would be sufficient to do that.


And if the above doesn't work, then I have some more ideas, based on the "external 
applications" part of OAM, which I saw while browsing the OAM documentation.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org