Thanks Scott, I feel like I'm on the right track now. Upon a
validation success, the application receives the username through
plain text from CAS. How does the Ticket Granting Cookie come into
action from here?
Quoting Scott Battaglia <[email protected]>:
On Tue, Oct 13, 2009 at 8:45 PM, <[email protected]> wrote:
This is helpful for clearing up a bit of my confusion, but I'm
wondering how exactly the webapp could validate a CAS-enabled webapp
session. I understand that the browser receives a "Ticket Granting
Cookie", TGC, of which is mentioned little about in the architecture
docs and is also an optional component of a CAS system. To present
the appearance of SSO, the TGC is required. The Service ticket, the
thing that expires as soon as it is used, validates the session on the
CAS-enabled webapp.
Upon success with the validation of the service
ticket, a TGC is sent to the browser.
<<<<<<
I'm not sure where you saw this but its not true. When a user comes to a
CASified application that he has not logged into yet, he is redirected to
CAS. One of two things happens. 1. If no SSO session exists he is prompted
for his credentials, and on successful authentication, a SSO session is
established or (2) the server recognizes an existing SSO session. In either
case, a Service TIcket is issued for that service that made the original
redirect. CAS tells the browser to redirect to the application with the
Service Ticket. The application sees the Service Ticket and makes a
validation call to CAS. If the validation is successful, the application
will receive the username and is then able to establish its local
application session.
Cheers,
Scott
The existence of the TGC seems
to be a clue into the world of validating a CAS-enabled webapp
session. Is this how an CAS SSO solution is supposed to work?
Quoting Marvin Addison <[email protected]>:
>>> Perhaps unnecessary redirects, redirects that
>>> happen when a user is logged in already, could be avoided by storing
data
>>> via the session with the webapp?
>
> I think we need to clarify what session you mean. The SSO session or
> the session of the CAS-enabled Web application? Assuming you mean the
> webapp session, then most CAS clients do store authenticated state to
> prevent unnecessary redirects to CAS every time. Note that this
> client feature is entirely optional; CAS has full support for
> stateless authentication scenarios.
>
>> I think a better question would have been: Where in the CAS
architecture
>> does session validation take place?
>
> Again, assuming you mean validating the authenticated state of a
> CAS-enabled webapp, then it's not formally part of either the protocol
> or the CAS architecture per se. Most CAS clients store the
> authenticated state to prevent redirects other than on session
> creation.
>
> M
>
> --
> You are currently subscribed to [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
>
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
