tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Date Sun, 04 Dec 2011 01:20:01 GMT

---- wrote: 
> ---- "André Warnier" <> wrote: 
> > wrote:
> > > ---- "André Warnier" <> wrote: 
> > >> wrote:
> > >>> ---- "André Warnier" <> wrote: 
> > >>>> wrote:
> > >>>>>> Now let me ask another question :
> > >>>>>> Why do you need to authenticate the user at the Apache
level, and pass this user-id to 
> > >>>>>> Tomcat ?
> > >>>>>> Obviously, from the OAM documentation I scanned, there
must exist an OAM module directly 
> > >>>>>> for Tomcat, to authenticate users there.  Why are you not
using that ?
> > >>>>> It seems like they should have one, but, unfortunately, they
> > >>>>>
> > >>>> Mmm. Browsing the documentation, I seem to remember seeing something
about Weblogic, no ?
> > >>>> Is that not usable ?
> > >>>>
> > >>>> (As an aside, send your messages only to the list. I get all messages
to the list anyway, 
> > >>>> so if you send them to me too, I get them twice).
> > >>>
> > >>> Hi,
> > >>>
> > >>> Sorry about the emails.  
> > >>>
> > >>> Yes, they do support integrating with WebLogic, and we do use that
for other cases, but that's probably a bit off-topic here.
> > >>>
> > >> We don't mind the competition here. Keeps us on our toes.
> > >> Just kidding.
> > >> What I meant to ask (me being the not-so-Java specialist see) was, since
Weblogic is a 
> > >> servlet engine, and Tomcat is a servlet engine, both ought to abide by
the servlet spec 
> > >> and such, so isn't the Weblogic-oriented module usable with Tomcat ?
> > >> Or is this too much of a rosy view of the world ?
> > >>
> > >> Anyway, the only other thing that comes to mind is, since you seem to be
an OAM customer, 
> > >> can you not ask the OAM support people if OAM sets the internal Apache
user-id or not ?
> > >>
> > > 
> > > 
> > > Hi,
> > > 
> > > I'll answer the last question first:  We have asked, but they don't support
integration with Tomcat out-of-the-box.  That was why I've been looking into it for our organization.
> > > 
> > 
> > Ok. But the question here is different : you are not asking if they support Tomcat.
> > What you are asking is if OAM can set the Apache internal user-id, once the user
> > authenticated by OAM.
> > 
> > The situation is the same as if you had to support, say, some legacy Apache-based

> > application, and this Apache-based application needs the user-id, and it normally
gets it 
> > from Apache.
> > For example, imagine that your organisation has some pre-existing content-management

> > system based on Apache and Perl.  Now you purchase OAM as a global SSO mechanism,
and you 
> > want to use OAM to authenticate the users for your content-management application.
> > that, the easiest way is for OAM to just set the Apache user-id, because then you
> > have to change anything to your existing application.
> > 
> Hi,
> I didn't say anything about it before, but I've been, in parallel with our discussion,
mucking around both the OAM innards and the Apache source code, as best I can, trying to find
out why that internal remote_user string (it is, I believe, only internal to Apache), to see
why it isn't being set.  Notice also that I said "remote_user string", rather than "remote_user
> The reason is that, in looking through the Apache source code, I haven't (yet) been able
to find a variable like that.  Rather, it looks like the Apache code just dumps the string
representing the user into some buffer that its building to send out via AJP protocol.
> On the OAM side, I haven't been able to find any configuration "tweaks" that would make
their webagent populate (or not populate) whatever data structure inside of Apache either.
> I may or may not decide to try to bug Oracle about why their webagent doesn't do appear
to do that.  Probably not though, as in the past, it's hard to find someone who knows their
stuff well enough to answer such an esoteric question.  Plus, the valve seems to work at the
> Having said that, and having started to work more with my valve code, I do have a more
on-topic question for you and for the list, in general.  
> To recall, my test Tomcat is pretty much vanilla, including the default realm that uses
the tomcat-users.xml.
> Earlier, you and Chuck said that when my valve code asserts a user into Tomcat (e.g.,
via the setUserPrincipal()), that that asserted user didn't have to even be in the Tomcat
> I'm finding that that part does work as we've discussed, but the question that I have
is what roles in Tomcat would that user have (in Tomcat)?  
> In my testing, and as I've mucked around with my valve code, I found that I could assert
not only a user, but it looks like I can also assert that user's roles in Tomcat.  
> And, I can even assert roles that don't exist in the realm!!
> In other words, suppose my valve gets a request with a userID of "foobar".   Then, it
appears that my valve code can not only assert the "foobar" user into Tomcat, but can also
assert that the "foobar" user has roles "foobarRole1" and "foobarRole2", EVEN when those roles
don't exist/aren't defined in the Tomcat realm.
> Is this correct?
> If it is, I may have a problem. 
> Let me explain:
> My original plan/thought/idea/thinking was that if I could get my valve code to assert
the user into Tomcat as a principal in the Tomcat environment, then, at least to Tomcat itself,
that user/principal would "pick up" the roles that that user would have within the Tomcat
> In other words, if I asserted "foobar" into Tomcat, and if there was already a user named
"foobar" in the Tomcat realm, that then the asserted user would have all of the roles within
Tomcat that he/she should have, via the realm.
> However, that doesn't appear to be the case :(.  
> Rather it appears that even if the user that I'm asserting actually exists in the Tomcat
realm, after my valve asserts the user into Tomcat, the user doesn't appear to have any roles
in Tomcat.  I'm using the security example app in the /examples that comes with Tomcat to
check if Tomcat 'believes" that the asserted user has xxxx role.
> 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?  
> I'm not sure if I'm explaining that clearly, but let me know?
> Here's an example:
> In tomcat-users.xml, I have a user, "0test" with role "manager-gui".
> I send a header into my valve with userID "0test", and it asserts the "0test" user into
> Then I go to the Tomcat security example app, and I search for role of "manager-gui",
and the app tells me that user "0test" has not been granted the "manager-gui" role.
> So the question that I really have here is:  Can I "connect" the user that my valve asserts
into Tomcat with the corresponding user in the Tomcat realm (so that the asserted user can
"have" all of the roles in Tomcat that he/she "should" have)?
> Thanks,
> Jim


I just found the following, which seems to confirm what I'm finding with asserted users, as
described above: 

Note where it says:

"This requires that any acess to /jsp-examples/snp/* be authenticated to any of 
the roles declared to Tomcat elsewhere in the web.xml file. The problem with 
this when receiving authentication information from Apache httpd via mod_jk is 
that we have not found any way to associate role membership with the 
authenticated user. As a result, Tomcat refuses access to the servlet, even 
though we do appear to have successfully conveyed authenticated user information 
to Tomcat. 
It appears that when Tomcat's own authentication is bypassed (using 
tomcatAuthentication="false" noted above), Tomcat's mechanisms for assigning 
roles to users (e.g. from tomcat-users.xml) are also bypassed, so the 
authentication is effectively useless for invoking servlets." 

That is exactly the same problem/behavior that I'm seeing with users that I assert into Tomcat
using my valve code...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message