Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of Groupbackend II #662

Merged
merged 10 commits into from
Dec 20, 2023
Merged

Implementation of Groupbackend II #662

merged 10 commits into from
Dec 20, 2023

Conversation

blizzz
Copy link
Member

@blizzz blizzz commented Oct 10, 2022

Work PR of #545, in good old tradition… For it is not possible to push into #545 it's easier to have the feature branch here.

Group display names

In one of the predecessor PRs group display names were a topic, with the conclusion

makeing use of group display names so present it more user friendly, perhaps with (SAML) in brackets.

The (SAML) suffix is in the code currently. While stated by the younger me, it does not make me very happy:

  • typical for LTR languages only
  • technical term exposed to potentially unwitting end users (why should they know about this detail
  • We have a FIXME that is rather wondering about adding another config flag here…

I am going to revert this, to use the value as provided from SAML again. Besides avoiding the downsides mentioned above, the end user does not have to face a change and will not suffer irritation. Admins may need a closer look to verify the backend, if needed, which is totally fine imo.

Group IDs

We have a group prefix SAMLSettings::DEFAULT_GROUP_PREFIX, that was brought back in the course of this work. At the momend it will only be used, to avoid name collisions. In hindsight this irritated me, I was expecting it to be considered independent of it (now only realizing that there is no way for an empty prefix).

I am not sure what to do about it. For, leaving it as it is results in an unpredictable behaviour of group ids, and groups may end up in an inconsistent naming manner: some with, some without prefix.

Keeping old group ids however could actually be important to keep shares in place, or also permissions. On existing setups the "old" group does not go away, but it theoretically might be that a group wlll be split into ORIGINAL and SAML_ORIGINAL, where only the latter might be populated with new SAML users. In those cases, a doubled group display name would cause more confusion with the admin.

Having the prefix always present makes it more predictable, and while transition may need action of the admin, re-deployments would be reproducible.

@blizzz blizzz force-pushed the groupbackend-upup branch 8 times, most recently from c347300 to 640372d Compare October 11, 2022 10:10
@blizzz
Copy link
Member Author

blizzz commented Oct 11, 2022

@Deltachaos it's been a while, but maybe you still remember: GroupDuplicateChecker is not wired anywhere, where was it intended to be used? And the only purpose was really to only issue a warning in the log?

@blizzz blizzz force-pushed the groupbackend-upup branch from 4e5c9aa to db380b4 Compare October 11, 2022 10:57
@blizzz blizzz force-pushed the groupbackend-upup branch 4 times, most recently from 3d3df70 to 9556523 Compare November 4, 2022 18:48
@blizzz
Copy link
Member Author

blizzz commented Nov 4, 2022

Added a section on Group Display Names to the opener ^.

@blizzz
Copy link
Member Author

blizzz commented Nov 14, 2022

Group IDs

We have a group prefix SAMLSettings::DEFAULT_GROUP_PREFIX, that was brought back in the course of this work. At the momend it will only be used, to avoid name collisions. In hindsight this irritated me, I was expecting it to be considered independent of it (now only realizing that there is no way for an empty prefix).

I am not sure what to do about it. For, leaving it as it is results in an unpredictable behaviour of group ids, and groups may end up in an inconsistent naming manner: some with, some without prefix.

Keeping old group ids however could actually be important to keep shares in place, or also permissions. On existing setups the "old" group does not go away, but it theoretically might be that a group wlll be split into ORIGINAL and SAML_ORIGINAL, where only the latter might be populated with new SAML users. In those cases, a doubled group display name would cause more confusion with the admin.

Having the prefix always present makes it more predictable, and while transition may need action of the admin, re-deployments would be reproducible.

@blizzz
Copy link
Member Author

blizzz commented Dec 4, 2022

on dealing with membership changes in local groups, I'd go for:

flowchart TD
    A[Should remove local group membership?] --> B{Is it about the admin group?};
    B -- Yes --> C[Keep membership!];
    B -- No --> D{Are we still in migration phase?};
    D -- No --> C;
    D -- Yes --> E{Is the group still in allow list?};
    E -- No --> C;
    E -- Yes --> F{Do other members stem<br/>from mixed user backends?};
    F -- Yes --> C;
    F -- No --> G[Remove membership!];
Loading

Currently, these are not being considered, while it might be important to revoke membership.

@blizzz blizzz force-pushed the groupbackend-upup branch 6 times, most recently from 8c5fa9b to 2c95cdb Compare December 6, 2023 13:37
...to separate SAML groups from system/other groups

Includes

- use of DB migrations and repair steps
- specific exceptions
- owned database group table
- firing of group related events
- migration logic of already existing groups on local backend where
  applicable
- group id collission detection and handling
  - map original gid by saml and avoid collissions
  - append SAML prefix to gid
  - create new SAML group on collision
- cleanup logic: delete SAML groups without members
- Ensure admin cannot unassign SAML groups/members
- Append SAML_ prefix to groups
- Settings
  - show default group prefix
  - order group related settings next to each other
- allow local group modifications in some cases
  - must not be about admin group
  - must be about local group backend
  - must be in allow migration list
  - must not have users from mixed backends

Signed-off-by: Arthur Schiwon <[email protected]>
Signed-off-by: Giuliano Mele <[email protected]>
Signed-off-by: Jonathan Treffler <[email protected]>
Signed-off-by: Julius Härtl <[email protected]>
Signed-off-by: Maximilian Ruta <[email protected]>
Co-authored-by: Carl Schwan <[email protected]>
Co-authored-by: Giuliano Mele <[email protected]>
Co-authored-by: Jonathan Treffler <[email protected]>
@blizzz blizzz force-pushed the groupbackend-upup branch from 8e2e97d to 2adda46 Compare December 6, 2023 19:19
@blizzz
Copy link
Member Author

blizzz commented Dec 6, 2023

fwiw, pushed some tooling to speed up running and debugging integration tests locally https://github.com/blizzz/user_saml_integration

@juliusknorr
Copy link
Member

fwiw, pushed some tooling to speed up running and debugging integration tests locally blizzz/user_saml_integration

Oh that is awesome 😍

it is failing much to often with container init

Signed-off-by: Arthur Schiwon <[email protected]>
previous to this change groups would be creating in our own backend
without the prefix. This is not a very predictable behaviour, and to be
more consistent and with less surprises, we include the prefix now
unconditionally.

Signed-off-by: Arthur Schiwon <[email protected]>
Signed-off-by: Arthur Schiwon <[email protected]>
@blizzz
Copy link
Member Author

blizzz commented Dec 11, 2023

bumped the version to 6.1, though since this is a bigger change with deeper impact, bumping the major would feel better. However, as we might backport it, and could not bump previous major ones, i went to bump the minor version bit only.

Copy link
Member

@juliusknorr juliusknorr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nitpicks, but otherwise 👍

appinfo/app.php Outdated

$samlSettings = \OC::$server->get(SAMLSettings::class);

\OC::$server->registerService(GroupManager::class, function (ContainerInterface $c) use ($groupBackend, $samlSettings) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually need this service registration? Isn't it all autowired these days (especially with all dependencies just coming from the DI containers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe to remember something about the groupBackend, but actually it seems to be safe to drop this. I'll check this.

'length' => 64,
'default' => '',
]);
$table->setPrimaryKey(['gid', 'uid'], 'idx_group_members');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
$table->setPrimaryKey(['gid', 'uid'], 'idx_group_members');
$table->setPrimaryKey(['gid', 'uid'], 'idx_saml_group_members');

To avoid too easily conflicting names on postgres

'default' => '',
]);
$table->setPrimaryKey(['gid', 'uid'], 'idx_group_members');
$table->addIndex(['gid']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we also name those indices?

@blizzz
Copy link
Member Author

blizzz commented Dec 20, 2023

@juliushaertl resolved all your smaller findings. Additionally I realized that IGetDisplayname was not implemented, so while the group displayname was set, it was actually not used. Added this as well.

@blizzz blizzz merged commit 4dbbd8e into master Dec 20, 2023
25 checks passed
@blizzz blizzz deleted the groupbackend-upup branch December 20, 2023 12:44
@Deltachaos
Copy link
Contributor

I am glad to see that this topic is now solved and some of my initial work was usefull for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants