Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CATSV2 Rel 8.4 - Service Providers SOAP binding for reception of <saml2p:LogoutRequest> #29

Open
lsleduc opened this issue Jun 24, 2020 · 1 comment

Comments

@lsleduc
Copy link

lsleduc commented Jun 24, 2020

Hi, CATSV2 Rel 8.4, egov 2.8.1.1 requires Service Providers that cannot support the SOAP binding for reception of saml2p:LogoutRequest MUST nevertheless include a for the SOAP binding in their Service Provider metadata AND discuss the resulting implications in a Security Assessment, and Privacy Impact Assessment.

The egov 2.8.1.1 makes an exception for the Sign In Canada Acceptance Platform which MUST only support the HTTP-Redirect binding for the reception of saml2p:LogoutRequest messages.

With the Sign In Canada platform operating as an SP with the existing CSPs on the GCCF Federation, should it not be subject to the same rules?

Not implementing a SOAP binding for reception of the saml2p:LogoutRequest will expose other SPs on the GCCF Federation at risks as they are relying on the CSPs to return a partial global logout response when one of the SP SOAP end point fails to process a logout request.

And would the Sign In Canada acting as an SP on the GCCF Federation not be subject to discuss the resulting implications in a Security Assessment, and Privacy Impact Assessment?

Thanks

@harrdou
Copy link
Collaborator

harrdou commented Jun 25, 2020

Hi Louis;

As mentioned in section 3.4.4, one of the goals of this update is to "prepare the federation for the introduction of Sign in Canada and the transition to version 3.0 of this specification". The Sign In Canada Acceptance Platform plays a special role in the GCCF. It is not an ordinary SP, it is the "bridge" between the old GCCF (which uses CATS v2) and the new Sign In Canada Federation (which uses CATS v3). In order to act as that "bridge" and a) enable seamless interoperability between the two federations and b) ensure user enrolments with SPs are preserved as they migrate, the Acceptance Platform needs to be subject to slightly different rules than "ordinary" SPs.

On your second point, remember that GCCF IDPs are required to complete propagation of logout to all SPs that support SOAP before beginning any logout propagation via HTTP-Redirect. Since the Acceptance Platform is the only SP in the GCCF that is allowed to use HTTP-Redirect this means that the GCCF IDP will not give up control of the browser until after the user has been logged out at the IDP as well as all of the other GCCF SPs that they have visited. Therefore there is no new risk to any other GCCF SPs (unless they have decided to opt-out of logout propogation, in which case they have deliberately accepted the risk).

In terms of an SA and PIA, we can definitely include the above explanation when discussing how this approach prevents any privacy /security risks.

-Doug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants