Verwaltung der Gruppenmitgliedschaft via Authentifizierung

[angus (Angus McLeod)]

@david Ich schließe mich der Diskussion von an

https://github.com/discourse/discourse-openid-connect/pull/7#issuecomment-758082333

Wie du dir wahrscheinlich denken kannst, liegt mir ebenfalls sehr daran, eine stabile Lösung für dieses Problem zu finden, das nicht spezifisch für das openid-connect-Plugin ist. Mal sehen, ob wir einen Weg nach vorne finden können.

Ich möchte auf deinen Punkt eingehen.

Wie entscheidest du, welchen Gruppen du den Benutzer hinzufügst oder aus denen du ihn entfernst? Und wie wirkt sich das auf das manuelle Hinzufügen/Entfernen von Benutzern aus Gruppen in Discourse selbst aus?

1. Ein Benutzer authentifiziert sich über OIDC mit den Gruppen ['group1', 'group2']
2. In der Discourse-Benutzeroberfläche wird der Benutzer zur Gruppe group3 hinzugefügt
3. Später authentifiziert sich derselbe Benutzer über OIDC mit den Gruppen ['group1']

Wenn wir dies als Mensch betrachten, sehen wir, dass der Endzustand group1, group3 sein sollte (group2 sollte entfernt werden). Aber ich glaube nicht, dass genügend Zustand verfolgt wird, um diese Entscheidung programmatisch zu treffen. Ebenso:

1. Ein Benutzer authentifiziert sich über OIDC mit den Gruppen ['group1', 'group2']
2. In der Discourse-Benutzeroberfläche wird der Benutzer aus group1 entfernt
3. Später authentifiziert sich derselbe Benutzer über OIDC mit den Gruppen ['group1', 'group2']

Was sollte jetzt passieren? Ein Administrator hat den Benutzer explizit aus group1 entfernt, aber OIDC hat ihn einfach wieder hinzugefügt. Das ist eine sehr verwirrende UX für den Administrator. Wir benötigen möglicherweise eine Möglichkeit, Gruppen als „extern verwaltet“ zu kennzeichnen und die gesamte Benutzeroberfläche zum Hinzufügen/Entfernen auszublenden

Ich denke, es gibt einige Möglichkeiten, wie wir dieses Problem angehen könnten (sie schließen sich nicht gegenseitig aus).

Identifizierung von Gruppen und Token-Attributen

In jeder Implementierung ist eine explizite Identifizierung erforderlich von:

1. welchen Gruppen die Mitgliedschaft über die Authentifizierung verwaltet werden kann; und
2. welche Attribute in einem Auth-Token die Gruppenmitgliedschaft steuern

Dies sollte entweder über Site-Einstellungen, Gruppeneinstellungen oder auf andere Weise erfolgen, und der Standardwert sollte „aus“ sein.

Strenge oder nachsichtige Behandlung

Die Behandlung ist „streng“, wenn ein Benutzer entfernt wird, wenn die Gruppe im identifizierten Token-Attribut fehlt. Die Behandlung ist „nachsichtig“, wenn ein Benutzer nicht entfernt wird, wenn die Gruppe im identifizierten Token-Attribut fehlt.

Der strenge/nachsichtige Zustand wird pro Gruppe festgelegt. Ein Beispiel dafür, wie du dies in einer Site-Einstellung umsetzen könntest, findest du hier: Handle groups by mattcg · Pull Request #7 · discourse/discourse-openid-connect · GitHub. Derselbe Ansatz könnte auch über eine Gruppeneinstellung umgesetzt werden.

Wie du vorschlägst, könntest du das Hinzufügen/Entfernen von Gruppenmitgliedschaften über den Gruppen-Admin deaktivieren, wenn die Behandlung „streng“ ist.

Identifizierung der Mitgliedschaftsquelle

Du könntest auch die Quelle der Gruppenmitgliedschaft in der Tabelle group_users speichern, um einen „gemischten“ Ansatz innerhalb einer Gruppe zu ermöglichen, d. h. ein Administrator kann keine Mitgliedschaften entfernen, die über ein Auth-Token erstellt wurden.

Je mehr ich darüber nachdenke, desto mehr bin ich der Meinung, dass dies über Gruppeneinstellungen erfolgen sollte.

[david (David Taylor)]

Danke @angus, dass du das angestoßen hast! Ich weiß, dass viele Leute an dieser Funktionalität interessiert sind!

@angus

Bei jeder Implementierung sollte eine explizite Kennzeichnung erforderlich sein von:

1. welchen Gruppen die Mitgliedschaft über die Authentifizierung verwaltet werden kann; und
2. welche Attribute in einem Authentifizierungstoken die Gruppenmitgliedschaft steuern

Interessant! Ich habe mir immer vorgestellt, dass Gruppen während der Authentifizierung automatisch erstellt werden und dass der Gruppenname zu 1:1 mit dem Gruppennamen beim Identitätsanbieter übereinstimmt. So funktioniert DiscourseConnect derzeit.

Aber ich mag diese explizitere Option tatsächlich sehr! Das bedeutet, dass die Discourse-Instanzen der Nutzer nicht mit unnötigen Gruppen ihres Identitätsanbieters überflutet werden, und es bedeutet, dass Administratoren die Gruppennamen nach ihren Wünschen anpassen können. Es hat eine große Parität zu unserer bestehenden mitgliedschaftsbasierten E-Mail-Domain-Funktionalität.

@angus

Strenge oder permissive Handhabung

Die Handhabung ist „streng“, wenn ein Nutzer entfernt wird, wenn die Gruppe im identifizierten Token-Attribut fehlt. Die Handhabung ist „permissiv“, wenn ein Nutzer nicht entfernt wird, wenn die Gruppe im identifizierten Token-Attribut fehlt.

Der strenge/permissive Zustand würde pro Gruppe festgelegt.

Das klingt aus technischer Sicht gut. Meine einzige Sorge ist, dass es für Nutzer/Admins schwierig zu erklären sein könnte. Wenn wir deine Idee der „expliziten Kennzeichnung“ von auth-verwalteten Gruppen verfolgen, könnten wir dann nicht einfach die „strenge“ Handhabung implementieren?

Wenn eine Gruppe als auth-verwaltet konfiguriert ist, ist das manuelle Hinzufügen/Entfernen hinter einer großen Warnung verborgen, und es verhält sich wie der „strenge“ Modus, den du beschrieben hast.

Wie klingt das?

Nebenbei: Wir sollten auch sicherstellen, dass alle automatischen Hinzufügungen/Entfernungen von Nutzern im Gruppenprotokoll aufgezeichnet werden. Das wird es für alle einfacher machen zu verstehen, was passiert und warum.

[angus (Angus McLeod)]

@david

Ich habe immer angenommen, dass Gruppen während der Authentifizierung automatisch erstellt werden und dass der Gruppenname zu 1:1 mit dem Gruppennamen beim Identitätsanbieter übereinstimmt. So funktioniert DiscourseConnect derzeit.

Ja, ich finde es besser, dies zumindest für Version 1 dieses Featuresatzes explizit zu gestalten. Ich bin bisher keinem Anwendungsfall begegnet, bei dem eine automatische Erstellung wirklich erforderlich gewesen wäre, d. h. die Gruppe hätte einfach vom Site-Administrator vor der Bearbeitung beliebiger Ansprüche eingerichtet und konfiguriert werden können.

Vielleicht könnten wir nach der Umsetzung der expliziten Version eine automatische Erstellung als Option einführen?

Im Hinblick auf die Gruppeneinstellungen könnte dies wie folgt aussehen:

Einstellungsabschnitt: Mitgliedschaft (d. h. der bestehende Abschnitt)
Titel der Einstellungsgruppe: Authentifizierungsverwaltung
Einstellungen:

• Dienst: Liste der Authentifizierungsdienste. „Alle“ wäre eine Option. Diese Einstellung würde auch als „aktiviert/deaktiviert“-Status für diesen Featuresatz fungieren. D. h. der Standardwert wäre „Keine“.
• Anspruch: Texteingabe zur Identifizierung des ID-Token-Anspruchs. Die „Beschreibung“ für dieses Feature (vielleicht in einem Beitrag hier auf Meta) würde die unterstützten Formate erläutern, z. B. boolescher Wert, durch Kommas getrennte Zeichenfolge usw.
• Modus: siehe unten

@david

Das klingt technisch gesehen gut. Meine einzige Sorge ist, dass es für Benutzer/Admins schwer zu erklären sein könnte. Wenn wir uns für deine Idee der „expliziten Identifizierung“ von authentifizierungsverwalteten Gruppen entscheiden, könnten wir dann nicht einfach die „strikte“ Handhabung implementieren?

Ja, wenn es eine Einstellung für „streng/umfassend“ gäbe, müssten wir sie prägnant erklären. Ich denke, der richtige Ansatz wäre, sich auf „Hinzufügen“ und „Entfernen“ zu konzentrieren. Man könnte es vielleicht so beschreiben:

Einstellung: „Modus"

Option 1 (umfassend):

• Beschriftung: „Mitglieder hinzufügen"
• Beschreibung: „Ermöglicht das Hinzufügen von Mitgliedern zu dieser Gruppe bei der Authentifizierung"

Option 2 (streng):

• Beschriftung: „Mitglieder hinzufügen und entfernen"
• Beschreibung: „Ermöglicht das Hinzufügen und Entfernen von Mitgliedern bei der Authentifizierung. Dadurch werden manuelle Mitgliedschaftskontrollen deaktiviert."

Der Grund, warum ich daran interessiert bin, die Option „umfassend“ beizubehalten, ist, dass dies bei der Arbeit mit Kunden in dieser Hinsicht in der Vergangenheit der häufigste Anwendungsfall war, d. h.:

• Der Hauptbedarf besteht darin, den Zugriff auf eine Gruppe abhängig von einem Status in einem externen Dienst zu ermöglichen.

• Die Notwendigkeit, den Zugriff abhängig vom Status im externen Dienst zu entfernen, ist eher nebensächlich, d. h. Menschen verlieren zwar den Zugriff und sollten entfernt werden, aber dies ist relativ weniger wichtig.

• Oft besteht der Wunsch, die Möglichkeit zur manuellen Steuerung der Mitgliedschaft in Discourse beizubehalten. Wenn ich den „strengen“ Ansatz implementiert habe, war dies „überraschend“ (d. h. „Warum hat Person X die Mitgliedschaft verloren?“), trotz Erklärungen und obwohl es (technisch) wie vorgesehen funktionierte.

@david

Nebenbemerkung: Wir sollten auch sicherstellen, dass alle automatischen Hinzufügungen/Entfernungen von Benutzern im Gruppenprotokoll erfasst werden. Das wird es allen erleichtern zu verstehen, was passiert und warum.

Ja, das ist wichtig, da sich Leute oft fragen werden, „warum“ jemand hinzugefügt oder entfernt wurde, insbesondere im strengen Modus, und wir (d. h. „Discourse") keine Kontrolle über die Richtigkeit der Ansprüche haben, die der externe Authentifizierungsdienst stellt.

Vielleicht eine neue Art von Aktion „Benutzer entfernen“ und „Benutzer hinzufügen“, die den für die Aktion zuständigen Authentifizierungsdienst enthält, d. h. „Benutzer entfernen ([Dienstname])“.

[angus (Angus McLeod)]

Eine weitere ‘Falle’ dabei ist, dass wir klarstellen müssen, dass dies keine Allzwecklösung für den Anwendungsfall „Ich möchte, dass die Mitgliedschaften einer Gruppe auf einem externen Dienst X basieren

[angus (Angus McLeod)]

@david Wie stehst du dazu? Wenn ich einen PR vorbereiten würde, wärst du offen dafür?

[tobiaseigen]

Das ist eine wertvolle Arbeit, die du hier leistest!

Nur als Funktionsvergleich: Ich wollte teilen, was wir beim Global Legal Empowerment Network machen, das WordPress und das Discourse-WordPress-Plugin nutzt. Wir haben es so eingerichtet, dass bei jeder Aktualisierung eines Benutzers in WordPress auch eine Aktualisierung in Discourse erfolgt. Dazu gehören spezielle Gruppen (z. B. Kernmitglied, Ressourcenbeitragsender usw.) sowie Profilangaben. Wir haben ein verstecktes Benutzerfeld für „zuletzt aktualisiert

[david (David Taylor)]

@angus

In Bezug auf die Gruppeneinstellungen…

Wir sollten versuchen, die hochtechnischen Details bei den Gruppeneinstellungen so weit wie möglich zu vermeiden. Wenn wir auf Syntax-Dokumentation verweisen müssen, heißt das wahrscheinlich, dass die Einstellung vereinfacht werden oder in die allgemeinen Admin-Einstellungen der Seite verschoben werden sollte. Ich denke, wir sollten diesen Teil jedem Authentifizierungs-Plugin überlassen, da dies stark variieren kann.

Nehmen wir OIDC als Beispiel: Dieses Plugin würde eine neue Seiteneinstellung namens openid_connect_roles_claim hinzufügen. Wenn Okta verwendet wird, würde der Administrator dies als groups konfigurieren. Ich denke, ein String-Array ist ein ziemlich Standardformat für OIDC, aber wir könnten hier bei Bedarf komplexere Optionen erkunden.

Um diese Informationen zu empfangen, würde Auth::Result ein neues Attribut roles erhalten, das ein einfaches Array von Strings akzeptiert. Der Kern (in Auth::Result#apply_user_attributes!) würde dies dann übernehmen 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".

Ich stelle mir die Gruppeneinstellungen ungefähr so vor:

Die Rollennamen würden mit dem provider_name-Präfix versehen werden. Die Autovervollständigung basiert auf allen vorhandenen Werten in der Tabelle UserAssociatedRoles, aber wir würden auch Werte akzeptieren, die nicht automatisch vervollständigt werden, falls die Rolle von Discourse noch nicht gesehen wurde.

Der Vorteil einer vollständigen user_associated_roles-Tabelle in der Datenbank besteht darin, dass Administratoren mit Discourse-Gruppen machen können, was sie wollen, und die Mitgliedschaften werden sofort aktualisiert, ohne dass sich Benutzer erneut anmelden müssen.

@angus

Oft besteht der Wunsch, die Möglichkeit zur manuellen Steuerung der Mitgliedschaft in Discourse beizubehalten.

Das ist fair. Ich denke, es wäre am besten, dies zumindest für v1 so einfach wie möglich zu halten, daher möchte ich keine mehreren „Modi" haben. Wie wäre es mit folgendem Standardverhalten:

• Mitglieder hinzufügen, wenn sie eine passende Rolle vom Authentifizierungsanbieter haben
• Mitglieder entfernen, wenn diese Rolle verschwindet
• Das Hinzufügen/Entfernen in Discourse ebenfalls zulassen
• Wenn ein Administrator versucht, einen Benutzer zu entfernen, der über einen Authentifizierungsanbieter hinzugefügt wurde, eine Warnung anzeigen: „Dieser Benutzer könnte beim nächsten Anmelden erneut hinzugefügt werden"

@angus

Bei der Implementierung des „strengen" Ansatzes war dies oft „überraschend" (d. h. „Warum hat Person X die Mitgliedschaft verloren?").

Ich denke, wir sollten hier standardmäßig sicherheitsorientiert vorgehen und Mitglieder entfernen, wenn sie die Rolle beim Identitätsanbieter verlieren. Mit den Verbesserungen im Mitgliedschaftsprotokoll hoffe ich, dass dies weniger verwirrend sein wird als der aktuelle Status quo.

Für Seiten, die das wirklich nicht wollen, könnten wir eine Seiteneinstellung wie remove_group_membership_when_auth_role_lost (Standard: true) haben.

@angus

Ein weiterer „Haken" hier ist, dass wir klarstellen müssen, dass dies keine Allzwecklösung für den Anwendungsfall ist: „Ich möchte, dass die Mitgliedschaft einer Gruppe auf einem externen Dienst X basiert", da sich Menschen nicht so häufig authentifizieren, oder zumindest nicht entsprechend den Anforderungen des Standardanwendungsfalls dieser Art.

Ja, absolut. Wir haben dieses Problem auch bei anderen Benutzermetadaten wie Name, Avatar usw. Ich denke, wir müssen uns bald damit beschäftigen, eine sync_sso-Äquivalenz für andere Authentifizierungs-Plugins zu erstellen. Dies könnte alle Informationen enthalten, die normalerweise über OIDC / SAML usw. übermittelt werden, einschließlich dieser neuen „Rollen"-Informationen. Wahrscheinlich jedoch ein separates Projekt.

---

Wie klingt das alles für dich, @angus? Es ist etwas weniger flexibel als separate strenge/erlaubende Modi, aber ich denke, nur einen Modus zu haben, wird die Fehlerbehebung / Dokumentation / Unterstützung viel einfacher machen.

---

Mit diesem Plan hier ist eine grobe Übersicht, wie es aus Administratorensicht aussieht:

Erste Einrichtung

1. Richten Sie Okta-Auth ein und aktivieren Sie den Gruppen-Claim auf der Seite von Okta.

2. Setzen Sie in Discourse openid_connect_roles_claim auf groups.

Einrichtung einer neuen Gruppe

1. Erstellen Sie wie üblich eine Discourse-Gruppe. Konfigurieren Sie Name / Vollständiger Name / Flair usw. nach Belieben.

2. Gehen Sie zu den „Mitgliedschaft"-Einstellungen, setzen Sie den Cursor in das Dropdown-Menü „SSO-Rollen" und wählen Sie eine Rolle aus dem Dropdown-Menü. Falls Discourse noch niemanden mit dieser Rolle hat einloggen sehen, müssen Sie sie manuell eingeben.

   

   Sie können mehrere Rollen für eine einzelne Discourse-Gruppe angeben. Zum Beispiel könnte eine „Team"-Gruppe in Discourse eine Kombination aus oidc:employees und oidc:contractors sein.

3. Klicken Sie auf Speichern, und die Gruppenmitgliedschaft wird sofort mit den von Discourse aus früheren Anmeldungen zwischengespeicherten Rolleninformationen aktualisiert.

4. Bei zukünftigen Anmeldungen werden Änderungen an den Rollen des Identitätsanbieters in der Discourse-Gruppe widergespiegelt.

5. Sie können Benutzer weiterhin in der nativen Discourse-Benutzeroberfläche zur Gruppe hinzufügen oder entfernen.

   • Wenn Sie versuchen, einen Benutzer zu entfernen, der über einen Identitätsanbieter hinzugefügt wurde, wird eine Warnung angezeigt, dass der Benutzer beim nächsten Anmelden erneut hinzugefügt werden könnte.

6. Wenn Sie später entscheiden, dass diese IDP-Rolle nicht mit der Gruppe verknüpft sein soll, können Sie sie entfernen. Alle Benutzer, die Mitglieder über diese Rolle waren, werden ebenfalls entfernt.

[angus (Angus McLeod)]

@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, 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.

[david (David Taylor)]

@angus

Ich vermute, wir hätten auch eine Methode group_sync_enabled? in Auth::Authenticator.

@angus

Dies könnte auch von den spezifischen Dienst-Authentifizierern verwendet werden.

Ja, definitiv. Ich habe dabei besonders an Google gedacht, da viele es für ihre GSuite-Organisationen nutzen, die meines Wissens nach ein Konzept für Gruppen haben.

@angus

hier haben wir auf „Rollen“ statt „Gruppen“ umgestellt. Kein großes Problem, aber ich möchte sicherstellen, dass ich nichts übersehe.

Ich wollte eigentlich jede Verwirrung zwischen „Identity Provider-Gruppen“ und „Discourse-Gruppen“ vermeiden … aber es ist möglich, dass ich durch die Namensänderung die Sache nur noch verworrener gemacht habe. Ich bin sehr gerne bereit, hier bei „Gruppen“ zu bleiben.

@angus

vielleicht sollten wir eine Fremdschlüssel-Beziehung mit user_associated_accounts anstelle von provider_name verwenden.

Mein Gedanke war, dass wir weiterhin nicht-verwaltete Authentifizierungsanbieter unterstützen, sodass es möglicherweise keinen Datensatz in user_associated_accounts gibt. Wie du gesagt hast, können wir trotzdem über die user_id darauf zugreifen

@angus

diese Informationen auf Anbieterbasis bereitzustellen, dank der von dir vorgeschlagenen Site-Einstellung, was auch den Fall abdecken würde, dass die Rolle noch nicht gesehen wurde.

Ich bin mir nicht sicher, ob die Site-Einstellung hier weiterhilft. Wenn wir über ein Array von Strings sprechen, das „Rollen“ repräsentiert, würde die Site-Einstellung nicht angeben, was die Rollen tatsächlich sind. Sie würde nur festlegen, wie das Array abgerufen wird. Macht das Sinn?

@angus

Ich denke, das ist ein guter Kompromiss. Besonders wenn wir auch die unten erwähnte Site-Einstellung haben.

Klingt großartig

[angus (Angus McLeod)]

@david

Ich bin mir nicht sicher, ob die Seiteneinstellung hier helfen würde. Wenn wir über ein Array von Strings sprechen, das „Rollen“ darstellt, würde die Seiteneinstellung nicht angeben, was die Rollen tatsächlich sind. Sie würde nur festlegen, wie das Array abgerufen wird. Macht das Sinn?

Ja, du hast recht. Ich dachte noch an eine vorherige Implementierung, bei der ich spezifische Gruppen direkt in der Einstellung angegeben hatte, aber das machen wir hier nicht, was in Ordnung ist.

Ich denke, es gibt hier genug Informationen, um mit der Arbeit am PR zu beginnen. Ich werde diesen später in dieser Woche starten, es sei denn, du hast noch Bedenken? Falls unterwegs etwas aufkommt, werde ich hier ein Update geben.

[david (David Taylor)]

Klingt großartig – ich helfe gerne bei allen Problemen oder Fragen auf dem Weg weiter

[angus (Angus McLeod)]

Ok, ich habe endlich einen Arbeitsstand, den ich hier teilen kann

Associated group memberships (#12446)

Ein paar Anmerkungen.

Ich habe mich für den etwas komplexeren Fall von Google Apps HD-Gruppen als erste Implementierung entschieden, da ich denke, dass dies hilft, die möglichen Permutationen davon durchzudenken, z. B. die Notwendigkeit, domänenspezifische Gruppen eines Anbieters zu berücksichtigen.

Um diesen Anwendungsfall zu implementieren, musste ich an der Stelle der Authentifizierung ein neues Konzept der „sekundären Autorisierung

[david (David Taylor)]

Das sieht wirklich cool aus!

@angus

Ich musste an der Stelle der Authentifizierung auch ein neues Konzept der „sekundären Autorisierung" einführen.

Ich bin etwas skeptisch bezüglich der „sekundären Autorisierung

[mattdm (Matthew Miller)]

Ich verfolge das mit Interesse – und werfe als verwandten Link noch diesen ein: Does `sso overrides groups` work with Oauth2?

Für meinen Anwendungsfall wäre ich völlig zufrieden, wenn das Discourse Connect-Verhalten auch für andere Authentifizierungsanbieter implementiert würde.

[angus (Angus McLeod)]

Super Wir sind schon fast soweit.

[quote=“david, post:13, topic:175950”]
Ich bin ein bisschen skeptisch bezüglich der „sekundären Autorisierung

[angus (Angus McLeod)]

@david Ich habe gerade ein paar Updates dafür eingepflegt, darunter:

• DistributedMutxes und in_batches in group_associated_group
• Akzeptanztests (bereits mit rspec vorhanden)

Es wird zweifellos noch weitere Arbeiten erfordern, aber aktuell funktioniert es gemäß der Spezifikation und alle Tests bestehen. Probier es gerne aus, lass mich wissen, was du denkst und welche Änderungen du dir wünschst.

Associated group memberships (#12446)

[sam (Sam Saffron)]

Vielleicht wäre es gut, es vorerst als Nicht-Entwurf zu markieren?

[mattdm (Matthew Miller)]

Hallo @angus! Ich frage mich, ob du in dieser Hinsicht weitere Fortschritte gemacht hast? Das einfache „strict"-Verhalten interessiert mich sehr, wie ich es verstehe, und da wir unseren OAuth2/OpenID-Connect-Anbieter selbst steuern, mache ich mir keine Sorgen um den Fall der „sekundären Autorisierung". Besteht die Chance, dass so etwas bald umgesetzt wird?

Falls es hilft: Unsere Umgebung ist hier dokumentiert: Infrastructure/Authentication - Fedora Project Wiki. Ich habe Discourse so konfiguriert, dass es den OAuth2-Scope openid profile email https://id.fedoraproject.org/scope/groups anfordert.

Im Wesentlichen wünsche ich mir Folgendes:

• Vertrauensebene und Mitarbeitergruppen unverändert lassen
• Den Benutzer zu allen vorhandenen Discourse-Gruppen hinzufügen, die in der Liste aus dem SSO enthalten sind, sofern er noch nicht Mitglied ist
• Den Benutzer aus allen Gruppen entfernen, in denen er Mitglied ist, aber die nicht in der Liste enthalten sind

Ich gebe gerne zu, dass ich nicht alle Feinheiten verstehe … gibt es eine Komplikation, die mir entgangen ist?

[angus (Angus McLeod)]

Ich habe mir dieses Wochenende Zeit genommen, um an diesem Thema zu arbeiten, Matt. Nächste Woche werde ich ein Update haben, wahrscheinlich auf dem PR auf GitHub.

Associated group memberships (#12446)

[mattdm (Matthew Miller)]

Super – vielen Dank! Ich will nicht drängeln, aber das Discourse-Support-Team hat empfohlen, in diesem Thema zu posten, um den aktuellen Stand der Dinge zu sehen.

Ich freue mich sehr auf eure Arbeit daran, denn sobald wir das haben, können wir mit den Fedora-Discourse-Seiten so viel machen, was uns aktuell noch nicht möglich ist!