Unable to map nested claim

[dragonpil]

Hi there 👋

I'm currently using Nextcloud 30.0.8 with the user_oidc app version 7.1.0. I'm trying to use OpenID Connect for user login and synchronization via EasyVerein as an Identity Provider.

In my configuration, I have added the scopes: openid myself custom Extra Claims: empty

I have defined for example the following in the mapping: displayName: custom.nickname

However, the displayName field is not populated correctly in Nextcloud. I have increased the log level to 0 and confirmed via the logs what the returned token contains. Here's a sanitized version of the relevant part of the ID token:

{
  "sub": "XXXXXXXX",
  "name": "OpenID Test",
  "username": "[email protected]",
  "email": "[email protected]",
  "custom": {
    "nickname": "Spitzname"
  },
  ...
}

As you can see, the nickname is present in a nested custom claim. According to the docs, the plugin allows specifying claim paths like custom.nickname, but this does not seem to work in practice (or is unsupported for nested claims?).

Other top-level mappings such as email and sub work perfectly.

❓ Question Is there currently a supported way to map nested claims (like custom.nickname) to fields such as displayName in Nextcloud?

If not, is this a known limitation or something that could be supported in future releases?

Thanks in advance – and thanks for maintaining this useful plugin 🙌

Best regards,

[julien-nc]

Hey, thanks for reporting this issue.

According to the docs, the plugin allows specifying claim paths like custom.nickname

Which part of the README are you referring to? I don't think nested attributes are mentioned.

This is indeed a limitation of the current implementation. I will have a look soon to check if there is a simple way to implement support for that.

[dragonpil]

Hi, I re-read everything and couldn't find the position where I originally thought I saw it – sorry for the confusion.

In the meantime, I already started preparing a solution on my side. How is the usual approach here? I'd be happy to prepare a pull request, but I would definitely need help checking whether I’ve changed all relevant places, if the general direction makes sense, and how to properly test it.

I also have a second feature request related to this topic: It would be great to allow some kind of fallback logic in the attribute mapping – like:

custom.nickname | profile.name | name | sub

… meaning “if the first value does not exist, try the next.”

I already have an idea how to implement this and would include it in the same PR if you think that would be welcome.

Let me know what you think!

Best regards,

[julien-nc]

Hey,

You are very welcome to create a PR. I can review your changes and give you pointers. Most of the changes should happen in lib/Service/ProvisioningService.php. I guess there are 2 aspects of that change:

• handling mapping attributes differently if they contain a "."
• correctly getting the nested values in the login token

There might be some questions to answer along the way. Like: What about the userinfo data? Should it support nested values? (the answer for this one is most likely yes)

Please make sure to isolate the token parsing logic in a function to keep the provisioning service readable.

I guess the 2nd part of your changes (fallback mechanism) is very related with the support for nested stuff. It can be done in the same PR indeed.

Thank you for the interest and the motivation.