Question about CAS protocol and its implementation in Apereo/JASIG CAS

10 views
Skip to first unread message

Clément OUDOT

unread,
Jun 1, 2016, 5:45:29 AM6/1/16
to identity-...@googlegroups.com
Hi all,

I don't know if this is the best place to ask this question, but as we are a group of collaboration between identity projects, it seems not to be the worst place ;)

I implemented CAS protocol (full 1.0 and 2.0, and a part of 3.0 with attributes sharing) in LemonLDAP:NG (http://lemonldap-ng.org)

I faced a little issue this week by moving an application from JASIG CAS to LemonLDAP::NG:
* When the application first ask for a service ticket, the "service" value is something like "http://service.example.com/;jessionid=xxxxxxxxx"
* When validating this service ticket, the submitted "service" value is "http://service.example.com/"

Looking at CAS protocol (https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html), in section 2.5.3, I read this:

INVALID_SERVICE - the ticket provided was valid, but the service specified did not match the service associated with the ticket. CAS MUST invalidate the ticket and disallow future validation of that same ticket.

In my code, I reject the request. But it seems that JASIG CAS allows this request.

So my question is: do I have to accept a service value that is not exactly the same at the one that was first submitted? Is this a specific behavior of JASIG CAS implementation?


Thanks a lot for your feedback,
-- 
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
87, rue de Turbigo - 75003 PARIS
Blog: http://sflx.ca/coudot

Misagh

unread,
Jun 1, 2016, 10:22:21 AM6/1/16
to identity-...@googlegroups.com
You probably should post to somewhere listed here http://apereo.github.io/cas/Mailing-Lists.html

Th JASIG CAS is slightly more forgiving. Because in your case at least, it's configured to track web sessions by rewriting the URL, and on validation requests, it ignores the jsessionid I think. 

You should never accept a service value that is not exactly the same at the one that was first submitted.


--
You received this message because you are subscribed to the Google Groups "Identity Ecosystem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to identity-ecosys...@googlegroups.com.
To post to this group, send email to identity-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/identity-ecosystem/574EAEB3.8050403%40savoirfairelinux.com.
For more options, visit https://groups.google.com/d/optout.



--
- Misagh

Clément OUDOT

unread,
Jun 1, 2016, 10:43:05 AM6/1/16
to identity-...@googlegroups.com


Le 01/06/2016 16:22, Misagh a écrit :
You probably should post to somewhere listed here http://apereo.github.io/cas/Mailing-Lists.html

Th JASIG CAS is slightly more forgiving. Because in your case at least, it's configured to track web sessions by rewriting the URL, and on validation requests, it ignores the jsessionid I think. 

You should never accept a service value that is not exactly the same at the one that was first submitted.


Thanks a lot for your answer. I subscribed to cas-dev mailing list, we will follow discussion there.
Reply all
Reply to author
Forward
0 new messages