On 14/10/11 04:04, Brian Burch wrote:
I will go quiet for a few days while I checkout 6.0.28 and get it to
build.
Phew! That took me longer than I expected.... I got 6.0.28 to build,
then ran all the unit tests, then debugged the SSO logic and started to
understand it.
Then I (coded/debugged/understood-better) for a while and eventually
arrived at a new version of NonLoginAuthenticator that did exactly what
I wanted. It is now running on my production system.
However, I wanted to make a contribution to the project and so started
stripping down my two simplest webapps as a demonstration case. I
quickly realised my fix against version 6 probably wouldn't be very
interesting to the tomcat developers, so I checked out the latest trunk
(aka version 8) and started all over again with the servlet spec 3.0.
Although the current source for NonLoginAuthenticator is identical in
the trunk, the behaviour of my webapps wasn't quite the same. It took a
while to untangle, but here is a summary of my conclusions:
1. The servlet spec states that the web.xml XML schema for
<login-config> multiplicity was changed from "optional" to "0 or more",
i.e. it has never been a mandatory element.
2. The servlet spec states the <auth-method> sub-element must be one of
the list: BASIC, DIGEST, FORM, CLIENT-CERT, or a vendor-specific
authentication scheme, i.e. tomcat's use of the internal value "NONE"
should be taken to be a vendor-specific implementation method.
3. I conclude that tomcat is correct in permitting a webapp to be
deployed under a web.xml that a) has security constraints defined, and
b) does NOT have a login-method defined. The servlet spec does not
define how this case should be implemented because it does not define an
<auth-method> of NONE.
4. Tomcat associates the
org.apache.catalina.authenticator.NonLoginAuthenticator class with a
webapp that has not defined a <login-method>. The latest (and also very
old) source has a trivial authenticate method that ALWAYS returns true.
Unfortunately, the multiple comments in the code are confusing (to me,
at least) about the semantic meaning associated with true and false
return values (see next step). However, the code that calls it in
AuthenticatorBase.invoke implies a value of true means the user is
successfully authenticated, while false implies an HTTP error status has
already been assigned to the response.
5. In the case where the SSO valve has NOT been associated with a Host,
it apparently does not matter that NonLoginAuthenticator.authenticate
always returns true (implying, I think, that the user is authenticated)
because AuthenticatorBase.invoke will eventually check whether the
resource is protected. If it is protected, then there will be no
associated java.security.Principal to provide a role that might be
permitted, and therefore access will be forbidden. (In my view, this is
the right outcome but for the wrong reason.)
6. In the case where the SSO valve is associated with the Host,
behaviour is different to step 5 above: if the remote user has already
authenticated to a different webapp, then the browser will send the SSO
cookie to all webapps in the same Realm. AuthenticatorBase will use the
cookie to find the SSOEntry instance and retrieve the associated
security Principal. This allows determination of permission to access
the constrained resource.
7. I believe there are two real (rather than philosophical) problems
with the existing logic:
7.1. Because the NonLogin webapp Session is never registered with the
existing SSOEntry, its own <session-timeout> will NOT be honoured. In
fact, once the last SSO-participating Session is expired, the NonLogin
webapp will effectively become instantly unauthenticated and so its next
protected resource access will be forbidden.
7.2. If SSO is used with a browser that does not accept cookies (I
/think/ this situation is supported), then NoLogin webapps will never be
able to "borrow" an existing SSO authentication as described in 6 above.
Have I overlooked anything important?
If I've got it right, should I tidy up and submit my demo webapps and
the proposed fix?
I haven't yet found any unit tests for the SingleSignOn valve... I would
have liked to write some tests for my proposed change, but without an
SSO environment, they (it?) would be trivial and pointless. Is the SSO
valve tested under some other framework than junit?
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
