CSRF FlowExecutionListener testing for CAS

Purpose

Following on from CSRF Mitigation Options, here we test that the CsrfFlowExecutionListener[1] CSRF synchroniser token pattern mitigation works when using the IdP as a CAS server.

Views

The following CAS views have been tested with CSRF protection enabled.

View Name	Description	Requires CSRF protection e.g. uses HTML Form POST to the IdP

View Name	Description	Requires CSRF protection e.g. uses HTML Form POST to the IdP
footer.vm	XML cas service response footer	No
header.vm	XML cas service response header	No
logoutService.vm	Propogates a CAS logout to the SP	No/Yes. Main form is posted to the SP with a SAML 2 logout request hence CSRF token is not required. However, the underlaying flow itself is finalised by directing the propagation iFrame back to the IdP and resuming the conversation. This is done by modifying the iFrame src, and requires the CSRF token in the URL set into the sessionStorage e.g. see U1. Alternatively you could exclude this view (ShowServiceLogoutView) from CSRF protection - probably makes sense.
postBack.vm	When service ticket request method is POST	No. Main form is posting the service ticket to the SP, hence an CSRF token is not required from the IdP.
proxyFailure.vm	XML cas proxy failure response	No
proxySuccess.vm	XML cas proxy success response	No
validateFailure.vm	XML cas authentication failure response	No
validateSuccess.vm	XML cas authentication success response	No

U1

Modify the script in the CAS logoutService.vm to include the csrftoken:

<script>
    if (typeof(Storage) !== "undefined") {
        sessionStorage.setItem("$logoutPropCtx.sessionKey", "$flowExecutionUrl&_eventId=proceed&${csrfToken.parameterName}=${csrfToken.token}");
    }
</script>