tomcat-users mailing list archives

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

So is the problem that Tomcat doesn't provide the same pluggability that
the other (full JEE servers) do?

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

Because the pluggable 3rd party agent handles that for you?

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

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)

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

You can always contribute it back.


> Thanks
> Marc
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message