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