Initial session is not verified for SSO-based accounts

[tobast]

Initial session is not verified for SSO-based accounts

[rob0403]

Thank you very much for this information. We rechecked with Element 1.11.70: It still didn't work. Upgrading the homeserver to v1.110, however, did the trick. I assume it has to do with: element-hq/synapse#17284. The verification is now set up upon the first login.

[urz-hgw]

Hi,

we have the same issue using SSO via SAML and verifying the (first) session.

I tested the following two scenarios, both times I reset the synapse server (v1.109) and started from scratch, results are identical using Element App or the latest Element web client.

Scenario 1:
Login with SSO user --> Security & Privacy --> Set Up --> Enter a Security Phrase --> Continue and Download the key.
==> Secure Backup successful

Then I select Sessions --> Verify Session --> Verify with Security Key or Phrase

I can either enter the phrase or the key file, click on "continue" and will immediately be thrown back to "Verify with Security Key or Phrase" and I can repeat this on and on in an endless loop and the session won't verify.

Then I logout from the session and login again. After the login Element asks for a security phrase, but the saved one does not work and the process is broken. I can fix this only by resetting the security key and after setting a new phrase and new file I am additionally asked to verify my account by "Use Single Sign On to continue", which I do and after that my session is finally verified, but with the newly created key.

Scenario 2:
Login with SSO user --> Sessions --> Verify session
I directly have to "Proceed with reset" since there is no key present, I enter my phrase, download the key and get a "Secure Backup successful" and here I also have to "Use Single Sign On to continue" and after that my session is verified.
After logout and login again, I'm being ask for the phrase or the key and it is accepted and my new session is immediately verified.

So in Scenario 2 everything works as it should, but in Scenario 1 the dialog to "Use Single Sign On to continue" does not appear after trying to verify my current session with the created key.

Unfortunately there are no error logs at all in synapse or element-web, only the browser log throws some errors when clicking on "continue" in scenario 1 when I am in the endless loop.

FetchHttpApi: --> GET https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device rageshake.ts:77:16
bootstrapCrossSigning: starting 
Object { setupNewCrossSigning: undefined, olmDeviceHasMaster: true, olmDeviceHasUserSigning: true, olmDeviceHasSelfSigning: true, privateKeysInSecretStorage: true }
rageshake.ts:77:16
bootstrapCrossSigning: Olm device has private keys and they are saved in secret storage; doing nothing rageshake.ts:77:16
bootstrapCrossSigning: complete rageshake.ts:77:16
Not setting dehydration key: feature disabled rageshake.ts:77:16
FetchHttpApi: --> GET https://my-server.de/_matrix/client/unstable/org.matrix.msc3814.v1/dehydrated_device rageshake.ts:77:16
XHRGET
https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device
[HTTP/2 404  40ms]

XHRGET
https://my-server.de/_matrix/client/unstable/org.matrix.msc3814.v1/dehydrated_device
[HTTP/2 404  38ms]

FetchHttpApi: <-- GET https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device [83ms 404] rageshake.ts:77:16
could not get dehydrated device M_NOT_FOUND: MatrixError: [404] No dehydrated device available (https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device)
    s errors.ts:37
    a errors.ts:66
    p utils.ts:83
    requestOtherUrl fetch.ts:333
    request fetch.ts:241
    authedRequest fetch.ts:159
    getDehydratedDevice client.ts:1681
    fetchKeyInfo SetupEncryptionStore.ts:109
    start SetupEncryptionStore.ts:78
    p SetupEncryptionBody.tsx:52
    React 8
    unstable_runWithPriority scheduler.production.min.js:18
    React 6
    componentDidMount AsyncWrapper.tsx:58
    promise callback*componentDidMount AsyncWrapper.tsx:49
    React 2
    unstable_runWithPriority scheduler.production.min.js:18
    React 4
    unstable_runWithPriority scheduler.production.min.js:18
    React 7
    reRender Modal.tsx:425
    p setImmediate.js:40
    p setImmediate.js:69
    a setImmediate.js:109
rageshake.ts:77:16
FetchHttpApi: <-- GET https://my-server.de/_matrix/client/unstable/org.matrix.msc3814.v1/dehydrated_device [84ms 404] rageshake.ts:77:16
FetchHttpApi: --> GET https://my-server.de/_matrix/client/v3/room_keys/keys?version=xxx rageshake.ts:77:16
[PerSessionKeyBackupDownloader] Got current backup version from server: 1 rageshake.ts:77:16
FetchHttpApi: <-- GET https://my-server.de/_matrix/client/v3/room_keys/keys?version=xxx [102ms 200] rageshake.ts:77:16
Checking key backup status... rageshake.ts:77:16
FetchHttpApi: --> GET https://my-server.de/_matrix/client/v3/room_keys/version rageshake.ts:77:16
FetchHttpApi: <-- GET https://my-server.de/_matrix/client/v3/room_keys/version [86ms 200] rageshake.ts:77:16
Backup version 1 still current

Hope this helps....

Best regards
Daniel

[crjo]

Same here, upgrading synapse to v1.110 solved our issue, thanks to the dev team and thank you guys for the information!

[rob0403]

We can reproduce this error using OIDC and keycloak. Instructing users to reset and re-verify their passphrase is very difficult. Please let us know if additional logs are needed.
Best regards

[crjo]

Hi,
We are having such issues with SSO and keys management, since many weeks, all issues are closed to point to #27455, but no update there
We are having a very bad UX and we found nothing that can leverage the difficulty, expect having users to logout and reset keys.
Regards

[mglaubitz]

Hi there, we have the same problem and very new user on our server runs into this problem since we advise our users to use the element desktop client. We are fighting against commercial tools like WhatsApp and Telegram and need a solution for this problem that works without a complicated series of steps that each user has to take.

Are you already working on this issue? What can we do to help?

Thanks in advance for your endeavors!

[urz-hgw]

It looks like this issue is solved in Element-Desktop Version 1.11.70 .. could somebody please verify this?

[t3chguy]

Closing as fixed on the backend