Benutzerdefinierte Ansprüche mit Geneva Framework und wie Sie Benutzer "synchronisieren"

Question

Vielleicht zeigt diese Frage, wie wenig ich über Ansprüche -Identitätsmanagement weiß, aber hier geht es.

Wenn Sie WIF in einer Anwendung verwenden, die eine STS von Drittanbietern für die Identität verwendet und benutzerdefinierte Ansprüche für die Autorisierung verwendet (etwas Relevantes und spezifiziert die Anwendung wie CanCreateFoobar)

1) Wie verwalte ich die Benutzer? Dh die Benutzer von Say AD oder anderen Mitgliedschaftsanbietern können identifiziert werden, aber intern in meinem System muss ich über sie wissen und haben mehr Benutzerinformationen, die nichts mit Identität zu tun haben (daher ist es wirklich sinnvoll, diese Informationen verfügbar zu haben außerhalb des Systems) und diese Informationen über den Benutzer sollten bestehen bleiben,
Die Frage ist, wie ich meine Systemdaten (beginnend nach den IDs) auf intelligente Weise verwalten und erstellen kann.
Das genaue Szenario, das ich in meinem Kopf habe, ist, dass ein neuer Mitarbeiter dem Unternehmen hinzugefügt wird. SYS Admin schafft den Benutzer für die Domain mit einer bestimmten Rolle. Wie kann mein System diese Tatsache bewusst sind? (Ich möchte wahrscheinlich, dass das System einen Administrator des Systems für eine Aktion auffordert

2) Wo sind die Anspruchswerte für die gespeicherten Benutzer und Rollen und wie kann ich sie ändern? Idealerweise möchte ich in der Lage sein, die Umfang für einen bestimmten Benutzer und eine bestimmte Aktion zu ändern. Gibt es irgendwelche Richtlinien dazu?

Ich kann sehen, dass dies wahrscheinlich sehr lahme Fragen sind, aber wenn ich darüber nachdenke, wie ich das Problem lösen kann, habe ich über komplizierte Lösungen oder mit Lösungen, die viel Duplikaiton erfordern (dh erstellen die verwendeten an zwei Stellen), also bin ich mir sicher, dass ich mir sicher bin, dass Ich denke einfach nicht auf dieses Problem auf die richtige Weise nach

Vielen Dank

Answer 1

1) Sie verwalten die Benutzer nicht wirklich. Sie nehmen einfach die iClaimSIDIDIENDITY und verwenden diese als Quelle für Ihre Autorisierung. Meiner Meinung nach sollten Sie die Behauptungen nicht behalten, wenn Sie ohne dies davonkommen können - die Behauptungen sollten die Quelle Ihrer Benutzerinformationen sein.

Wenn Sie auf den Ansprüchen aufbauen möchten, nehmen Sie eine eindeutige Referenz aus der Ansprüche -Identität, sagen Sie E -Mail -Adresse oder PPID/Signierschlüssel OU Hash und verwenden Sie diese, um Ihre eigene Datenbank zu erstellen und Ihre eigenen Informationen hinzuzufügen.

Ihr System wird jedoch niemals von Änderungen in einer Identitätsmetabase eines Drittanbieters entfernt - erst wenn ein neues SAML -Token in Ihrem Antrag ausgestellt und analysiert wird.

2) Die Schadenswerte werden nirgends gespeichert, es sei denn, Sie speichern sie. Wie Sie das in Berechtigungen übersetzen, liegt bei Ihnen - aber im Allgemeinen führen Sie Ansprüche Transformation durch, um die externen Ansprüche aufzunehmen und sie an Ansprüche auf Ihre Bewerbung zuzuordnen, die Sie für Berechtigungen verwenden. Da Ansprüche von externen Anbietern stammen, können Sie sie nicht ändern - Sie haben keine Verbindung zu diesen Anbietern.

Answer 2

Wie Sie sehen, lindert die Föderation nicht unbedingt die Notwendigkeit einer Bereitstellung. Dies ist ein wichtiger Einblick, der nicht sofort offensichtlich ist.

Es gibt mehrere Möglichkeiten, dies anzugehen, einschließlich:

1. Die Verwendung eines Meta- oder virtuellen Verzeichnisprodukts oder
2. Durch die Verwendung von "JIT-Bereitstellung" (auch bekannt als "dynamische Bereitstellung" oder "On-the Fly Provisioning").

Lassen Sie mich Letzteres erklären. Diese Lösung, was ich auch in meinem Blog beschreibe, Enthält zwei STSS, ein IP-STS und ein RP-STS. Der erste authentifiziert den Benutzer; Die zweite ist spezifisch für Ihre Bewerbung und weiß, welche Ansprüche erforderlich sind, um die Benutzer dieses Systems zu autorisieren. Die IP-STS können diese anwendungsspezifischen Attribute nicht ausgeben. Durch diese müssen Ihr Unternehmensverzeichnisdienst mit allen Arten von anwendungsspezifischen Informationen überlagert. Stattdessen sind die Attribute für Benutzer, die in diesem Geschäft verwaltet und von den IP-STS ausgegeben werden, allgemein in der Natur und gilt für den Benutzer, unabhängig davon, welche Anwendung sie verwenden. Nach der Authentifizierung der IP-STS und der Erhalt von Identitätsansprüchen daraus wird das Token an die RP-STS weitergegeben. Dieser Token -Service ist eng mit Ihrer Bewerbung verbunden. Es weiß, welche Behauptungen, dass Benutzer auf verschiedene Ressourcen zugreifen müssen. Es kann die Nur-Identitätsansprüche in die erforderlichen Umstände umwandeln, um diese Zugriffskontrollentscheidung zu treffen. Das RP-STS ist also ein Schadenstransformator, der die Identitätsansprüche in App-spezifische Ansprüche einbinden.

Wie liefert die RP-STS den Benutzer? Angenommen, ein neuer Mitarbeiter wird wie in Ihrem Beispiel oben erstellt. Wenn der Benutzer auf Ihre App zugreift, wird er zu den RP-STS abprallt. Er wird dort nicht protokolliert, also wird er zu den IP-STS abprallen. Der SYS-Administrator hat ein Konto für ihn erstellt, damit er sich anmelden kann, und sein Browser wird ihn zu den RP-STS zurückspringen. Die RP-STS knacken das Token, erhalten die Benutzer-ID (E-Mail, PPID usw.) und sehen, dass es nicht weiß, wer der Benutzer ist. Daher werden die RP-STS den Benutzer bereitstellen. Dies wird beispielsweise eine Webseite angezeigt. Es kann Informationen erfassen, die die Rolle dieses Benutzers beim Zugriff auf die RP ermitteln. Danach wird der Benutzer bereitgestellt (dh ein Datensatz wird in seiner Datenbank erstellt, die Anspruchswerte für ihn enthält), und die RP-STS werden ein für Ihre Bewerbung spezifisches Token ausstellen und ihn dort weiterleiten. Die Bewerbung wird nicht wissen, dass er nur bereitgestellt wurde. Es wird nur die Behauptungen wie immer verwenden. (Sehen Sie, warum ich es JIT -Bereitstellung genannt habe?)

Was ist, wenn sich die Dinge ändern, nachdem der Benutzer bereitgestellt wurde? OK. Stellen Sie sich Folgendes vor: Der Benutzer wurde vor seit langem im Verzeichnisgeschäft erstellt und wurde wie oben in den RP-STS beschrieben bereitgestellt. Er nutzt das System schon lange glücklich. Anschließend gibt es eine Richtlinienänderung, bei der Benutzer Ihrer Anwendung neue Bedingungen (T & CS) akzeptieren müssen. Wenn sich der Benutzer das nächste Mal bei der App anmeldet, wird er zu den RP-STS, zu den IP-STS umgeleitet, er authentifiziert und zu Ihren RP-STS zurückgezogen. Zu diesem Zeitpunkt wird festgestellt, dass der Benutzer die neuen T & Cs akzeptieren muss, sodass der Benutzer eine Webseite angezeigt und seine Vereinbarung abhängt. Danach geben die RP-STS ein Sicherheitstoken aus und leiten ihn zu Ihrer App um. Ihre App wird wie immer die Ansprüche übernehmen und das tun, was sie tun muss, um den Zugriff zu genehmigen. Es wird es nicht wissen und es wird sich nicht interessieren, dass der Benutzer nur "neu aufgestellt" wurde. Alternativ können Sie Änderungen in der Synchronisierung zwischen dem Identitätsgeschäft (dh Ihrem Unternehmensverzeichnis) und dem Schadenspeicher Ihrer RP-STS unter Verwendung eines Produkts wie ILM (oder FIM, wie es jetzt genannt wird) beibehalten. Abhängig von Ihrem System kann ein Produkt, das eine solche Rücksperrsynchronisation durchführt, angemessener sein.

Übrigens, das sind keine "lahmen" Fragen! Es gibt sehr scharfe Fragen, die tiefgreifende Gedanken und intelligente Reflexion über ein sehr kompliziertes Problem widerspiegeln. Andere, die Sie beantworten müssen, umfassen:

• Wie aktualisieren Administratoren Ihrer Anwendung ihre Richtlinien (z. B. ändern die T & Cs)? Welche Benutzeroberfläche/API müssen Sie erstellen? Ist die Benutzeroberfläche in diejenige integriert, die zur Verwaltung der IP-STS-Richtlinie verwendet wird?
• Welche Art von Vertrauensbeziehungen müssen existieren, damit ein solches System funktioniert?
• Was ist, wenn das Thema das passive Profil nicht verwendet? Was ist, wenn er das aktive Profil verwendet und/oder es keine Benutzeroberfläche gibt?
• Wie und wo befinden sich Schlüssel? Welche Berechtigungen werden benötigt, um diese Schlüssel zu verwenden? Wie werden sie überarbeitet, verteilt und wie werden SYS -Administratoren alarmiert, wenn sie ablaufen?

Dieses Zeug ist bei Benutzergruppen Meetings und Konferenzen wirklich einfach zu demonstrieren, aber in Wirklichkeit ist es sehr fortgeschritten. Wenn Sie andere Fragen haben, können Sie sie hier oder hier veröffentlichen oder Machen Sie sich direkt mit mir in Verbindung.