OIDC login - Internal Server Error

carloum70

We are trying to use the OIDC auth plugin to enable login to our Xen Orchestra without local accounts.

We registered a client with our identity provider and got a client id, client secret and the auto-discovery url. That we used to configure the plugin.

However, if we login we get redirected back from the identity provider to the XO callback url and receive then an "Internal Server Error"

The callback URL is as follow:

https://xoa.domain.com/signin/oidc/callback?state=STRING&scope=profile+openid&code=STRING&iss=https://identity-provider.url&client_id=XXXXX

In the log file we see then the following 4 lines:

mrt 25 12:29:25 vm-xoa xo-server[2618522]: Expected values to be strictly equal:
mrt 25 12:29:25 vm-xoa xo-server[2618522]: + actual - expected
mrt 25 12:29:25 vm-xoa xo-server[2618522]: + 'undefined'
mrt 25 12:29:25 vm-xoa xo-server[2618522]: - 'string'

If we change both the username field and the scope to email, we get the same Internal Server Error, but with a different single log line:

mrt 25 13:18:04 vm-xoa xo-server[2618522]: Cannot read properties of undefined (reading '0')

Because we are getting redirected back from our identity provider to Xen Orchestra we guess that the issue is not there. We also get in the browser a SAML response with the userdata.

Running a wireshark on the server shows also traffic between Xen Orchestra and the identity provider, but unfortunately we cannot look in the contents of that traffic stream.

Setting the log level to debug does unfortunately not produce more (error) output.

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

Is there an other way to figure out what is going wrong?

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

OIDC login - Internal Server Error

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