Am 01.04.2015 um 12:22 schrieb André Warnier:
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.
Understood. To find out, what the best way of forwarding these user
attributes is, IMHO one would first have to identify the right target
concept in the Java webapp world, e.g. realm/role or whatever. If your
goal is to be completely generic, then all we can do is forward info as
request attributes and then some adapter code would need to map the
attributes into the right objects per concept.
Forwarding as request attributes is already possible with JkEnvVar.
Other ideas?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
