search

humlab-speech / visible-speech-deployment

3 stars 2 forks source link

Logout #140

Closed johanvonboer closed 3 weeks ago

johanvonboer commented 2 years ago

A breakdown of things:

We want to support Single Logout (SLO), which means logging out from all VISP services simultaneously with a single action. This is theoretically achievable in SAML but it requires that all relevant services are playing ball and supporting this properly.

As of today, what we have working is: Sign-out from the main site will clear the dashboard/php session as well as send a back-channel SAML logout request to Keycloak which will clear ALL of the users sessions in KC, so this means that this users sessions for all VISP subdomains/services are cleared. HOWEVER, if this user have visited gitlab during their session, through opening a repository page or some other part of the gitlab subdomain, that means that gitlab has authenticated this user towards keycloak and established its own session and this session will NOT be cleared by signing out from the main site.

Why? It is - theoretically - setup to work, OmniAuth (which gitlab uses for SAML authentication) does support SLO and KC is configured to use it, and KC makes an attempt att sending an SLO request to gitlab, but there's an SSL error while doing this which makes the request fail. Reason for this error is currently unknown. It could be as simple as that we can't use self-signed certs, which we are doing in dev.

Another important thing to be aware of is that the IdP (keycloak) metadata does currently NOT include a public key for encryption. The metadata for the prod site is found at https://idp.visp.humlab.umu.se/auth/realms/visp/protocol/saml/descriptor

In order for Shibboleth to be able to create a SLO request it needs a public key for encryption because it insists on encrypting this request, I have not managed to persuade KC to include a pk for encryption, so I have instead performed a (hopefully temporary) hack regarding this by saving the IdP metadata xml as a file locally on the server where the signature key is copied to also act as an encryption key. This has the drawback that updates to the IdP metadata, such as new pk's will NOT be automatically imported by Shibboleth.

johanvonboer commented 2 years ago

Trying to use front-channel logout for gitlab results in a 422 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422

FredrikKarlssonSpeech commented 2 years ago

@johanvonboer Logging out seems to work - it logs me out very often now... 3 times in the last hour.

Edit: Seems to really be related to the server restarting?

johanvonboer commented 2 years ago

Yes, I have been restarting the server, sorry! I'm trying to fix the gitlab-login-endless-redirect-loop-problem, which I don't have locally so I'm working directly on the server with it. Will have to restart it again!

FredrikKarlssonSpeech commented 2 years ago

No problems. I finish this thing up tomorrow just before the presentation thing.

FredrikKarlssonSpeech commented 2 years ago

This issue is still active (has resurfaced?)

In the new login, I try to log out and get this:

Skärmavbild 2022-09-01 kl 11 14 49

FredrikKarlssonSpeech commented 2 years ago

@johanvonboer @TomasSkotare With the new login infrastructure, is this issue then closer somehow to a solution?

johanvonboer commented 2 years ago

So, the status now is that in order to have fully functional logout we need to clear sessions in:

  1. The VISP site.
  2. The IdP that was used for login, UmU in our case.
  3. Our internal IdP (SSP).
  4. Gitlab.

Clearing the session in our own VISP site is obviously not a problem, and doing so should also work as a logout in our internal SSP IdP since they actually share the same PHP-session through the module I made for it.

Clearing the session in the external IdP (UmU for us) should now also work, and seems to work. I assume this should work for all the other SWAMID IdPs as well, but I can't verify that.

So what remains is clearing the session in gitlab. I don't have a solution for that at this point in time, but it's possible that there is a solution for it, I just haven't had time to dive into that yet.

johanvonboer commented 2 years ago

I partly take back what I said earlier that clearing the PHP session should also log you out from SSP, that is perhaps not necessarily the case since they run on different subdomains. Need to verify this.

johanvonboer commented 2 years ago

Slight update: It doesn't seem to be the differing subdomains which is the issue but rather that SSP and the WebAPI are running different PHP sessions.

johanvonboer commented 3 weeks ago

This is working now. Not having keycloak or gitlab in the mix made this vastly easier.