[cas-dev] Single Sign out with Domain Cookies

[Scott Battaglia]

Trenton,

Domain cookies would be difficult for a few reasons:

1. We do log out when the Ticket Granting Ticket is expired, not just when
you log out.
2. There are backend services that aren't necessarily web-based.
3. We can't assume that all applications will be under the same domain.

The only advantage that I see would be that it would allow us to handle the
situation where applications don't store any session information on the
server side (which we currently can't handle). Unfortunately, it wouldn't
handle the other situations ;-)

-Scott

On Wed, Mar 19, 2008 at 6:20 PM, Trenton D. Adams <trenta at athabascau.ca>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Guys,
>
> Kind of brain storming here...
>
> I'm just curious if anyone has thought of doing single sign out with
> domain cookies, as opposed to the current method in CAS 3.2?  i.e. All
> services use domain cookies, and CAS expires them all upon logout.
>
> One would have to implicitly trust every server in the domain.  If you
> can't do that, then this would not work for you.
>
> Are there any potential security issues that you can think of with this?
> ~ Obviously we won't make the CAS cookie a domain cookie!!!
>
> Any reasons for or against such a mechanism?
>
> I can think of one reason why the current CAS method may be better in at
> least one instance.  I'm assuming that CAS does callbacks to clients
> when it's TGTs timeout from inactivity (in addition to forcing a
> logout), is that correct?  If so, that is one feature that is desirable,
> that domain cookies would not have.  Perhaps combining the two features
> may be desirable?  i.e. Languages that don't support the client callback
> would make domain cookies, which CAS would delete upon logout.
>
>
> FYI: This domain cookie mechanism would not work with servlet based
> applications, without a little work.  But, I'm assuming there is a Java
> CAS client that already supports the CAS 3.2 single sign out???  Anyhow,
> the Java Servlet spec requires cookies to be named JSESSIONID.  I'm not
> sure if this is the case with any other CSo, servlet containers do not
> allow you to change the cookie name.  Or should I say tomcat does not,
> as it is a reference implementation.  Perhaps others do.  So, something
> would have to sit in front of each servlet context, and rename
> JSESSIONID to a configured name (not the context name as it could be in
> the root '/'), going both in and out, and the path would also need to be
> manipulated going to the browser.
>
> - --
> Trenton D. Adams
> Systems Analyst/Web Software Engineer
> Navy Penguins at your service!
> Athabasca University
> (780) 675-6195
> :wq!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFH4ZG8y1ltpSlXkf8RAjYlAKCB7bDU8aluk4Vu9SJ+ZKf/xGizkwCfRCmC
> wQxjyv4FzB+aUXHqc/IONnw=
> =vd23
> -----END PGP SIGNATURE-----
>
> __
>    This communication is intended for the use of the recipient to whom it
>    is addressed, and may contain confidential, personal, and or privileged
>    information. Please contact us immediately if you are not the intended
>    recipient of this communication, and do not copy, distribute, or take
>    action relying on it. Any communications received in error, or
>    subsequent reply, should be deleted or destroyed.
> ---
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>



-- 
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080324/40f0180d/attachment-0001.html