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.
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.
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.
A naive linked question : is the <Realm> a purely Tomcat thing, or is it mandated by the
Servlet Spec ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
