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 ohaya@cox.net designates
 68.230.241.215 as permitted sender)
Message-ID: <20111201232930.BIJW0.186798.imail@eastrmwml205>
Date: Thu, 1 Dec 2011 23:29:30 -0500
From: <ohaya@cox.net>
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Do any of the Tomcat LDAP-type realms support "no password"
 authentication?
In-Reply-To: <20111201231847.8N7N1.186708.imail@eastrmwml205>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sensitivity: Normal


---- ohaya@cox.net wrote:=20
>=20
> ---- ohaya@cox.net wrote:=20
> >=20
> > ---- "Andr=C3=A9 Warnier" <aw@ice-sa.com> wrote:=20
> > > ohaya@cox.net wrote:
> > > > ---- "Andr=C3=A9 Warnier" <aw@ice-sa.com> wrote:=20
> > > >> ohaya@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 r=
equired?  In other words, where just a userID/username is presented, and if=
 that userID/username is present in the LDAP, then the user gets authentica=
ted?
> > > >>>
> > > >> You have to be VERY specific here about what you mean, because thi=
s is a very delicate area.
> > > >>
> > > >> If you mean : "does there exist any way by which Tomcat can authen=
ticate a user, without=20
> > > >> forcing this user to go through a login dialog with userid and pas=
sword ?"
> > > >> then the answer is : yes, several (*).  But the applicability of e=
ach depends very much on=20
> > > >> the exact circumstances.
> > > >>
> > > >> If you mean : "does there exist any /standard/ authentication mech=
anism in Tomcat whereby,=20
> > > >> /with/ a login dialog, the user could be authenticated without pro=
viding a password,=20
> > > >> although the authentication back-end (e.g. LDAP) has a non-empty p=
assword registered for=20
> > > >> that user ?"
> > > >> then the answer is no, definitely.  Because such a mechanism would=
 be a HUGE security=20
> > > >> hole, so it is certainly not provided as any standard authenticati=
on framework.
> > > >> (which does not mean that you could not invent your own mechanism)=
.
> > > >>
> > > >> Also, when you are mentioning LDAP, do you really mean the standar=
d LDAP (which is just=20
> > > >> basically a database, and is not per se an "authentication mechani=
sm"), or do you mean=20
> > > >> "Windows domain authentication, backed up by an Active Directory s=
erver" ?
> > > >> Or something else ?
> > > >>
> > > >> There is so much variation possible here, that it may be better to=
 describe what you want=20
> > > >> 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
> > > >>
> > > >=20
> > > >=20
> > > > Hi Andre,
> > > >=20
> > > > Sorry.  I should have been clearer in my explanation and my questio=
n, so let me try again.
> > > >=20
> > > > Our configuration has an Apache in front of the Tomcat, with the Ap=
ache reverse-proxying (using mod_proxy, for now) to the Tomcat.
> > > >=20
> > > > In the Apache proxy, we do client-authenticated certificate authent=
ication, and we also have a web agent/module that authenticates the user in=
to 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 h=
eader containing the userID of the user that got authenticated by the SSO p=
roduct.
> > > >=20
> > > > I've been working on Tomcat valve that does "ID assertion", i.e., w=
hen the code in my valve sees the HTTP header with the authenticated userID=
, it "asserts" the user into Tomcat. =20
> > > >=20
> > > > Specifically,  my valve code calls org.apache.catalina.connector.Re=
quest.setUserPrincipal(getPrincipal(paramRequest)), where "paramRequest" is=
 the org.apache.catalina.connector.Request object.
> > > >=20
> > > >=20
> > > > 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* t=
hat 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).
> > > >=20
> > > >=20
> > > > I've since gotten an initial version of my valve code kind of worki=
ng, but I'm still a little. =20
> > > >=20
> > > > I can get the userID from the request header and call the setUserPr=
incipal() in the valve code successfully, and from some test JSP pages I us=
e, I can see that when the JSP calls request.getUserPrincipal(), it appears=
 to return the asserted user.
> > > >=20
> > > >=20
> > > > The thing that is puzzling me is that, on my test Tomcat, I just ha=
ve the default realm (the one that uses tomcat-user.xml for the user base),=
 with only the default set of dummy users.
> > > >=20
> > > >=20
> > > > And yet, when I test with my valve and the test JSP, it appears tha=
t everything just works, even when the userID that I assert is not in the T=
omcat realm!
> > > >=20
> > > >=20
> > > > 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 heade=
r with a userID of "foobar" (and even though there is no user "foobar" in t=
he Tomcat realm), things seem to work ok, i.e., my JSP displays "foobar" fo=
r request.getUserPrincipal().
> > > >=20
> > > >=20
> > > > Having said all of that, I guess that my question has changed somew=
hat.  Specifically, now I'm wondering:  With what I described above, and wi=
th my valve as described above, does the asserted user NOT have to be in th=
e Tomcat realm at all?
> > > >=20
> > > >=20
> > > > It's almost like, with Tomcat, when my valve code calls setUserPrin=
cipal(), Tomcat doesn't "care" whether the user that I'm asserting actually=
 exists or doesn't exist in the Tomcat realm?
> > > >=20
> > > >=20
> > > > Again, as I said, I'm new, so I may  (and probably am) misunderstan=
ding something about how Tomcat security works...
> > > >=20
> > > >=20
> > > > Sorry for the longish post, but I hope that things are clearer now?
> > > >=20
> > >=20
> > > Better a long and clear post, than a short and obscure one.
> > >=20
> > > Two things :
> > >=20
> > > I am not really a Tomcat expert, and this will need to be corroborate=
d by one of them, but=20
> > > it seems that I remember a not-too-long-ago thread in this same forum=
, in which it came=20
> > > out that if there is already a user-id known to Tomcat, it will not e=
ven bother to run its=20
> > > own authentication code.  That is said in non-expert terms, but I'm s=
ure someone here will=20
> > > correct that if need be.
> > >=20
> > > 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=20
> > > connector to Tomcat, then this connector will automatically pass the =
authenticated Apache=20
> > > user to Tomcat with every request, and you would not need your Valve.
> > > Have a look at the TomcatAJP <Connector> description, attribute "tomc=
atAuthentication".
> > > http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html
> > >=20
> > > This being said, make sure that the connection between Apache and Tom=
cat is reasonably=20
> > > secure (for example, within the same host or over an internal network=
), because the AJP=20
> > > protocol (although in part binary) is not itself encrypted.
> > > No user password is passed over it (only the user-id), but a hacker c=
ould in theory=20
> > > intercept the packets, and replace one user-id by another.
> > >=20
> >=20
> >=20
> > Hi Andre,
> >=20
> > Thanks for that info re. AJP.  I will definitely take a look (test) tha=
t, 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 coul=
d use my valve, but if they use mod_ajp, then they wouldn't need the valve!
> >=20
> > 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.
> >=20
> > Thanks again for all the great info!
> >=20
> > Jim
> >=20
>=20
>=20
> Hi Andre (et al),
>=20
> I've been testing with AJP and Tomcat.  From what I've read, it looks lik=
e that tomcatAuthentication looks for an HTTP header, "REMOTE_USER" that co=
ntains the userID that it will authenticate/assert into Tomcat.
>=20
> At this point, I can proxy to Tomcat using AJP fine, but it looks like th=
e user is not being authenticated within Tomcat.  It looks like to me, the =
"REMOTE_USER" HTTP header is "(null)", instead of containing a userID.
>=20
> 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.
>=20
> Does anyone have a reliable way to populate the REMOTE_USER header, when =
using AJP connector?
>=20
> Also, I'm a little unclear about whether the "tomcatAuthentication" in th=
e AJP connector should be set to "true" or "false"?
>=20
> 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 con=
nection protocol.
>=20
> Thanks, and sorry for all of the questions!
>=20
> Jim


Hi,

Also, BTW, I just did a test where, in the Apache httpd.conf, I hard-coded =
REMOTE_USER header using RequestHeader. =20

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org