You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The validateCasTicketFormat() (also involved in / could also fix 134 and 145) does not handle those jwt tickets. We bypassed it with :
apr_byte_t validCASTicketFormat(const char *ticket)
{
/* NOTE(ARKEA) : Always returning true, because of various tickets encoding (JWT, ST-, ... )
Also a question on the need of validating cas Ticket Format ?
*/
return TRUE;
}
The environement where the vhost is deployed is secured, we so did not see any security risk.. But any feedback is welcome ;)
The text was updated successfully, but these errors were encountered:
ghost
changed the title
Not working when cas configured with JWT service tickets
Not working when CAS configured with JWT service tickets
Oct 31, 2019
I expect it would be trivial to update validCASTicketFormat() to support JWT tickets. I'd have to look at the history of this function to comment about security issues, but I expect it is minimal.
From the CAS v2 documentation, there is no need to validate the content of the ticket, the only relevant check is that it needs to begin with "ST-".
tests/mod_auth_cas_test.c:getCASTicket_test actively check that it fails to validate ST-^<> which is a valid ticket, or ST- which it also a valid ticket.
src/mod_auth_cas.c:validCASTicketFormat can be then be updated with a way simpler body, such as
apr_byte_tvalidCASTicketFormat(constchar*ticket)
{
if (ticket[0] =='\0'|| (ticket[0] !='P'&&ticket[0] !='S'))
return FALSE;
if (ticket[1] =='\0'||ticket[1] !='T')
return FALSE;
if (ticket[2] =='\0'||ticket[2] !='-')
return FALSE;
return TRUE;
}
Hi every one,
We got a problem with our CAS 5.3.x, configured to deliver JWT service tickets (eg : ticket=deyJhbGciOiJIUzUxMiJ9.ZXlKNmFYQWlPa...).
The validateCasTicketFormat() (also involved in / could also fix 134 and 145) does not handle those jwt tickets. We bypassed it with :
The environement where the vhost is deployed is secured, we so did not see any security risk.. But any feedback is welcome ;)
The text was updated successfully, but these errors were encountered: