tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <>
Subject Re: Setting JK_REMOTE_USER help
Date Thu, 17 Jun 2010 11:34:02 GMT
>> 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
> 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 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.

>> 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?
> 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 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.

>> 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.
> 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.

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!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message