client ticket security

[Dallas]

A question has been asked by the engineers working on the client app that is authenticating against CAS regarding the security of the CAS ticket in the client session cookie.

The connection between the client app and CAS is over ssl but the rest of the client app does not use ssl. The concern is that the CAS ticket is exposed on the network traffic between the browser and the client app server and could be hijacked.

Are there any recommendations (other than putting the client app on ssl, which is not an option in my case) for addressing this?

I'm using CAS server 3.3.2 and CAS client 3.1.6.
--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

If you mean the SSO session token that is sent by the CAS Server to the browser, then you have no worries. That session token is *only* submitted to the CAS server and also *only* over SSL (if its not SSL, then CAS won't send back the cookie).  If you mean the one time token sent to your client application via the url, then if that's over HTTPS you should be fine.  However, if you switch out of HTTPS after that, then your HttpSession is exposed (which we have nothing to do with).

On Tue, Oct 6, 2009 at 6:11 PM, David Jefferson <[hidden email]> wrote:

A question has been asked by the engineers working on the client app that is authenticating against CAS regarding the security of the CAS ticket in the client session cookie.

The connection between the client app and CAS is over ssl but the rest of the client app does not use ssl. The concern is that the CAS ticket is exposed on the network traffic between the browser and the client app server and could be hijacked.

Are there any recommendations (other than putting the client app on ssl, which is not an option in my case) for addressing this?

I'm using CAS server 3.3.2 and CAS client 3.1.6.
--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

I recommend you read our protocol document:

http://www.jasig.org/cas/cas1-architecture
http://www.jasig.org/cas/cas2-architecture

Cheers,
Scott

On Wed, Oct 7, 2009 at 8:10 AM, David Jefferson <[hidden email]> wrote:

Thanks for the reply.

Could you elaborate a bit more on how the SSO session token is handled in the client?

I see that, after being authenticated, the CASTGC cookie that the CAS server creates that contains the session token in the content attribute, the host is pointing at my CAS server, and the "Send For" attribute is set to "Encrypted connections only".

I'm assuming though that, after a user has been authenticated, when the user navigates between secured pages (where secured means that they need to be logged in to access the page, but otherwise the requests are going over http) the CAS client code is retrieving the session token from the cookie and calling the CAS server to validate the token. Although the validation between the client and the CAS server is over SSL, the cookie data is being sent from the browser to the client app server over http. Is this correct? If yes, then this is what you meant in your earlier reply that the session token is exposed?

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Wed, Oct 7, 2009 at 10:32 AM, David Jefferson <[hidden email]> wrote:

Well... I have read those docs several times but it has not sunk in yet...<SIGH>

So... If I'm starting to understand correctly... I can put aside for the moment questions about the cookie that CAS server generates for SSO support since I don't need to support SSO (yet) and the cookie does not come in to play for a single client app authenticating against CAS.

The cookie *always* comes into play but the cookie is ONLY SENT between the CAS SERVER and the BROWSER.  NO client sees it EVER. (caps for emphasis only)
 

In the CAS 1 arch doc it discusses setting up a jsp to accept the "ticket" attribute on the request from from CAS, and then I need to invoke the call to validate the ticket and inspect the response. Looking at the example given at

http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml

for integrating a client app with the CAS server, it seems to imply that the validation filter provided in the CAS client jar will handle this for me.

Does the validation filter do what I assume it does or do I need to validate the ticket in my client code as described in the CAS 1 doc?

Yes, the client nicely handles everything for you!  Its our gift to you ;-)
 

Finally...,

After validation the service ticket is removed from the ticket registry. When the authenticated user tries to navigate from page A to page B CAS client authentication filter sends a new request to CAS server,

It doesn't send a request to the server, it redirects the client to the server.
 

CAS server verifies that the service and netid are ones that it recognizes as current and that the user has been authenticated (if yes, how does CAS check this?),

No, it reads the session cookie, establishes than an SSO session still exists, issues a service ticket and redirects the client back to the application with the ticket appended. The service then validates the ticket.

Hope that helps.
Scott
 

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

> I see that, after being authenticated, the CASTGC cookie that the CAS server
> creates that contains the session token in the content attribute

I would recommend avoiding the term "session token" when referring to
the CAS ticket-granting ticket for fear of confusion with the more
common meaning of an identifier that maintains an application server's
session state.

> I'm assuming though that ... the CAS client code is retrieving the session
> token from the cookie and calling the CAS server to validate the token.

The CAS client does not interact with browser cookies.  Study of the
protocol documents may be helpful background here.  The TGT is not
sent with the service ticket at validation time.  The _browser_ sends
a request to CAS for a service ticket.  CAS either complies
immediately if the CASTGC containing a valid TGT is sent or it forces
the user to authenticate.  The service ticket is then delivered back
to the CAS-enabled application for validation.  _Only_ the service
ticket is needed for validation, and it is retrieved from the
querystring.

> Although the validation between the client and the CAS server is over SSL, the cookie data is being sent from the browser to the client app server over http. Is this correct?

No.  As Scott said, the CASTGC cookie is only sent over a secure
channel.  It is _never_ sent over http assuming the browser honors the
"secure" flag in the cookie.

> If yes, then this is what you meant in your earlier reply that the session token is exposed?

I am fairly certain he meant the application server session
identifier.  If your application maintains any sort of state, then a
session ID cookie of some sort is sent back to the browser.  Failure
to send this cookie over a secure channel enables man-in-the-middle
attacks against your application.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Wed, Oct 7, 2009 at 12:25 PM, Marvin Addison <[hidden email]> wrote:

<snip />

> If yes, then this is what you meant in your earlier reply that the session token is exposed?

I am fairly certain he meant the application server session
identifier.  If your application maintains any sort of state, then a
session ID cookie of some sort is sent back to the browser.  Failure
to send this cookie over a secure channel enables man-in-the-middle
attacks against your application.

Yes, that's what I meant.  Thanks, Marvin.  I think you've read too many of my emails over the years ;-)

M

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Technolithic]

I understand the docs perfectly, aside from the nitty gritty details
involving how the TGC comes into play, it only took two hours of
pondering, reading, reconsidering, and rereading.  The record of the
chronological sequence of events is lost in the shuffle of details, but
with tenacious patience, years of experience with careful meticulous
training in the arts of reading documents for open source projects, and
plenty of time to sweep up the lost hair from the top of one's head,
anyone can easily overcome the ominous resistance for those documents to
be understood.

That said, since reading the other emails about the subject still leaves
me confused with the browser never sending the cookie to the webapp but
to CAS instead.  How does the webapp know when to redirect the browser
to the CAS login page?


David Jefferson wrote:

> Well... I have read those docs several times but it has not sunk in yet...<SIGH>
>
> So... If I'm starting to understand correctly... I can put aside for the moment questions about the cookie that CAS server generates for SSO support since I don't need to support SSO (yet) and the cookie does not come in to play for a single client app authenticating against CAS.
>
> In the CAS 1 arch doc it discusses setting up a jsp to accept the "ticket" attribute on the request from from CAS, and then I need to invoke the call to validate the ticket and inspect the response. Looking at the example given at
>
> http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml
>
> for integrating a client app with the CAS server, it seems to imply that the validation filter provided in the CAS client jar will handle this for me.
>
> Does the validation filter do what I assume it does or do I need to validate the ticket in my client code as described in the CAS 1 doc?
>  
> Finally...,
>
> After validation the service ticket is removed from the ticket registry. When the authenticated user tries to navigate from page A to page B CAS client authentication filter sends a new request to CAS server, CAS server verifies that the service and netid are ones that it recognizes as current and that the user has been authenticated (if yes, how does CAS check this?), CAS server generates a new service ticket, CAS sends the new ticket back to the app service, CAS client validation filter validates the new ticket, if all is good the user is redirected to page B. Is this correct?    
>
>
>      
>  

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Mon, Oct 12, 2009 at 9:15 PM, Jayson Ash <[hidden email]> wrote:

<snip />

That said, since reading the other emails about the subject still leaves me confused with the browser never sending the cookie to the webapp but to CAS instead.  How does the webapp know when to redirect the browser to the CAS login page?

The client redirects when there is no valid user in the session for the web application.

 

David Jefferson wrote:

Well... I have read those docs several times but it has not sunk in yet...<SIGH>

So... If I'm starting to understand correctly... I can put aside for the moment questions about the cookie that CAS server generates for SSO support since I don't need to support SSO (yet) and the cookie does not come in to play for a single client app authenticating against CAS.

In the CAS 1 arch doc it discusses setting up a jsp to accept the "ticket" attribute on the request from from CAS, and then I need to invoke the call to validate the ticket and inspect the response. Looking at the example given at

http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml

for integrating a client app with the CAS server, it seems to imply that the validation filter provided in the CAS client jar will handle this for me.
Does the validation filter do what I assume it does or do I need to validate the ticket in my client code as described in the CAS 1 doc?

 Finally...,

After validation the service ticket is removed from the ticket registry. When the authenticated user tries to navigate from page A to page B CAS client authentication filter sends a new request to CAS server, CAS server verifies that the service and netid are ones that it recognizes as current and that the user has been authenticated (if yes, how does CAS check this?), CAS server generates a new service ticket, CAS sends the new ticket back to the app service, CAS client validation filter validates the new ticket, if all is good the user is redirected to page B. Is this correct?    

       

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Technolithic]

Sweet, that makes sense.  Thanks!  This is probably common knowledge in
the world of web-apps, since it wasn't mentioned in the arch docs.  As
helpful those docs were, through trying to understand them I think I
need to call Bosely to replant the hair I ripped out =P


Scott Battaglia wrote:

> On Mon, Oct 12, 2009 at 9:15 PM, Jayson Ash <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     <snip />
>
>     That said, since reading the other emails about the subject still
>     leaves me confused with the browser never sending the cookie to
>     the webapp but to CAS instead.  How does the webapp know when to
>     redirect the browser to the CAS login page?
>
>
> The client redirects when there is no valid user in the session for
> the web application.
>
>  
>
>
>
>     David Jefferson wrote:
>
>         Well... I have read those docs several times but it has not
>         sunk in yet...<SIGH>
>
>         So... If I'm starting to understand correctly... I can put
>         aside for the moment questions about the cookie that CAS
>         server generates for SSO support since I don't need to support
>         SSO (yet) and the cookie does not come in to play for a single
>         client app authenticating against CAS.
>
>         In the CAS 1 arch doc it discusses setting up a jsp to accept
>         the "ticket" attribute on the request from from CAS, and then
>         I need to invoke the call to validate the ticket and inspect
>         the response. Looking at the example given at
>
>         http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml
>
>         for integrating a client app with the CAS server, it seems to
>         imply that the validation filter provided in the CAS client
>         jar will handle this for me.
>         Does the validation filter do what I assume it does or do I
>         need to validate the ticket in my client code as described in
>         the CAS 1 doc?
>          Finally...,
>         After validation the service ticket is removed from the ticket
>         registry. When the authenticated user tries to navigate from
>         page A to page B CAS client authentication filter sends a new
>         request to CAS server, CAS server verifies that the service
>         and netid are ones that it recognizes as current and that the
>         user has been authenticated (if yes, how does CAS check
>         this?), CAS server generates a new service ticket, CAS sends
>         the new ticket back to the app service, CAS client validation
>         filter validates the new ticket, if all is good the user is
>         redirected to page B. Is this correct?    
>
>                
>
>
>
>     --
>     You are currently subscribed to [hidden email]
>     <mailto:[hidden email]> as: [hidden email]
>     <mailto:[hidden email]>
>     To unsubscribe, change settings or access archives, see
>     http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

> anyone can easily overcome the
> ominous resistance for those documents to be understood.

In all fairness, most open source project documentation suffers more
from incompleteness and factual errors than obscurity.  But it
doubtless has the same effect on the reader, though, of causing
confusion instead of enlightenment.

> the subject still leaves me
> confused with the browser never sending the cookie to the webapp but to CAS
> instead.  How does the webapp know when to redirect the browser to the CAS
> login page?

A CAS-enabled application _always_ redirects to the CAS login page on
a new session.  It's that simple.  You only see the login form if you
don't currently have a valid SSO session or you have to reauthenticate
(e.g. renew=true) for some other reason.  Once you have a valid SSO
session, CAS issues a redirect to the original application with a
ticket parameter appended to the request URL.  The CAS client securing
the application extracts the ticket and validates it out of band from
the browser.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Technolithic]

Thanks for your reply.  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?


Marvin Addison wrote:

>> anyone can easily overcome the
>> ominous resistance for those documents to be understood.
>>    
>
> In all fairness, most open source project documentation suffers more
> from incompleteness and factual errors than obscurity.  But it
> doubtless has the same effect on the reader, though, of causing
> confusion instead of enlightenment.
>
>  
>> the subject still leaves me
>> confused with the browser never sending the cookie to the webapp but to CAS
>> instead.  How does the webapp know when to redirect the browser to the CAS
>> login page?
>>    
>
> A CAS-enabled application _always_ redirects to the CAS login page on
> a new session.  It's that simple.  You only see the login form if you
> don't currently have a valid SSO session or you have to reauthenticate
> (e.g. renew=true) for some other reason.  Once you have a valid SSO
> session, CAS issues a redirect to the original application with a
> ticket parameter appended to the request URL.  The CAS client securing
> the application extracts the ticket and validates it out of band from
> the browser.
>
> M
>
>  

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Technolithic]

Jayson Ash wrote:
> Thanks for your reply.  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 a better question would have been:  Where in the CAS
architecture does session validation take place?

>
>
> Marvin Addison wrote:
>>> anyone can easily overcome the
>>> ominous resistance for those documents to be understood.
>>>    
>>
>> In all fairness, most open source project documentation suffers more
>> from incompleteness and factual errors than obscurity.  But it
>> doubtless has the same effect on the reader, though, of causing
>> confusion instead of enlightenment.
>>
>>  
>>> the subject still leaves me
>>> confused with the browser never sending the cookie to the webapp but
>>> to CAS
>>> instead.  How does the webapp know when to redirect the browser to
>>> the CAS
>>> login page?
>>>    
>>
>> A CAS-enabled application _always_ redirects to the CAS login page on
>> a new session.  It's that simple.  You only see the login form if you
>> don't currently have a valid SSO session or you have to reauthenticate
>> (e.g. renew=true) for some other reason.  Once you have a valid SSO
>> session, CAS issues a redirect to the original application with a
>> ticket parameter appended to the request URL.  The CAS client securing
>> the application extracts the ticket and validates it out of band from
>> the browser.
>>
>> M
>>
>>  
>
>

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

>> 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 [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Technolithic]

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.  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 <[hidden email]>:

>>> 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 [hidden email] as:  
> [hidden email]
> To unsubscribe, change settings or access archives, see  
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
>

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Tue, Oct 13, 2009 at 8:45 PM, <[hidden email]> 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 <[hidden email]>:

>>> 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 [hidden email] as:

> [hidden email]

> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
>


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Technolithic]

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 <[hidden email]>:

> On Tue, Oct 13, 2009 at 8:45 PM, <[hidden email]> 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 <[hidden email]>:
>>
>> >>> 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 [hidden email] as:
>> > [hidden email]
>> > To unsubscribe, change settings or access archives, see
>> > http://www.ja-sig.org/wiki/display/JSG/cas-user
>> >
>> >
>> >
>>
>>
>> --
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>
>>
>
> --
> You are currently subscribed to [hidden email] as:  
> [hidden email]
> To unsubscribe, change settings or access archives, see  
> http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Tue, Oct 13, 2009 at 10:05 PM, <[hidden email]> wrote:

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?

It doesn't.  An SSO session is generated when the user authenticates for the first time (which means sending the cookie to the browser).

 

Quoting Scott Battaglia <[hidden email]>:

On Tue, Oct 13, 2009 at 8:45 PM, <[hidden email]> 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 <[hidden email]>:

>>> 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 [hidden email] as:
> [hidden email]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
>


--
You are currently subscribed to [hidden email] as:
[hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user