Rainer Jung wrote:
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?
Let's say that from my point of view, that new "tomcatAuthorization" feature is "good",
because it is an additional step in the "right" direction. In effect, it (optionally)
splits the authentication from the authorization phase, which makes the whole thing more
flexible.
The underlying issue here is that the concept of "groups" used in most of the non-Tomcat
area, is distinct of the concept of "role" in Tomcat.
In general terms, what I am trying to bring about, is this :
In recent times, there is an increasing need in large organisations, to "standardise" the
web-related authentication/authorization methods, and provide SSO-like solutions which
work seamlessly, no matter what kind of underlying platform is being used.
And a number of schemes and products have been appearing to fill that need, open-source
and free as well as commercial.
It is already possible in a number of ways, to authenticate and provide SSO for users, on
each platform separately (such as for example if they all use OpenId, or all use NTLM, or
all use SPNEGO/Kerberos).
And at the Tomcat level, there already exist a number of solutions which will retrieve for
example a list of AD Groups to which the user belongs, and allow to use them under Tomcat
for authorization (the real details of this are still unclear to me, I have never used
this yet).
But the way all these solutions work, is that each server basically does its own AAA
separately, even if they all use the same back-end in the end.
This is inefficient in cases for example where all accesses to Tomcat, first go through a
front-end which has already done the user AAA (such as Apache httpd or IIS).
Passing the user-id is the first step, but it is not enough.
At the Apache httpd level, we have developed our own "universal" AAA/SSO module (using
mod_perl), which can be configured according to the circumstances to use any number of
back-ends available at some customer site, and provide some kind of "unified" AAA/SSO no
matter what, to the underlying applications (ours).
I am basically now grappling at a concept, to try to extend this to Tomcat-based
applications, which are accessed only through such an Apache httpd front-end running our
AAA/SSO solution.
The basic idea is not so much the concept of "role" under Tomcat, which determines whether
a given user gets to run an application or not.
It is that the application running under Tomcat, should be able to obtain some user
"attributes", which determine how the application behaves to that user. (*)
And since this information is already obtained at the front-end Apache httpd level, and
/could/ be forwarded to Tomcat, it seems a pity (and inefficient) that the Tomcat-based
code would need to re-retrieve this same information from the same or some separate source
(which then needs also to be constantly synchronised).
I understand that this is different from the concept of roles in Tomcat. I was just
trying to understand if it makes sense or not, to try to use the existing Tomcat roles
concept and implementation, for a purpose that is not really its original one.
(*) in terms of authorization, if this user was not allowed to run this application, he
would never even get this far, he would already have been blocked at the front-end level.
Imagine for example the application under Tomcat as a search engine, which would have to
return different results for the same search, depending on the user's group.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
