OIDC login - Internal Server Error

olivierlambert

Hi,

Probably giving more context on which OIDC provider you are using and how do you fill the fields in the configuration, XO version too (commit or XOA branch) etc.

HeMaN

Are the users from the oidc provider unique and not already present as local users? I ran into this issue because my already existing local user was the same as the oidc provided user

carloum70

We are running Xen Orchestra with commit c3dcb and the auth-oidc (v0.4.2) plugin.

The users that login are unique and not yet present as local users.

The OICD provider is SURF with SRAM: https://www.surf.nl/en/services/identity-access-management/surf-research-access-management

They support the following attributes/scopes: https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226142/Attributes+in+SRAM

There are some IPs that need to be accessable: https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226067/IP+addresses#IPaddresses-OIDC . Outgoing traffic from the server to port 443 is open and works.

We did try several settings for the Username field and scopes.

For example the following:

This should create a user R123456789

The logging shows the following:

mrt 27 09:29:48 vm-xoa xo-server[2641104]: Expected values to be strictly equal:
mrt 27 09:29:48 vm-xoa xo-server[2641104]: + actual - expected
mrt 27 09:29:48 vm-xoa xo-server[2641104]: + 'undefined'
mrt 27 09:29:48 vm-xoa xo-server[2641104]: - 'string'

If we change it to:

The following shows up:

mrt 27 09:32:21 vm-xoa xo-server[2641104]: Cannot read properties of undefined (reading '0')

I hope this helps to understand the problem. Thanks.

HeMaN

@carloum70 are the scopes email and uid provided by the source (are they delivered to xo by surfnet)?

By default only the openid scope is provided, without email or uid

https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226151/Connect+using+OpenID+Connect

carloum70

@HeMaN

We would like to know that too.

It seems that xo is receiving something, but not what it is expecting. But unfortunately we cannot see what it receives.

With a saml tracer plugin I can see data that my browser exchanges with Surf and there are the field that are used/needed, like the uid and the mail.

But from my understanding xo requests its own data from surf based on token from the web session.

olivierlambert

Hi,

I think I've identified the issue. The OIDC plugin assumes the identity provider will always return the requested profile fields, but it doesn't handle the case where they're missing.

Error 1 (Expected 'undefined' to be 'string' with usernameField: uid): passport-openidconnect only maps standard OIDC fields (displayName, username, emails) onto the profile object. Custom fields like uid are only available in the raw claims (profile._json), but the plugin doesn't look there.
Error 2 (Cannot read properties of undefined (reading '0') with usernameField: email): The plugin tries to access profile.emails[0].value without checking that profile.emails exists first.
If your provider doesn't return the email claim (which SURF/SRAM doesn't by default — only openid is provided), it crashes.

I've opened a draft PR that fixes both issues by falling back to raw OIDC claims and giving a clear error message when the field is genuinely missing:

https://github.com/vatesfr/xen-orchestra/pull/9648

Could you test it? You'd need to build from that branch. If the fix works, you should either get a successful login (if the field exists in the raw claims) or a clear error message telling you exactly which field is missing — instead of the current cryptic crashes.

Also, it would help to confirm what your provider actually returns. You can check by temporarily adding this line in packages/xo-server-auth-oidc/index.js at line 136 (before the registerUser2 call):

console.log('OIDC profile:', JSON.stringify(profile, null, 2))

Then check the xo-server logs after a login attempt.

olivierlambert opened this pull request in vatesfr/xen-orchestra

draft fix(xo-server-auth-oidc): handle missing profile fields in username resolution #9648

HeMaN

remark; I wrote this before I saw the reply from Olivier. Redacted my reply to skip a few things I was wondering about but Oliver already solved. Main part that is left from my original thoughts is that you need to expose scopes on the Surf side before XO can actually use it, based on the information I extracted from my Authentik setup

=====

@carloum70 Strange indeed. Sadly, I do not know that much about the process.

I am a homelab user and use Authentik for authentication. In there I have to create an application and provider for XO.
The application part is nothing special, just some information about the name and the slug that will be userd later in the authentication url .
The provider part is what exposes the authentication endpoint for an application and here the properties are defined, like the authorization flow, Client ID and secret, redirect URIs, and the scopes that can be used by the client.

So I must add them to the provider first, and then the client can request them.

If I tell XO to use email for the username field and the scope email, it does not work if I did not expose the email scopemapping first in the Authentik provider.

(https://integrations.goauthentik.io/hypervisors-orchestrators/xen-orchestra/)

carloum70

Thanks for the reply's! This really helps.

I added the

console.log('OIDC profile:', JSON.stringify(profile, null, 2))

and then tried with the following:

username field: email
scope: email

logging:

mrt 30 12:34:57 vm-xoa xo-server[2747568]: OIDC profile: {
mrt 30 12:34:57 vm-xoa xo-server[2747568]:   "id": "38882f04f015223135313da0b919cb3d67bf4fbc@sram.surf.nl"
mrt 30 12:34:57 vm-xoa xo-server[2747568]: }
mrt 30 12:34:57 vm-xoa xo-server[2747568]: Cannot read properties of undefined (reading '0')

username field: uid
scope: uid

logging:

mrt 30 12:35:54 vm-xoa xo-server[2747568]: OIDC profile: {
mrt 30 12:35:54 vm-xoa xo-server[2747568]:   "id": "38882f04f015223135313da0b919cb3d67bf4fbc@sram.surf.nl"
mrt 30 12:35:54 vm-xoa xo-server[2747568]: }
mrt 30 12:35:54 vm-xoa xo-server[2747568]: Expected values to be strictly equal:
mrt 30 12:35:54 vm-xoa xo-server[2747568]: + actual - expected
mrt 30 12:35:54 vm-xoa xo-server[2747568]: + 'undefined'
mrt 30 12:35:54 vm-xoa xo-server[2747568]: - 'string'

So it seems that in both cases we only receive the "sub" from the scope openid from surf. Which is here named "id". Is this translated by xo?

Then I applied the patch from @olivierlambert . Therafter we were able to login by using "id" as Username field, "sub" returned an error. The user 38882f04f015223135313da0b919cb3d67bf4fbc@sram.surf.nl was then created.

If I use email or uid we get now better logging:

mrt 30 12:41:14 vm-xoa xo-server[2747760]: Could not find username: field "uid" is missing from the OIDC profile. Ensure the required scopes are configured and granted by your identity provider.
mrt 30 12:42:27 vm-xoa xo-server[2747760]: Could not find username: field "email" is missing from the OIDC profile. Ensure the required scopes are configured and granted by your identity provider.

We will check if we have to enable/allow additional claims from the authentication provider to be available and let you now.

olivierlambert

Okay waiting for your feedback

dlgroep

Replicating the issue with another OIDC OP (simplesamlphp module-oidc), it appears to hinge on an expectation of a 'thick' JWT token being returned from the OP, whereas some OPs (simplesamlphp, but also SRAM which IIRC uses SATOSA) strictly interpret OpenID Connect Core section 5.4 so that in the Authorization Code flow the returned JWT token is 'thin' and the RP must collect the claims (based on the requested scopes) from the userinfo endpoint, rather than expecting them to be in the returned IDToken. And since the auth-oidc plugin uses the response_type=code ...
(see https://github.com/vatesfr/xen-orchestra/pull/9648#issuecomment-4161156812 for more details).
Modifying an OP to always add claims to the IDToken, i.e. disregarding section 5.4 of the OIDC core spec, makes the issue above go away ...

olivierlambert opened this pull request in vatesfr/xen-orchestra