Am 01.04.2015 um 09:43 schrieb André Warnier:
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 ?)
I think there's no trivial way to do that. By default the "Principal"
retrieved via AJP13 will have no roles.
But Mark just committed for 8.0.21 and the forthcoming 7.0.61 a new
feature "tomcatAuthorization", see
http://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html.
If it is set to "true", then the name of the principal will be used to
look up the roles in whatever realm is configured in Tomcat. That is not
the same as setting them on the proxy side though.
We could add a custom attribute to AJP like we did before to transport
roles. But where would that attribute get its content from?
As far as I can see, there is no official place in Apache httpd
structures where group or role info is kept around. The same modules
that retrieve group info (from files, ldap, etc.) are also responsible
for checking authorization, so they keep that info in module individual
private data. Some of them use env vars to publish info, especialy the
ldap module and it seems also the dbd one. Adding a custom AJP attribute
would therefore be of limited (but non-void) use. You would have to fill
a custom env var with the list of roles using mod_setenvif, mod_rewrite,
mod_perl or hopefully ldap or dbd already provide the data you'd want to
pass along. Do you think that would be useful?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
