At my organization, we run a customized version of CAS (both client and server
customized) which supports three forms of single logoff (SLO). To participate
in SLO, when a CAS client redirects the user to the CAS server, it includes one
of the three parameters listed below. When the CAS server creates the service
ticket, it remembers the URL, the service ticket, and the SLO information
passed in that extra parameter. When the user accesses /cas/logout, the system
retrieves this list of service URLs for the current session and performs the
required action for each.
The first method (logout callback) is, IMHO, the "best"... the others are
available to support clients that may not be able to handle the logout callback
method.
1) logoutCallback
* When initially redirecting to the CAS server, the CAS client passes a
callback URL to the CAS server. CAS server remembers this URL.
* When user requests logout, CAS server directly contacts CAS client at the
logoutCallback URL. The original service ticket sent to the CAS client for
login is presented again, this time prefixed with a dash ("-"). The CAS client
recognizes this as a logout callback and invalidates the session associated
with the service ticket.
2) iframeLogoutUrl
* When initially redirecting to the CAS server, the CAS client passes a
logout URL to the CAS server. CAS server remembers this URL.
* When user requests logout, CAS displays a logout page containing a small
IFRAME HTML tag that references this URL. For some implementations of the CAS
client, or of applications that reside below the CAS client, this is easier to
implement than the logoutCallback. Also, sometimes firewall rules or routing
may prevent direct communication from the CAS server to the CAS client.
* The iframeLogoutUrl should display a small HTML page containing a "logout
success" message or icon. We never fully defined what this should look like.
* The iframeLogoutUrl structure is defined completely by the service. It
should be URL-encoded before being passed to the CAS server.
3) userLogoutUrl
* When initially redirecting to the CAS server, the CAS client passes a
logout URL to the CAS server. CAS server remembers this URL.
* When user requests logout, CAS displays a logout page containing a link
to the userLogoutUrl and a message instructing the user to click on the link.
Clicking the link pops up a new window pointing to the URL. As with the
iframeLogoutUrl, this causes the user's browser to initiate the logout process
with the external service/resource, which is sometimes easier to implement than
the logout callback.
* The userLogoutUrl structure is defined completely by the service. It
should be URL-encoded before being passed to the CAS server.
By the way... I have run into slowness with our legal department regarding
releasing our code as open source. It's been approved by all necessary
managers, but we're still waiting for the final clearance from legal. The code
I'm talking about is a fully-featured ISAPI filter / Apache module (portable
core code with customized builds for Windows/Linux and Apache/IIS) and an
HttpModule for .NET (equivalent of a J2EE servlet filter). Both of these
support our enhancements, which are: 1) additional attributes; and 2) single
logout. Hopefully this will clear the legal department soon.
-Nathan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Cruz
Sent: Thursday, February 22, 2007 10:09 AM
To: Yale CAS mailing list
Subject: Re: Single Sign-Off
What if you're logged in more than one application?
A redirect from application to application destroying the sessions
and finally reaching the CAS server does not seem practical... :)
On Feb 22, 2007, at 11:35 AM, John Fereira wrote:
> At 09:35 AM 2/21/2007, Scott Battaglia wrote:
>> Any application that has used CAS for authentication is unaffected
>> by calling /cas/logout. /cas/logout merely destroys the
>> TicketGrantingTicket, preventing further single sign on with that
>> session. It will not destroy any client application sessions.
>
> We just encountered the same issue. Our solution to this was to
> create a Logout servlet (running in the application context, not the
> CAS context) which does a session.invalidate() on the application,
> then forwards to /cas/logout.
>
>
> John Fereira
> [EMAIL PROTECTED]
> Ithaca, NY
>
> _______________________________________________
> Yale CAS mailing list
> [email protected]
> http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
