# Verwaltung der Gruppenmitgliedschaft via Authentifizierung **URL:** \ **Category:** Development\ **Created:** [13. Januar 2021 um 06:50 UTC](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950 "2021-01-13T06:50:24Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![angus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/angus/32/341715_2.png) [@angus](https://meta.discourse.org/u/angus)\ **Post date:** [25. Januar 2021 um 23:01 UTC](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950/8 "2021-01-25T23:01:07Z")
> [@david](#): > > Wir sollten es, wenn möglich, vermeiden, super-technische Details in den Gruppeneinstellungen unterzubringen. Wenn man auf Syntax-Dokumentation verlinken muss, sollte das wahrscheinlich vereinfacht werden oder in die Admin-Seiteneinstellungen ausgelagert werden. Ich denke, wir sollten diesen Teil jeder Auth-Plugin-Implementierung überlassen, da dies stark variieren kann. Ich stimme zu. > [@david](#): > > Nehmen wir OIDC als Beispiel: Dieses Plugin würde eine neue Seiteneinstellung `openid_connect_roles_claim` hinzufügen. Wenn [Okta verwendet wird](https://developer.okta.com/docs/guides/customize-tokens-groups-claim/add-groups-claim-org-as/), würde der Administrator dies als `groups` konfigurieren. Ich denke, ein String-Array ist ein recht Standardformat für OIDC, aber wir könnten hier, falls wirklich notwendig, komplexere Optionen erkunden. hm ja, jedoch gibt es Fälle, in denen die Unterstützung eines booleschen Claims sinnvoll ist. Aber ja, ich stimme zu, lassen wir es vorerst einfach und unterstützen nur ein String-Array. Wenn wir das authentifizierungsspezifisch angehen, hätten wir vermutlich auch eine Methode `group_sync_enabled?` in `Auth::Authenticator`, die in einzelnen Authentifizierern überschrieben würde und in den generischen Authentifizierern basierend auf dem Vorhandensein eines Werts in der entsprechenden Einstellung. Das wirft eigentlich eine interessante Frage auf. Dies könnte auch von den spezifischen Service-Authentifizierern genutzt werden, wie z. B. Facebook (“groups”?), Google (“groups”?) und Discord (“roles”). Ich bin mir nicht sicher, ob deren ID-Tokens solche Informationen enthalten, aber es könnte sich lohnen, dies aus technischer Designperspektive zu prüfen (d. h. die Möglichkeit, dies später nachzurüsten). Für v1 ist das meiner Meinung nach jedoch keine primäre Sorge. > [@david](#): > > Um diese Informationen zu erhalten, würde `Auth::Result` ein neues Attribut `roles` erhalten, das ein einfaches Array von Strings akzeptiert. Der Kern wird dies dann übernehmen (in `Auth::Result#apply_user_attributes!`) und in eine neue Tabelle `UserAssociatedRoles` mit den Spalten (`provider_name`, `user_id`, `role`) laden. Diese Tabelle `UserAssociatedRoles` liefert uns die von dir im OP erwähnte „Identifizierung der Mitgliedschaftsquelle“. Diese Mechanismen klingen in Ordnung, aber ich bin neugierig, warum wir hier von „groups“ auf „roles“ umgestiegen sind. Kein großes Problem, aber ich möchte sicherstellen, dass mir nichts entgeht. Aus UX-Sicht sehe ich Verwirrung, die durch die Verwendung dieser Terminologie entstehen könnte (d. h. „roles“ und „groups“ gleichzeitig), selbst wenn dies auf einer nützlichen technischen Unterscheidung basiert. Auch mögliche Verwirrung bei Entwicklern, die ohne diesen Hintergrundkontext an die Sache herangehen. Ich mag die separate Tabelle, aber vielleicht sollten wir eine Fremdschlüssel-Beziehung zu `user_associated_accounts` anstelle von `provider_name` haben? Das könnte bei Dingen wie Bereinigungsoperationen nützlich sein. Ich vermute, die Antwort auf diese Frage hängt teilweise davon ab, wie stark wir die Gruppen-/Rollen-Assoziation aus Produktsicht mit dem verknüpften Konto verknüpft haben wollen. Gibt es Nachteile, wenn wir die beiden jetzt verknüpfen? \*\* Edit, ich vermute, wir haben die Verknüpfung bereits über die `user_id`. > [@david](#): > > Rollenamen würden mit dem `provider_name` versehen werden. Die Autovervollständigung würde auf allen vorhandenen Werten in der Tabelle `UserAssociatedRoles` basieren, aber wir würden auch nicht-autovervollständigte Werte akzeptieren, falls die Rolle von Discourse noch nicht gesehen wurde. Das klingt in Ordnung, aber ich denke gerade, dass wir diese Information auch pro Anbieter haben, und zwar durch die von dir vorgeschlagene Seiteneinstellung, die auch den Fall abdecken würde, dass die Rolle noch nicht gesehen wurde. Vielleicht gibt es eine Möglichkeit, `Discourse.authenticators` hier zu verwenden, also eine Liste im Speicher der Anbieter und ihrer Claims? > [@david](#): > > - Mitglieder hinzufügen, wenn sie eine passende Rolle vom Auth-Anbieter haben > - Mitglieder entfernen, wenn diese Rolle verschwindet > - Hinzufügen/Entfernen auch in Discourse zulassen > - Wenn ein Admin versucht, einen Benutzer zu entfernen, der über einen Auth-Anbieter hinzugefügt wurde, eine Warnung anzeigen: „Dieser Benutzer könnte beim nächsten Login wieder hinzugefügt werden“ Ich denke, das ist ein guter Kompromiss. Besonders wenn wir auch die unten erwähnte Seiteneinstellung haben. > [@david](#): > > Für Seiten, die das wirklich nicht wollen, könnten wir eine Seiteneinstellung wie `remove_group_membership_when_auth_role_lost` haben (Standard: true). Auf Plugin- (d. h. Authentifizierer-) Basis? Wenn ja, bin ich dabei. Das sollte diesen Bedarf für v1 abdecken. Gute Zusammenfassung des Benutzerflusses 👍 Unter Vorbehalt der relativ kleinen Vorschläge, die ich gemacht habe, bin ich mit der Richtung einverstanden. --- _[View the full topic](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950)._