On 10/12/13 18:02, Mark Thomas wrote:
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).
WDYT?
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.
I didn't want to put forward my own opinion until I heard your thoughts.
I basically agree with Martin G in this case - anyone who cares about
authentication (or any other kind of) security ought to be using the
cloak of SSL, in which case the "inside" security isn't so important. As
he points out, unwrapping the SSO session ID from a cookie isn't that
difficult compared to reading it off the url in the HTTP response.
Nevertheless, we haven't had any "it doesn't work" or "why do I have to
use cookies" questions on the users list, so there can't be much need
for the "feature" in the real world. I'll review the unit tests and make
sure we only have cases that work properly under the existing
implementation.
Thanks,
Brian
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
