Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 brian@pingtoo.com does not designate 217.154.193.216 as permitted sender)
Message-ID: <52A85926.4040009@pingtoo.com>
Date: Wed, 11 Dec 2013 12:23:02 +0000
From: Brian Burch <brian@pingtoo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: Single Signon without Cookies
References: <52A74BCC.1030503@pingtoo.com> <52A75730.9030002@apache.org>
In-Reply-To: <52A75730.9030002@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org