Problem with Service Ticket from keycloak CAS extension

[kkalev]

Despite the CAS protocol being quite relaxed on the character set allowed in a Service Tickets (describing it as opaque with acceptable length of at least 32 characters). the plugin is quite strict and only accepts dots, hyphens and alnums. As a result, when the keycloak CAS extension issues an ST containing an underscore it breaks the CAS authentication.

Given that there's no real reason for being that strict on the accepted character set, is it possible to add the underscore in the accepted characters in order for the keycloak extension to continue working?

[kkalev]

Based on the response from the keycloak cas extension maintainers, the presence of underscores in the ST is the result of data being Base64 encoded which allows for a _. Given this fact, we'd like to request that the underscore be added in the acceptable character set by mod_auth_cas

[dhawes]

Here's a previous discussion about _ in STs with a simple patch to support them:

#134

I'll have to dig up the current specs to see if this is allowed. A quick search says yes, but I'd like to verify that.

[dhawes]

There's this in the spec:

https://apereo.github.io/cas/development/protocol/CAS-Protocol-Specification.html#37-ticket-and-ticket-granting-cookie-character-set

CAS - CAS Protocol Specification

CAS - Enterprise Single Sign-On for the Web

[jacekkow]

@dhawes - could you tell me why dots (.) are accepted, even though the spec forbids that?

mod_auth_cas/src/mod_auth_cas.c

Line 743 in 9acbc62

if (*ticket != '-' && *ticket != '.' && !isalnum(*ticket))

[dhawes]

Sadly, I can't find any history of this change other than it happened in 2012. If I had to speculate, it was probably to support an earlier version of the spec or an application that used a different character set for service tickets, like what is being experienced here.

Based on the current spec I'd be of a mind to restrict the character set in mod_auth_cas further, but I do not see an argument to expand it.

[kkalev]

@dhawes I understand that the CAS specification is quite restrictive on the allowed character set for STs.

Nevertheless, given that Base64url is used in JWT and applications will tend to reuse concepts and code from other protocols (such as OIDC), it seems reasonable to also allow underscores in STs. But it's definitely your call.

If the decision to not allow underscores is final it would be helpful to have a note somewhere in the README, especially since the problem will present itself on a completely random basis.

[dhawes]

I think that reasoning is sound, but I would also like to follow the spec if possible. It may be worth appealing to spec writers. I'll dig around and see if there are any conversations about this on any of the CAS lists.

Documenting this is a good idea regardless of any decisions made here.