oh...@cox.net wrote:
---- "Caldarale wrote:
From: oh...@cox.net [mailto:oh...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
