---- oh...@cox.net wrote: > > ---- oh...@cox.net wrote: > > > > ---- "André Warnier" <a...@ice-sa.com> wrote: > > > oh...@cox.net wrote: > > > > ---- "André Warnier" <a...@ice-sa.com> wrote: > > > >> oh...@cox.net wrote: > > > >>> Hi, > > > >>> > > > >>> I'm new here, and hope that someone can help. > > > >>> > > > >>> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, > > > >>> etc.) support an authentication mode where no password or credentials > > > >>> are required? In other words, where just a userID/username is > > > >>> presented, and if that userID/username is present in the LDAP, then > > > >>> the user gets authenticated? > > > >>> > > > >> You have to be VERY specific here about what you mean, because this is > > > >> a very delicate area. > > > >> > > > >> If you mean : "does there exist any way by which Tomcat can > > > >> authenticate a user, without > > > >> forcing this user to go through a login dialog with userid and > > > >> password ?" > > > >> then the answer is : yes, several (*). But the applicability of each > > > >> depends very much on > > > >> the exact circumstances. > > > >> > > > >> If you mean : "does there exist any /standard/ authentication > > > >> mechanism in Tomcat whereby, > > > >> /with/ a login dialog, the user could be authenticated without > > > >> providing a password, > > > >> although the authentication back-end (e.g. LDAP) has a non-empty > > > >> password registered for > > > >> that user ?" > > > >> then the answer is no, definitely. Because such a mechanism would be > > > >> a HUGE security > > > >> hole, so it is certainly not provided as any standard authentication > > > >> framework. > > > >> (which does not mean that you could not invent your own mechanism). > > > >> > > > >> Also, when you are mentioning LDAP, do you really mean the standard > > > >> LDAP (which is just > > > >> basically a database, and is not per se an "authentication > > > >> mechanism"), or do you mean > > > >> "Windows domain authentication, backed up by an Active Directory > > > >> server" ? > > > >> Or something else ? > > > >> > > > >> There is so much variation possible here, that it may be better to > > > >> describe what you want > > > >> to achieve really, rather than asking questions about this or that > > > >> mechanism right away. > > > >> > > > >> > > > >> (*) for example, look here : > > > >> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html > > > >> http://waffle.codeplex.com/ > > > >> http://www.ioplex.com/jespa.html > > > >> > > > > > > > > > > > > Hi Andre, > > > > > > > > Sorry. I should have been clearer in my explanation and my question, > > > > so let me try again. > > > > > > > > Our configuration has an Apache in front of the Tomcat, with the Apache > > > > reverse-proxying (using mod_proxy, for now) to the Tomcat. > > > > > > > > In the Apache proxy, we do client-authenticated certificate > > > > authentication, and we also have a web agent/module that authenticates > > > > the user into a commercial SSO product. After the user is > > > > authenticated, the requests that go to/get proxied to the Tomcat have > > > > some HTTP headers, including a header containing the userID of the user > > > > that got authenticated by the SSO product. > > > > > > > > I've been working on Tomcat valve that does "ID assertion", i.e., when > > > > the code in my valve sees the HTTP header with the authenticated > > > > userID, it "asserts" the user into Tomcat. > > > > > > > > Specifically, my valve code calls > > > > org.apache.catalina.connector.Request.setUserPrincipal(getPrincipal(paramRequest)), > > > > where "paramRequest" is the org.apache.catalina.connector.Request > > > > object. > > > > > > > > > > > > When I posted my message, I had just started on my valve code. As I > > > > said, I'm kind of new to Tomcat security, but at that time, I *thought* > > > > that after my valve did the setUserPrincipal(), that the user had to > > > > somehow be authenticated into the Tomcat realm (i.e., that the asserted > > > > userID had to actually exist in the Tomcat realm). > > > > > > > > > > > > I've since gotten an initial version of my valve code kind of working, > > > > but I'm still a little. > > > > > > > > I can get the userID from the request header and call the > > > > setUserPrincipal() in the valve code successfully, and from some test > > > > JSP pages I use, I can see that when the JSP calls > > > > request.getUserPrincipal(), it appears to return the asserted user. > > > > > > > > > > > > The thing that is puzzling me is that, on my test Tomcat, I just have > > > > the default realm (the one that uses tomcat-user.xml for the user > > > > base), with only the default set of dummy users. > > > > > > > > > > > > And yet, when I test with my valve and the test JSP, it appears that > > > > everything just works, even when the userID that I assert is not in the > > > > Tomcat realm! > > > > > > > > > > > > For example, I guess in the default realm, there's only a comple of > > > > users (tomcat, etc.), but if I send a request into the Tomcat with a > > > > header with a userID of "foobar" (and even though there is no user > > > > "foobar" in the Tomcat realm), things seem to work ok, i.e., my JSP > > > > displays "foobar" for request.getUserPrincipal(). > > > > > > > > > > > > Having said all of that, I guess that my question has changed somewhat. > > > > Specifically, now I'm wondering: With what I described above, and > > > > with my valve as described above, does the asserted user NOT have to be > > > > in the Tomcat realm at all? > > > > > > > > > > > > It's almost like, with Tomcat, when my valve code calls > > > > setUserPrincipal(), Tomcat doesn't "care" whether the user that I'm > > > > asserting actually exists or doesn't exist in the Tomcat realm? > > > > > > > > > > > > Again, as I said, I'm new, so I may (and probably am) misunderstanding > > > > something about how Tomcat security works... > > > > > > > > > > > > Sorry for the longish post, but I hope that things are clearer now? > > > > > > > > > > Better a long and clear post, than a short and obscure one. > > > > > > Two things : > > > > > > I am not really a Tomcat expert, and this will need to be corroborated by > > > one of them, but > > > it seems that I remember a not-too-long-ago thread in this same forum, in > > > which it came > > > out that if there is already a user-id known to Tomcat, it will not even > > > bother to run its > > > own authentication code. That is said in non-expert terms, but I'm sure > > > someone here will > > > correct that if need be. > > > > > > The other thing is that you may be doing a lot of work for nothing. > > > If you would use either one of the mod_proxy_ajp or the mod_jk Apache > > > module as a > > > connector to Tomcat, then this connector will automatically pass the > > > authenticated Apache > > > user to Tomcat with every request, and you would not need your Valve. > > > Have a look at the TomcatAJP <Connector> description, attribute > > > "tomcatAuthentication". > > > http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html > > > > > > This being said, make sure that the connection between Apache and Tomcat > > > is reasonably > > > secure (for example, within the same host or over an internal network), > > > because the AJP > > > protocol (although in part binary) is not itself encrypted. > > > No user password is passed over it (only the user-id), but a hacker could > > > in theory > > > intercept the packets, and replace one user-id by another. > > > > > > > > > Hi Andre, > > > > Thanks for that info re. AJP. I will definitely take a look (test) that, > > as even if I/we pursue the valve I'm working on, it'd be a nice thing to > > have as an option (e.g., if someone doesn't want to use mod_ajp, they could > > use my valve, but if they use mod_ajp, then they wouldn't need the valve! > > > > If you can remember, can you either provide a link or maybe the subject for > > that thread you referenced? I'd be very interested in reviewing it. > > > > Thanks again for all the great info! > > > > Jim > > > > > Hi Andre (et al), > > I've been testing with AJP and Tomcat. From what I've read, it looks like > that tomcatAuthentication looks for an HTTP header, "REMOTE_USER" that > contains the userID that it will authenticate/assert into Tomcat. > > At this point, I can proxy to Tomcat using AJP fine, but it looks like the > user is not being authenticated within Tomcat. It looks like to me, the > "REMOTE_USER" HTTP header is "(null)", instead of containing a userID. > > I've tried a bunch of stuff in my Apache httpd.conf, using RequestHeader and > also several different rewrite rules, but still can't get this to work. > > Does anyone have a reliable way to populate the REMOTE_USER header, when > using AJP connector? > > Also, I'm a little unclear about whether the "tomcatAuthentication" in the > AJP connector should be set to "true" or "false"? > > Finally, is there a way to configure Tomcat so that it outputs some debug > logging for the AJP connector, e.g., so I can see exactly what headers it IS > seeing? I have a sniffer on, but it's hard to see what's in the AJP > connection protocol. > > Thanks, and sorry for all of the questions! > > Jim
Hi, Also, BTW, I just did a test where, in the Apache httpd.conf, I hard-coded REMOTE_USER header using RequestHeader. In my sniffer, I can see the REMOTE_USER set to the hard-coded string, but in my test JSP on Tomcat, there getUserPrincipal() is returning null. I've tried this test with 'tomcatAuthentication' attribute in server.xml set to both "true" and "false", with the same results :(... Jim --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
