[Tomcat-users] Setting JK_REMOTE_USER help

You should not need to do that, it should be automatic.
Just make sure that in the Tomcat <Connector> for AJP (in server.xml), you set the attribute
tomcatAuthentication="false"

If the request is authenticated by Apache, mod_jk will (always) pass it internally to
Tomcat, along with the request. If the above attribute is set, then Tomcat will also
"believe" this user-id, and not try itself to authenticate the user.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Also, it is *really really really* helpful, when you post a question, that you would
specify the precise versions of software you are talking about.
Like :
Apache httpd version : 2.2.3
Tomcat version : 5.5.21
mod_jk version : 1.2.18
.. the documentation .. : the documentation page at : http://tomcat.apache.org/.....

It helps people here figure out if you have a real problem, or if your are using an old
version with a know bug, or if you are looking at some incorrect instructions etc... It
helps them getter a better idea, quickly, of where the issue may be. And it shows that
you have at least done some homework yourself, before asking other people to spend their
time trying to help you.
All of the above have the indirect effect of motivating more people to help you faster, so
it is also to your own advantage.


André Warnier wrote:
see here :
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
(at the end)
(if of course you are using Tomcat 6.0)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

OK, so the good news is that setting tomcatAuthentication="false" did
get tomcat to not prompt me for authentication. The bad news is that
it looks like that this doesn't actually set the user's context
because I am receiving unauthorized messages from the application
which relies on container security. I have an LDAP realm setup, is
there a configuration to bridge this gap? If not I THINK I can write
a "wrapper" realm that will take the user id attribute and "fake" it.
Any thoughts?

As for the versions, thanks for the reminder:
Tomcat 6.0.26
Apache 2.2.15
mod_jk 1.2
CentOS 5.5



Thanks
Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

When Apache authenticates a user, it gets a user-id, like "marcb".
That is what mod_jk passes to Tomcat, nothing else. That is one "A" of "AAA", which
stands for Authentication, Authorization and Access-control.
Authorization is another step, which can only be done by Tomcat in this case, because the
concepts do not really match between Apache httpd and Tomcat (Apache has users and groups,
Tomcat uses "roles").

I have an LDAP realm setup, is
Since you have Apache in front already, you could do the whole AAA under Apache, and
remove anything you do not really need from Tomcat.
What do you really need to know about a user at the Tomcat application level, apart from
his user-id ?
(Or you could do the total opposite : do the whole AAA in Tomcat)
The whole thing is rather flexible, and what you choose to do where is very much depending
on your circumstances.
(Like : do all accesses to Tomcat go through Apache first ? is the link between Apache and
Tomcat secure ? are there resources served by Apache directly, and do some of them need
AAA ? etc..)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

OK, come context first:

What I'm trying to do is integrate a Commercial Off The Shelf (COTS)
application that relies on container security into a Web Access
Manager (WAM). In a typical WAM deployment there are AAA is broken up
into multiple layers:

Web Server - Authentication (via the WAM) and course grained
Authorization (can the user access this app?)
Application - Fine grained Authorization aka Entitlements (can the
user perform task x?)

Since the authentication is done at the web server but the
entitlements are done by the application the web server needs to tell
the application server who the user is and the application server then
needs to fulfill the J2EE contract by providing information about the
user to the application.

In commercial application servers (Weblogic, WebSphere, JBoss) this is
done with an agent of some kind that satisfies the application
server's security requirements (usually by phoning home to the WAM to
validate the request). However commercial WAM products (SiteMinder,
OAM, etc) don't provide an "agent" for Tomcat. Given that what I'm
working on is a POC I'm not overly concerned with security as in
production this app will likely run on weblogic but for my purposes
Tomcat is a better pick for now.

That being said, the sequence of events should be:
1. Web server authenticates the user (works)
2. Pass the context to Tomcat (works)
3. Tomcat calls the realm to retrieve the user information and set
the context (doesn't presently occur)

#3 appears to be the issue. Authenticaiton and Authorization should
be separate steps entirely in order to satisfy the J2EE contract in an
enterprise environment (which often involves WAMs).

So it doesn't sound like there is a configuration way to handle this.
I think I'll try hacking around to see if I can solve this with some
kind of custom Realm.
mod_jk 1.2.30
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

On 6/16/2010 10:58 AM, Marc Boorshtein wrote:

...
Keep in mind that Tomcat is not a full j2ee server; it's a "servlet
container", so may not meet some of the requirements you have for your
app if they are part of higher-level j2ee specs.

D

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Sent from my iPhone
Yes, however there are security methods in the sevrlet spec
(getPrincip, isUserInRole). Tomcat+mod_jk should satisfy these contracts

Thanks
Marc


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Well, no. It passes a user-id to Tomcat.
For Tomcat, the user-id may be part of a "context" (although I believe that for Tomcat
also, the word "context" means "an application".)
Probably, more like yes. Tomcat, as far as I know, creates a userPrincipal object, which
contains the user-id and other information if available.
To look at this from a very strict point of view, the whole area is already a bit
stretched. Tomcat has this notion of "roles" (because the Servlet Spec has this same
notion). But if you look at common authentication schemes, like NTLM or LDAP, they do not
have this notion. It is possible that some authentication "Realm" (another servlet-engine
specific use of the term) "translates" the NTLM notion of "user group" (or some LDAP
attribute) into Tomcat's notion of "role" (and in fact they often do). But that is a
stretch. Unavoidable, because servlet engines do not know about "user groups", but stretch
nevertheless.

I suppose it would be boring if everyone agreed on the same notions all the time.

Basically, nobody stops you from retrieving some LDAP attributes of the user at the Apache
level, and passing them over to Tomcat by adding one or more custom HTTP headers to the
request (or a request attribute, as explained here :
http://tomcat.apache.org/connectors-doc/reference/apache.html
search for "JkEnvVar").
And then at the Tomcat level, adding a servlet filter which retrieves these
header/attributes and stuffs them inside the UserPrincipal object, to satisfy Tomcat's
isUserInRole() call (with some approximation due to my incomplete knowledge in these matters).

Just an idea to avoid having to access LDAP twice.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

The issue here is that the servlet specification specifies a way to
check what "role" a user is in. How that role is implemented (LDAP
group, user attribute, pulled out of a hat) doesn't really matter. An
application's code can write "if (request.isUserInRole("X")..." and
should work. It should also work whether you are using tomcat to do
authentication or something else (ie Apache+mod_jk or federation).
The problem with the Realm system is its designed with the assumption
that tomcat is doing the authentication which is not a valid
assumption in an environment where the authentication is seperated
from authorization. The entire point of container security is that as
a coder I don't have to worry about how any of this is implemented.



LDAP as a service is generally fast enough to be a negligable part of
the AAA process. It looks like subclassing the JNDIRealm is going to
be the easiest way here. I don't need perfect, just working for this
POC. Spending 20 min on some code is still easier then getting
weblogic up and running.

Thanks everyone!

Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

The problem with Tomcat is that all too often it doesn't do what people
expect it should do*.


p

* Or maybe the problem isn't Tomcat.

I'm not looking to start a holy war here, but is there anything
incorrect in what I said? Tomcat is a servlet container, the servlet
API is a contract between the container and the developer, the
contract specifies how a developer would access role information
regardless of the implementation. Since the Realm implementation
assumes that Tomcat is doing the authentication and breaks when it
isn't Tomcat, isn't that a violation of the contract? It's open
source, so I'm not complaining or demanding anything. I think I know
how to do what I need however that doesn't change the facts of the
situation that Tomcat does not have the built in capability for a
standard realm to simply retrieve user infomation as opposed to
authentication AND user retrieval that would enable Tomcat to maintain
its compliance while being fronted by Apache.

Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Yes.

You made a sweeping statement about container managed security which
implied that things should just work. Someone has to make them work.

As an app developer you might not have to worry about how the bits
behind the API work, but some admin has to configure it properly.

No. I don't think it is.

Your specific need might not be handled by the Realm implementations
supplied with Tomcat, but that's not proof that either design of Realms
is flawed or that Tomcat isn't spec compliant.

The explanation you provided in your 3rd email doesn't sound like
'simply' to me. You also state that other servlet containers need a 3rd
party agent to achieve the desired result.

If your complaint is accurate then the other 3 servers you name must
also 'violate the contract' because they don't provide what you need out
of the box.


p

No argument there. Thats what I started trying to figure out. As I
said this is a Commercial Off The Shelf application that was built to
the Servlet API specification. I didn't develop the app but given the
app is written to the Servlet API there are certain expectations do to
how the api is written.

The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the
authentication unless you do a 100% custom realm. This is ultimately
how I solved my issue (I make a copy of JNDIRealm and took out the
credential check). Why I feel this is an issue with Tomcat's
implementation is explained below.
The way WebSphere and Weblogic work (I've not done this integration
with JBoss so I can't speak to it) there is a security subsystem that
seperates user & group retrieval from actual authentication. The
reason for this is to allow third party authentication providers to be
plugged into the system without changing how the application server
retrieves user information.

Here's the flow of how WebSphere with SiteMinder integrates:

1. User accesses URL pointing to IHS (an apache variant)
2. SiteMinder "agent" in IHS authenticates and authorizes the user
3. WebSphere plugin (which would be a peer to mod_jk) forwards the
request to WebSphere
4. WebSphere executes a "TAI" (I forget what the acronym stands for)
that is provided by the vendor (in this case CA) validate the request
and provide WebSphere with the user's principal. Websphere also
exposes its API to the TAI for retrieving user information for
building the Principal object.
5. WebSphere executes it's security configuration as it executes the request

It is a similar process for Oracle Access Manager and IBM Tivoli
Access Manager as well with Oracle Weblogic. The critical point here
is that if you swapped out any of the above Web Access Managers (or
even replace them with Federation systems like Ping) you don't change
how WebSphere RETRIEVES user information and do not need to recode the
application. The only portion that gets changed is the third party
integration tool. This was the intent of including security
components in the Servlet API.

So do I think Tomcat needs to support every WAM or Federation system?
No, that would be completely unreasonable. Do I think that Tomcat
should not require a re-coding of a component that has nothing to do
with authentication when changing authentication systems? Yes. I do
think that is reasonable. I think its reasonable that if I provide
the authentication mechanism that Tomcat should be able to accept it
and retrieve the user information without being forced to do the
authentication on its own.

I want to be clear. I think Tomcat is a great product and like all
great products it has it's strengths and weaknesses. Even between the
1/2 hour of coding I had to do to get the solution working, the bit
more coding I'll have to do once I move from Basic authentication to
form based and the very interesting conversation on this list it still
took me less time to do it in tomcat then to get Weblogic setup,
installed and configured!

Thanks
Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

So is the problem that Tomcat doesn't provide the same pluggability that
the other (full JEE servers) do?
Because the pluggable 3rd party agent handles that for you?

Surely that's subjective, it depends entirely on the authentication &
authorization mechanism you want to use. I wouldn't expect Tomcat to be
able to effect authorization when I've authenticated by Internet
Telepathy(tm). (To pick a wildly unreasonable alternative)

You can always contribute it back.


p

Hi.
I must say that, with my limited knowledge of the Tomcat internals taken into
consideration, I tend to agree with Marc in this case, if he is right in claiming that the
Tomcat Realm mixes authentication with authorization and does not allow to separate the two.
At the very least, I would expect the Realm to check first if the request already has a
user-id, and skip the authentication part in such a case.
There are many cases out there were Tomcat is only a part of a more complex system, where
a network-wide authentication is required, while the authorization part may still be one
that only Tomcat can do.

A naive linked question : is the <Realm> a purely Tomcat thing, or is it mandated by the
Servlet Spec ?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

That is how Tomcat Realms are designed. This is consistent with the
Servlet sepc that leaves the implementation details entirely to the
container. If Tomcat required all authentication requests to be made via
carrier pigeon then that would be spec complaint providing the correct
information was exposed via the API defined in the spec.
Easier said than done. The Realms deliberately have no visibility of the
request or the response. The Authenticators extract the username and
password, pass them to the realm to obtain an authenticated Principal
(with roles) and then the Authenitcators populate the attributes that
then support the calls in the Servlet API.

The way to handle this (probably) is to modify the Authenticators
(hopefully just the base class) to check for an already authenticated
user. If one is found, use the realms just to get the roles. The
implementation for that is already in place. It just needs adding to the
interface and the visibility changed. Then you just need to figure out
how to merge the existing Principal (that may have roles) with the new
one that has the roles from the Realm.

Tomcat 7's internal API has deliberately been declared as volatile inthe
docs so now is the time to make these changes. Patches welcome.

Note this won't get ported back to 6 due to the API changes required.
100% pure Tomcat.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Yes, it is as long as Tomcat is not combined with Apache or IIS. Once
Tomcat offloads the authentication to Apache/IIS there should be a
mechanism in place to still continue the authorization framework.

I'll take a look at the tomcat 7 api and see what I can do.

Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Well, he said he's managed to make it work, so it must be possible to
separate the two.

As far as I could tell, his major complaint was that it didn't just work
'out of the box' (but it needs a 3rd party agent in the other examples).
He also threw in a complaint about contract violations which I didn't
think was fair, or valid.
I don't think the Servlet Spec defines a situation where authentication
and authorisation occur separately, but I'm happy to be corrected.

The Spec defines some methods of authentication & authorization (BASIC,
FORM, etc), and some objects associated with the request which describe
some properties of an authenticated user principal, and it's roles.

It also makes statements about what Containers must provide API wise,
but it doesn't say how.

It's a Tomcat thing, as are the Authenticators and Valves.


p

I got it to work by writing custom code (namely I commented out the
"bind" in the JNDIRealm). Thats OK for my own needs building a POC
but I wouldn't use it in production.
So apparently you didn't actually READ what I wrote in my previous
email. I would suggest you do as it is quite detailed and pinpoints
exactly what my "complaint" is.
This is what the "base" problem probably is. The authentication
mechanism doesn't have the conext to make decisions
Yes. Thats my point. It should be transparent. I (or any developer)
that writes my app to the spec should not have to recode their
applicatoin because the container doesn't handle a common
configuration change such as externalizing authentication.

I'd be happy to share how I was able to get this to work...where is
the best place, the wiki?

Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Steady now. You might not like my take on it, but I read it.

That's a fairly sweeping statement you've made there.

It is. You've still got to plug something into the back of the API to
make it do what you want. If what you want is something complicated
then maybe Tomcat won't do that without modification, as you've found.

You're talking about having to change your app, but you've only
described having to make modifications to a Tomcat internal support class.

You seem to be saying that Tomcat has a compliancy issue - IMO the
problem with leaving that unchallenged is that it breeds
misunderstanding that would land back here sometime later.

I don't think it's reasonable to mix an argument about spec compliancy
with an point about something that isn't covered by the spec - even if
it is a common requirement.

Yep.


p

(Enough now.)

We can agree to disagree on this one. Either way Tomcat 6 can not
support a very common pattern in application deployment. I think it
would be valuable for Tomcat to support this model and will work on
I'll take a look at the 7 code to see how I can help.

Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org