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.
p
> Thanks
> Marc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
|