On 17/06/2010 13:26, André Warnier wrote: > Pid wrote: >> 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. >> >> > Hi. > I must say that, with my limited knowledge of the Tomcat internals taken > into consideration, I tend to agree with Marc in this case, if he is > right in claiming that the Tomcat Realm mixes authentication with > authorization and does not allow to separate the two.
Well, he said he's managed to make it work, so it must be possible to separate the two. As far as I could tell, his major complaint was that it didn't just work 'out of the box' (but it needs a 3rd party agent in the other examples). He also threw in a complaint about contract violations which I didn't think was fair, or valid. > At the very least, I would expect the Realm to check first if the > request already has a user-id, and skip the authentication part in such > a case. The Realm doesn't see the request at all. > There are many cases out there were Tomcat is only a part of a more > complex system, where a network-wide authentication is required, while > the authorization part may still be one that only Tomcat can do. I don't think the Servlet Spec defines a situation where authentication and authorisation occur separately, but I'm happy to be corrected. The Spec defines some methods of authentication & authorization (BASIC, FORM, etc), and some objects associated with the request which describe some properties of an authenticated user principal, and it's roles. It also makes statements about what Containers must provide API wise, but it doesn't say how. > A naive linked question : is the <Realm> a purely Tomcat thing, or is it > mandated by the Servlet Spec ? It's a Tomcat thing, as are the Authenticators and Valves. p > --------------------------------------------------------------------- > 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
