tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Single Signon without Cookies
Date Tue, 10 Dec 2013 18:02:24 GMT
On 10/12/2013 17:13, Brian Burch wrote:
> Some background first: I made a lot of changes to the Authenticator test
> classes some time ago. That led to changes to some of the Authenticator
> classes. The test classes are basically in pairs - "with" and "without"
> SSO.
> I decided to revisit the entire test suite, trying to make them more
> self-consistent and self-documenting. I hoped to remove redundant tests
> and perhaps add some missing edge cases at the same time.
> I started work on TestSSOnonLoginAndBasicAuthenticator and found a test
> that ended successfully, but for the wrong reason! (I take the blame.)
> As I changed the test to do what it claimed, I discovered that
> org.apache.catalina.connector.Response.encodeURL (implements
> javax.servlet.http.HttpServletResponse) has logic to add the session ID
> to the url in the jsessionid parameter, but there is nothing to add the
> SSO session ID.
> I decided to RTFM... Single Signon is described briefly in the Servlet
> Spec, but is not defined. Tomcat implements SSO as a Valve. It is
> described in the tomcat docs Reference section,
> docs/config/host.html#Single Sign On
> ... which has six bullet points, the last of which says:
> "The Single Sign On feature utilizes HTTP cookies to transmit a token
> that associates each request with the saved user identity, so it can
> only be utilized in client environments that support cookies."
> I had always thought encoded url's were equally acceptable, but I was
> mistaken. The documentation is clear and consistent with the
> implementation.
> I need to fix my faulty unit test(s), but before I do any work I would
> like to ask whether the restriction "SSO is only available to clients
> that accept cookies" is reasonable and necessary. My initial thought is
> that it wouldn't be too hard to support SSO within encodeURL (the real
> work is done in Response.toEncoded).

I think that session IDs in URLs are a bad idea because of the security
implications. They are only supported because the Servlet spec says they
have to be. Given that there is no spec requirement to support SSO
session tracking via URLs I don't think we should.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message