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.

@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.

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.

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?

What is the output of the following command:

cloud-init schema --system

I am using terraform to setup a VM but it's the same approach for cloud-init:
cloud_config

#cloud-config
preserve_hostname: false
hostname: ${hostname} 
create_hostname_file: true
users:
  - name: ansible
    groups:
      - sudo
    sudo:
      - ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    ssh_authorized_keys:
      - "ssh-ed25519 somekeyl"
      - "ssh-ed25519 otherkey"

network_config:

#cloud-config
network:
  version: 1
  config:
    - type: physical
      name: enX0
      subnets:
        - type: static
          address: ${ip_address}
          netmask: ${netmask}
          gateway: ${gateway}
          dns_nameservers:
%{ for dns_server in dns ~}
            - ${dns_server}
%{ endfor ~}

Maybe a silly question: Your template supports cloud-init ?

@amititre331
If you want to configure ip settings using cloud-init you have to use the option network_config instead of cloud_config.

Unbrand_CreateVmBody_{
memory	
name_description	[...]
name_label*	[...]
clone	[...]
gpuGroup	[...]
vgpuType	[...]
autoPoweron	[...]
vifs	[...]
copyHostBiosStrings	[...]
template*	[...]
affinity	[...]
vdis	[...]
install	{...}
cloud_config	[...]
network_config	string
boot	[...]
destroy_cloud_config_vdi	[...]
}

By the way, do not share your tokens on the internet

This approach isn’t entirely foolproof since I can’t use a wildcard, and I don’t know how many disks will be attached to the VM. For now, it will never exceed two disks, so I can explicitly include both in the ignore_changes statement. That’s an acceptable solution for us. Thanks for your support.

Hi all,

I have a general question about the Terraform provider.

At the moment, all my VMs are managed by Terraform, so far, so good. However, there’s one feature I’m missing. Terraform doesn’t seem to support disk migration. When I change the sr_id in the xenorchestra_vm resource, I get the following error:

Error: disk update action 'disk migration Update (Sr ID update)' not handled

I’m aware that I can use "ignore_changes = [disk]", but in that case, I lose the ability to modify the disk size through Terraform.

I’m not really happy with the idea of managing my VMs partly in Terraform and partly in XO. Another possible workaround is to set "ignore_changes = all", using Terraform only to create or remove systems, and handling all other changes through XO or Ansible.

How are you handling this situation?

Here is a full logging (xensource.log) the moment terraform creates the vm (carlo111).
I really hope someone can give me some clues. Because this is a showstopper.
Debug-terraform2.txt