nextcloud / user_saml

:lock: App for authenticating Nextcloud users using SAML https://apps.nextcloud.com/apps/user_saml
https://portal.nextcloud.com/article/configuring-single-sign-on-10.html
GNU Affero General Public License v3.0
96 stars 76 forks source link

Allow disabling group prefix #879

Open hrenard opened 3 months ago

hrenard commented 3 months ago

Expected behaviour

We should be able to disable group prefix. I think it's a regression because this was the default behavior in v5.

Actual behaviour

It's not possible to set an empty value from the CLI. And in the UI, the difference between empty or default isn't clear either.

Server configuration

PHP version: 8.2

Nextcloud version: (see Nextcloud admin page) 28.0.9

App version: 6.2.0

blizzz commented 3 months ago

The behaviour is different yes, but existing groups are not affected.

rthaler commented 1 month ago

But it breaks systems using group names without a prefix. The lack of an option to disable the prefix or set it to empty is causing issues. This flexibility is needed to maintain compatibility with setups that don’t use group prefixes. In my case, new users automatically provisioned via SAML end up in new groups like SAML_groupname and therefore lose access to existing shared resources.

blizzz commented 1 month ago

But it breaks systems using group names without a prefix. The lack of an option to disable the prefix or set it to empty is causing issues. This flexibility is needed to maintain compatibility with setups that don’t use group prefixes. In my case, new users automatically provisioned via SAML end up in new groups like SAML_groupname and therefore lose access to existing shared resources.

These are local groups with users from mixed backends?

rthaler commented 1 month ago

In my case, there is no mix of different backends. All users and groups are exclusively provisioned via Keycloak, so these are local groups created by Keycloak. However, the proposed change would require me to adjust all existing groups and group assignments, which would create significant complications. Additionally, folders and shares are created by another system, meaning adjustments would also need to be made there, further complicating the process. That’s why it would be very helpful to have the option to disable the prefix or set it to empty, to ensure compatibility with the existing setups.

jooooaah commented 2 weeks ago

Same here - now there are a lot duplicated Groups in NC with same name but different internal names - had to reorganize a lot of shares.

blizzz commented 2 weeks ago

@rthaler

In my case, new users automatically provisioned via SAML end up in new groups like SAML_groupname and therefore lose access to existing shared resources.

Users are still sorted into existing groups that do not have a prefix. And when migrating groups from local to SAML backend, the ID will persist without the backend. Both scenarios are covered with automated tests.

Additionally, folders and shares are created by another system, meaning adjustments would also need to be made there, further complicating the process.

Now when it comes to newly created groups and the IDs are just assumed, then I see how you can run into it.