OIDC via ADFS failed with error "Failed to encrypt refresh token: securecookie: the value is too long"

[qch2012]

Required information

• Distribution: Ubuntu
• Distribution version: 20.04
• The output of "snap list --all lxd core20 core22 core24 snapd":

snap list --all lxd core20 core22 core24 snapd
Name    Version         Rev    Tracking       Publisher   Notes
core20  20240416        2318   latest/stable  canonical✓  base,disabled
core20  20240705        2379   latest/stable  canonical✓  base
core22  20240823        1612   latest/stable  canonical✓  base,disabled
core22  20240904        1621   latest/stable  canonical✓  base
core24  20240528        423    latest/stable  canonical✓  base,disabled
core24  20240710        490    latest/stable  canonical✓  base
lxd     5.21.2-22f93f4  29948  5.21/stable    canonical✓  disabled
lxd     5.21.2-2f4ba6b  30131  5.21/stable    canonical✓  -

• The output of "lxc info" or if that fails:
  • Kernel version: 5.4.0-195-generic
  • LXC version: 5.21.2 LTS
  • LXD version: 5.21.2 LTS
  • Storage backend in use: zfs

Issue description

ODIC authentication against ADFS failed to return refresh token due to returned token size exceed the cookie size limit

Following errors are seen in browser after login to ADFS

{"type":"error","status":"","status_code":0,"operation":"","error_code":500,"error":"Failed to set login information: Failed to encrypt refresh token: securecookie: the value is too long: 5888","metadata":null}

Steps to reproduce

1. Step 1 , configure application groups in ADFS (in windows 2022 server)

2. Step 2 , configure LXD oidc.client.id and oidc.issuer

3. Step 3, open lxd gui https://:8443, click "login with SSO", the login page should be redirected to ADFS

4. Step 4, Login with the AD account in ADFS page, the browswer returns token exceeding cookie size error

[markylaing]

Initial thoughts on this:

1. We shouldn't fail if we can't encrypt the refresh token. The client has authenticated at this point, so we can discard the refresh token and encrypt the refresh token only.
2. We can introduce a setting e.g. oidc.storage with two options client, and server. client will be the default and this will use cookies. When set to server, we will set a session_id cookie as normal, as well as a session_secret cookie. The session secret will be encrypted as tokens are today. The session ID could either reference a long lived operation or a new identity type OIDC Client (session), the metadata would contain the session secret and their identity and refresh tokens. We would have to run a background job to remove sessions when they expire.

Edit: Again these are just initial thoughts, we'll need to do more research on session management before any implementation.

[tomponline]

2. The session ID could either reference a long lived operation or a new identity type OIDC Client (session), the metadata would contain the session secret and their identity and refresh tokens. We would have to run a background job to remove sessions when they expire.

Do we actually need a new identity type, can we not just store the token in the metadata for the normal client type?

[markylaing]

2. The session ID could either reference a long lived operation or a new identity type OIDC Client (session), the metadata would contain the session secret and their identity and refresh tokens. We would have to run a background job to remove sessions when they expire.

Do we actually need a new identity type, can we not just store the token in the metadata for the normal client type?

It depends, the identifier for an OIDC client is their email address, but in this case we'll just have a session ID and session secret. I was thinking we'd use the session ID as the identifier, then have the secret in the metadata and ensure it matches. If these identities have a different identifier I think it makes sense to have a different identity type.

This change will need a specification as there is a fair bit of complexity.

[tomponline]

@mionaalex shall we add this to the roadmap candidate sheet?