Be less restrictive on service parameter check in CAS issuer
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: {panel} 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. {panel}
In our code, we reject the request. But it seems that JASIG CAS allows this request.
So to be able to support applications that uses wrong service values when doing CAS, I think we should tolerate that GET parameters are ignored when matching service values.