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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: OpenPGP digital signature
