[cas-dev] Single Sign out with Domain Cookies
Trenton D. Adams
trenta at athabascau.ca
Thu Mar 27 15:50:26 EDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I had forgotten about this thread. lol
Those are good points Scott. So really, the best idea is to just
implement a client that supports it, in the event that we use a language
that doesn't have a supported client.
Scott Battaglia wrote:
| 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:
|
| 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.
|
|>
__
~ 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
|>
| ------------------------------------------------------------------------
| _______________________________________________
| cas-dev mailing list
| cas-dev at tp.its.yale.edu
| http://tp.its.yale.edu/mailman/listinfo/cas-dev
- --
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
iD8DBQFH6/qCy1ltpSlXkf8RAsHGAKD/CXNf0U6lH8X95WOO6j7aUv6/ZgCgrKbo
HLDfUKYoNw1VesPDF+HC5Yc=
=nnEp
-----END PGP SIGNATURE-----
More information about the cas-dev
mailing list