regex detection of groups claims has bugs. Groups are missing after login

[Wikinaut]

• Nextcloud 31.0.8 (hosted at Hetzner)
• OIDC 8.0.0

Detection of groups claims has apparently bugs. It is difficult to find out at which step.

Our OIDC provider sends these groups to Nextcloud as OIDC client:

ABC_HAUPTKATEGORIE_\u00FC\u0020\u0028Herr\u0029,ABC_UNTERKATEGORIE_\u0020Berlin,ABC_AMT_99\u0020Team

Not all groups were taken or updated, at the moment, it looks not reliable.

Groups REGEX:

1. /^ABC_(HAUPTKATEGORIE|UNTERKATEGORIE|AMT)_/

After detecting that a group is missing then I used the following wider REGEX:
2. /^ABC_/

[Wikinaut]

I further noticed, that a very long group name is only shown as sha1-hash in the group list, where my other group connections are clearly readable. Something serious, in my view. At least a full show stopper for my association > 350 members.

This is somehow reproducible. That group names contains spaces " ", slashes "/", parentheses "(", ")", which all are coded `\u as shown above

[julien-nc]

Some escaping might be missing. I'll have a look. Thank for reporting this.

[julien-nc]

Can you give me a precise group name and a "group whitelist regexp" so I can try to reproduce? So far all good with groups like group/1 and regexps like /^group/.

[Wikinaut]

See my post

[Wikinaut]

oidc_groups = "ABC_HAUPTKATEGORIE_\u00FC\u0020\u0028Herr\u0029,ABC_UNTERKATEGORIE_\u0020Berlin,ABC_AMT_99\u0020Team"

as mentioned above.

[julien-nc]

Main issue

I've set ABC_HAUPTKATEGORIE_ü (Herr),ABC_UNTERKATEGORIE_ Berlin,ABC_AMT_99 Team in the group attribute of a user on the IdP side and used /^ABC_(HAUPTKATEGORIE|UNTERKATEGORIE|AMT)_/ as the group whitelist regexp in user_oidc.
The result is that the groups are created and the user is affected to all 3 of them.

Then I've set the group attribute to ABC_HAUPTKATEGORIE_\u00FC\u0020\u0028Herr\u0029 and kept the same regex. This works on my side as well. I wanted to see how user_oidc behaves if the IdP sends the attribute value with a wrong decoding of the UTF-8 characters. The result is that the group ABC_HAUPTKATEGORIE_\u00FC\u0020\u0028Herr\u0029 is created and the user is in it.

The implementation is rather straightforward:

user_oidc/lib/Service/ProvisioningService.php

Lines 550 to 552 in a031bf0

	if ($groupsWhitelistRegex && !preg_match($groupsWhitelistRegex, $group->gid)) {
	$this->logger->debug('Skipped group `' . $group->gid . '` for importing as not part of whitelist');
	continue;

It will skip the groups obtained in the token payload for which preg_match returns a falsy value.

From the information i have right now, it seems like your IdP is not sending UTF-8 strings in the token payload.
I made a PR to add a little bit more details on the debug log that is produced when a group ID does not match the regex: #1228

What you can do right now is to set the loglevel to 0 (debug) in Nextcloud's config.php and reproduce the error by logging in again. You should find lines that contain Skipped group in nextcloud.log. This will show which string is actually tested with the regex.

GID too long

I further noticed, that a very long group name is only shown as sha1-hash in the group list, where my other group connections are clearly readable

This is expected, the max group ID length is 64 characters in Nextcloud. The occ command or the internal API will still accept to create a group when giving a longer group ID but it will silently replace the group ID with a sha256 hash
See https://github.com/nextcloud/server/blob/0c1be89f1b96824aa4c40c0cd97e285813d017ca/lib/private/Group/Database.php#L579-L583

I can still see a bug from what you say: when editing a user in the account settings, in the group list dropdown menu, for the groups the user is in (the selected items) the group ID is displayed instead of the group name.
I reported this in the server repo: nextcloud/server#55785

[Wikinaut]

Thanks so far! I will be watching the changes here.

Yes, we decided to let (our) OIDC-Provider send these json-utf-escaped group names (in order to avoid UTF-8 codes); the person in charge of the OIDC_provider could also not find a reliable and robust "standard".

We already shortened some of the very long group names. I understand, that this indeed is a restriction in Nextcloud currently. I would suggest to lift the restriction, or at least to show warnings to admins.

The case is (can be) somehow dangerous in the sense, that a certain group was not auto-assigned to these (oidc_claim) group-member-users, a team ordner was not available etc. I am looking forward to any improvements here and I am willing to help.

One point, related: I wanted to create a TEAM folder(s) (Team app) which are automatically auto-assigned to all users having an OIDC-Login from a certain provder.

Just as an arbitrary example:

• read-only folder for all_oidc_users@oidcprovider1.com
• r/w-folder for all_oidc_users@oidcprovider2.com