canada-ca / CATS-STAE

Cyber Authentication Technology - Technologie d’authentification électronique
https://canada-ca.github.io/CATS-STAE/
14 stars 1 forks source link

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

Open lsleduc opened 4 years ago

lsleduc commented 4 years ago

Hi, CATSV2 Rel 8.4, egov 2.8.1.1 requires Service Providers that cannot support the SOAP binding for reception of 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 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 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 commented 4 years ago

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