Rainer Jung wrote:
Am 31.03.2015 um 22:47 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 3/31/15 3:41 PM, André Warnier wrote:
I have a question of my own.
??!
+1
Tomcat 6.x/7.x/8.x.
Until now, we have been using mostly the Apache httpd mod_jk
connector to Tomcat. And we have been using the Tomcat AJP
Connector's 'tomcatAuthentication="false"' setting, to "propagate"
the authenticated user from httpd to Tomcat.
Now we have a case where we must use the Apache httpd
mod_proxy_ajp connector instead of mod_jk, and I want to make sure
that the working of the AJP Connector's attribute
"tomcatAuthentication" remains the same in that context. Does it ?
Not automatically IIRC.
Mostly the same.
And do we have to specify anything special in the httpd
configuration for mod_proxy_ajp to make it so, or is the
authenticated user always passed to Tomcat by default, as seems to
be implied here :
http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html Attributes
?remote_user 0x03 String
mod_jk sends the user's authentication information over in the
REMOTE_USER field, so you'd just make sure that the REMOTE_USER field
is being sent using mod_proxy_ajp. I'm not exactly sure what the
incantation is for telling mod_proxy_ajp to send that field.
You could try to see if you get a REMOTE_USER without any additional
configuration on the httpd side. Note that REMOTE_USER will not show
up if you call request.getAttributeNames -- you have to explicitly
call request.getAttribute("REMOTE_USER") if you want to get it back.
mod_jk and mod_proxy_ajp by default forward the "user" member of the
request_rec struct as the AJP attribute SC_A_REMOTE_USER to Tomcat. If
"tomcatAuthentication" is false, Tomcat uses this attribute instead of
doing its own authentication.
With mod_jk you are a bit more flexible, because you can e.g. configure
it to take the user name from an Apache environment variable you choose
instead of where Apache puts it when its builtin authentication
procedures are used. But for the typical setup it should work for both
modules out of the box.
Regards,
Rainer
Many thanks for the confirmation.
@Chris : it looks like you are thinking a bit more complicated than it is..
But your thinking may come in handy for my follow-up question :
Now suppose that the front-end Apache authenticates the user, and in addition to an
authenticated user-id, it is also able to collect a number of "groups" to which this user
belongs. And suppose that being a mod_perl guru at the Apache httpd level, I could collect
these groups and could use just about any scheme known to man, to pass them on to Tomcat
in the proxied request.
In what form would I need to do that, so that Tomcat could use these groups as "roles" for
that user ? And how would Tomcat (or a Tomcat-based application) get to know about these
roles/groups for that user ?
(for example if the webapp were to call : request.isUserInRole("x") ?)
(and by the way, apart from calling isUserInRole() and getting a true/false answer, is
there a way for the webapp to get a list of all such "roles" for the user, without knowing
them in advance ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
