-
Notifications
You must be signed in to change notification settings - Fork 76
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
Conversation
c347300
to
640372d
Compare
@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? |
4e5c9aa
to
db380b4
Compare
3d3df70
to
9556523
Compare
Added a section on Group Display Names to the opener ^. |
026f99a
to
1055402
Compare
|
3e2d177
to
edc1c47
Compare
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!];
Currently, these are not being considered, while it might be important to revoke membership. |
0d72089
to
33271fb
Compare
dee0936
to
16a67a1
Compare
5468ab0
to
a633310
Compare
8c5fa9b
to
2c95cdb
Compare
...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]>
8e2e97d
to
2adda46
Compare
fwiw, pushed some tooling to speed up running and debugging integration tests locally https://github.com/blizzz/user_saml_integration |
Oh that is awesome 😍 |
Signed-off-by: Arthur Schiwon <[email protected]>
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]>
Signed-off-by: Arthur Schiwon <[email protected]>
56d21ff
to
8be15ac
Compare
Signed-off-by: Arthur Schiwon <[email protected]>
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. |
There was a problem hiding this 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) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$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']); |
There was a problem hiding this comment.
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?
@juliushaertl resolved all your smaller findings. Additionally I realized that |
Signed-off-by: Arthur Schiwon <[email protected]>
Signed-off-by: Arthur Schiwon <[email protected]>
Signed-off-by: Arthur Schiwon <[email protected]>
6e05d4c
to
84ec0aa
Compare
I am glad to see that this topic is now solved and some of my initial work was usefull for it |
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
The
(SAML)
suffix is in the code currently. While stated by the younger me, it does not make me very happy: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.