Strange behaviour while reaching the login page with cookie but without service

[Drew Mazurek]

I see two ways of interpreting the CAS Specification 
(http://www.ja-sig.org/wiki/display/CAS/CAS+2.0+Protocol+Specification) 
in this case.

1.  When /login is passed a ticket-granting cookie, it is acting as a 
credential acceptor (a TGC could be considered a credential) per section 
2.2.  In that vain, an invalid TGC must be considered a failed login and 
respond as in section 2.2.4:  "return to /login as a credential 
requestor."  It is also recommended that CAS display an error message.

2.  When /login is passed a ticket-granting cookie, it is acting as a 
credential requestor per section 2.1.  In that case, per 2.1.1, if 
service isn't specified and a single sign-on session doesn't exist (due 
to the invalid TGC), "CAS SHOULD request credentials from the user to 
initiate a single sign-on session."

Even though the specification isn't exact in this case ("CAS SHOULD 
request credentials..." should probably be made into a "MUST"), in order 
to be backwards-compatible with the Yale CAS 2.0 server, an invalid TGC 
should result in the login screen being presented.

- Drew

Scott Battaglia wrote:
> Technically its the correct behavior as without a service, we never 
> bother to "use" the TGT to make sure its valid (we have no way of using 
> it) and just assume its valid.  The first time a user attempts to access 
> a service it will make them log in. I will admit however, that the 
> behavior does seem a bit odd if you know you've forged or have an 
> expired ticket :-)
>
> If its a concern, one can always check the ticket registry to make sure 
> the ticket still exists and is not expired.  It breaks the fact that we 
> try and keep any ticket access to the service layer, but it would allow 
> you to make sure this behavior doesn't happen.
>
>
>
>
> Arnaud Lesueur wrote:
>   
>> Hi,
>>
>> I have found a strange behaviour with the default CAS login webflow.
>>
>> If you reach the login page without requesting any service and with a CASTGC cookie, you get the casGenericSuccess
>> page as answer.
>>
>> This step is OK with a valid cookie but with a non-valid cookie (either expired or a forged cookie) you reach also the
>> casGenericSuccess page which does not enable the user to login and get a valid TGC.
>>
>> Do you think this is really a valid behaviour for end-user ?
>> Don't you think that CAS should return the login form instead ?
>>
>> Arnaud Lesueur
>>
>> _______________________________________________
>> Yale CAS mailing list
>> cas at tp.its.yale.edu
>> http://tp.its.yale.edu/mailman/listinfo/cas
>>   
>>     
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>