canada-ca / CATS-STAE

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

User interaction during single logout #40

Open harrdou opened 2 years ago

harrdou commented 2 years ago

Traditionally, CATS has not permitted an IDP/OP to interact with the user during single logout. I.e.

...deployments MUST NOT deploy support for user intervention governing the choice of propagating logout to other SPs, or limiting the operation to the Identity Provider. At all times, a Single Logout Request will generate a global logout for the principal’s session.

The newly finalized OIDC RP-Initiated logout spec takes the opposite approach...

At the Logout Endpoint, the OP SHOULD ask the End-User whether to log out of the OP as well. Furthermore, the OP MUST ask the End-User this question if an id_token_hint was not provided or if the supplied ID Token does not belong to the current OP session with the RP and/or currently logged in End-User. If the End-User says "yes", then the OP MUST log out the End-User.

Do we want to reconsider our approach or stick with our current approach?

harrdou commented 2 years ago

The spec also says that

If the ID Token's sid claim does not correspond to the RP's current session or a recent session at the OP, the OP SHOULD treat the logout request as suspect, and MAY decline to act upon it.

This seems to conflict with the requirement that the "the OP MUST ask the End-User this question if an id_token_hint was not provided or if the supplied ID Token does not belong to the current OP session".

Current Sign In Canada behaviour is more aligned with the first requirement. If the id_token hint does not match a current session we reject the request and display our Logout Error page...

harrdou commented 2 years ago

I was just reading the new spec further and identified the motivation for this requirement in section 6:

Logout requests without a valid id_token_hint value are a potential means of denial of service; therefore, OPs should obtain explicit confirmation from the End-User before acting upon them.

Traditionally, the GC has erred on the side of caution in this regard. I.e. considering it better for a user to have been logged out (if even maliciously) than left logged in without knowing it.

SteveLPKI commented 1 year ago

I am having trouble understanding the rationale for shifting the responsibility to protect against DoS attacks from the RP to the user. If a user sees an unsolicited/unexpected logout dialogue they might reply “no” to the logout prompt, but they might also reply “yes” or simply close their browser because they may assume/fear something has gone wrong. In the latter case, the DoS attack is successful anyway and user engagement potentially results in a loss of confidence in the service itself. My sense is that a CATS 3.0 compliant OP should not prompt the user unless absolutely necessary. Please refer to Issue #41 for additional discussion related to this issue.