Ansprüche sind Aussagen (z. B. Name, Identität, Schlüssel, Gruppe, Berechtigung oder Funktion), die über Benutzer getroffen werden (und von beiden Partnern in einem Active Directory-Verbunddienst verstanden werden) und für die Autorisierung durch eine Anwendung verwendet werden.

Der AD FS-Verbunddienst handelt das Vertrauen zwischen vielen unterschiedlichen Einheiten aus. Der Dienst ist so konzipiert, dass er den vertrauenswürdigen Austausch von Ansprüchen ermöglicht, die beliebige Werte enthalten. Diese Ansprüche werden dann vom Empfänger (z. B. einem Ressourcenpartner) verwendet, um Autorisierungsentscheidungen zu treffen.

Ansprüche können den Verbunddienst auf drei verschiedene Arten durchlaufen:

  • Vom Kontospeicher zum Kontoverbunddienst und dann zum Ressourcenpartner

  • Vom Kontopartner zum Ressourcenverbunddienst und dann zur Ressourcenanwendung

  • Vom Kontospeicher zum Verbunddienst und dann zur Ressourcenanwendung

Der Verbunddienst kann dabei so konfiguriert werden, dass er alle drei Rollen übernimmt. Daher ist es möglich, dass ein einzelner Verbunddienst alle drei Kommunikationswege zur Verfügung stellt.

Der Verbunddienst unterstützt drei Arten von Ansprüchen: Identitätsansprüche, Gruppenansprüche und benutzerdefinierte Ansprüche. In der folgenden Tabelle werden die einzelnen Anspruchstypen ausführlicher erläutert.

Anspruchstyp Beschreibung

Identität

Ansprüche vom Typ UPN, E-Mail und allgemeiner Name werden in AD FS als Identitätsanspruchstypen bezeichnet.

  • UPN: steht für einen Kerberos-Benutzerprinzipalnamen (User Principal Name, UPN), z. B. benutzer@bereich. Nur ein Anspruch darf vom Typ UPN sein. Auch wenn mehrere UPN-Werte kommuniziert werden müssen, darf nur einer den Typ UPN aufweisen. Zusätzliche UPNs können als benutzerdefinierte Ansprüche konfiguriert werden.

  • E-Mail: steht für RFC 2822-E-Mail-Namen (Request for Comments) der Form benutzer@domaene. Nur ein Anspruch darf vom Typ E-Mail sein. Auch wenn mehrere E-Mail-Werte kommuniziert werden müssen, darf nur einer den Typ E-Mail aufweisen. Zusätzliche E-Mails können als benutzerdefinierte Ansprüche konfiguriert werden.

  • Allgemeiner Name: steht für eine beliebige Zeichenfolge, die für die Personalisierung verwendet wird. Beispiele hierfür sind "John Smith" oder "Mitarbeiter von Tailspin Toys". Nur ein Anspruch darf vom Typ allgemeiner Name sein. Es ist wichtig zu wissen, dass es keinen Mechanismus gibt, durch den die Eindeutigkeit des allgemeinen Namensanspruchs sichergestellt werden kann. Sie sollten daher mit Vorsicht vorgehen, wenn Sie diesen Anspruchstyp bei Autorisierungsentscheidungen verwenden.

Gruppe

Steht für die Mitgliedschaft in einer Gruppe oder einer Rolle. Administratoren definieren individuelle Ansprüche, die den Gruppentyp Gruppenansprüche aufweisen. Sie können beispielsweise folgenden Gruppenanspruch als Gruppe definieren: [Entwickler, Tester, Programm-Manager]. Jeder Gruppenanspruch wird in Bezug auf die Auffüllung und die Zuordnung von Ansprüchen als separate Verwaltungseinheit behandelt. Sie können sich den Wert eines Gruppenanspruchs als booleschen Wert vorstellen, der die Mitgliedschaft anzeigt.

Benutzerdefiniert

Steht für einen Anspruch, der benutzerdefinierte Informationen zu einem Benutzer enthält, z. B. die ID-Nummer eines Mitarbeiters.

Wenn in einem Token mehr als einer der drei Identitätsanspruchstypen vorhanden ist, werden die Identitätsansprüche in der folgenden Reihenfolge nach Priorität geordnet:

  1. UPN

  2. E-Mail

  3. Allgemeiner Name

Es muss mindestens einer dieser Identitätsanspruchstypen vorhanden sein, um ein Token ausstellen zu können.

Anspruchszuordnung

Von AD FS wird das WS-Verbund-PRP (WS-Federation Passive Requestor Protocol, WS-F PRP) verwendet, das Ansprüche in vom Verbunddienst ausgestellten Sicherheitstoken überträgt. Die Ansprüche werden ursprünglich durch Kontospeicher aufgefüllt. Dabei handelt es sich entweder um Kontospeicher von Active Directory-Domänendiensten (Active Directory Domain Services, AD DS) oder Kontospeicher von Active Directory Lightweight Directory Services (AD LDS).

Der Verbunddienst kann Ansprüche zuordnen, wenn sie an einen Verbundpartner gesendet oder von einem Verbundpartner empfangen werden. Die Anspruchszuordnung ist das Zuordnen, Entfernen oder Filtern von eingehenden Ansprüchen oder das Weiterleiten von eingehenden Ansprüchen an ausgehende Ansprüche. Die Anspruchszuordnung kann sich für jeden Verbundpartner unterscheiden. Die Definition der Auffüllung und Zuordnung dieser Ansprüche ist für die Konfiguration des Verbunds sehr wichtig. Für Anspruchszuordnungen werden Zeichenfolgenvergleiche verwendet, bei denen die Groß-/Kleinschreibung berücksichtigt wird. Der Prozess der Anspruchszuordnung ist in der folgenden Abbildung dargestellt.

Anspruchs-Zuordnungsprozess

Gruppen von Organisationsansprüchen

Für alle eingehenden Ansprüche erfolgt eine Zuordnung in Organisationsansprüche. Bei Organisationsansprüchen handelt es sich um Ansprüche in einer Zwischenform bzw. normalisierten Form innerhalb des Namespaces einer Organisation. Alle internen Verbunddienstaktionen werden für die zusammengefassten Organisationsansprüche ausgeführt. Organisationsansprüche werden von Ressourcenanwendungen verarbeitet.

Bei Organisationsansprüchen müssen Zuordnungen zwischen zwei Organisationen, die miteinander kommunizieren müssen, nicht einzeln verwaltet werden. Jede Organisation definiert nur jeweils eine Zuordnung in einer Richtung (entweder auf ihre Organisationsansprüche hin weisend oder von diesen Organisationsansprüchen ausgehend). Auf diese Weise wird die Komplexität der AD FS-Verwaltung verringert. Beispiel für einen Verbund mit folgender Konfiguration:

x Kontopartner

y Ressourcenanwendungen

Der Verbund verfügt somit über x + y Anspruchszuordnungen.

Dies ist im Vergleich zu möglichen x × y Anspruchszuordnungen eine beträchtliche Reduzierung. Weiteres Beispiel für einen Verbunddienst mit folgender Konfiguration:

3 Kontopartner

7 Ressourcenanwendungen

Der Verbund benötigt nur 10 Anspruchszuordnungen, und nicht 21 potenzielle Anspruchszuordnungen, wenn die Zuordnung direkt von den eingehenden Ansprüchen zu den ausgehenden Ansprüchen erfolgt.

E-Mail

Für E-Mail-Anspruchstypen erfolgt die Zuordnung immer zu E-Mail-Anspruchstypen. Als Teil dieser Zuordnung im Kontoverbunddienst kann das Domänensuffix einem konstanten Wert zugeordnet werden. Durch das Zuordnen eines Domänensuffixes zu einem konstanten Wert wird verhindert, dass eine Partnerorganisation einer anderen Organisation versehentlich Informationen über ihre interne Gesamtstruktur bereitstellt. Im Ressourcenverbunddienst kann das Domänensuffix anhand einer Liste mit konstanten Werten gefiltert werden.

Im folgenden Beispiel wird ein AD FS-Verbund zwischen zwei Organisationen – Tailspin Toys und Adventure Works – beschrieben. Tailspin Toys ist hierbei der Kontopartner, Adventure Works der Ressourcenpartner.

  • Tailspin Toys als Kontoverbunddienst ordnet den E-Mail-Organisationsanspruch dem ausgehenden E-Mail-Anspruch für Adventure Works zu. Als Teil dieser Zuordnung werden alle E-Mail-Suffixe tailspintoys.com zugeordnet. Wenn beispielsweise der E-Mail-Organisationsanspruch (e-mail=jsmith@sales.tailspintoys.com) verwendet wird, lautet der ausgehende E-Mail-Anspruch (e-mail=jsmith@tailspintoys.com).

  • Adventure Works als Ressourcenverbunddienst ordnet den eingehenden E-Mail-Anspruch von Tailspin Toys dem E-Mail-Organisationsanspruch zu und filtert die Suffixliste während dieser Zuordnung unter Verwendung von tailspintoys.com. Ein eingehender E-Mail-Anspruch von Tailspin Toys (e-mail=jsmith@tailspintoys.com) wird also akzeptiert, während ein eingehender E-Mail-Anspruch von Adventure Works (e-mail=jsmith@adventure-works.com) abgelehnt wird.

UPN

Für UPN-Anspruchstypen erfolgt die Zuordnung immer zu UPN-Anspruchstypen. Sie unterliegen wie E-Mail-Ansprüche auch der Suffixzuordnung und -filterung. Da AD DS jedoch UPNs ohne @-Symbol zulässt, fügt der Kontoverbunddienst das @-Symbol gefolgt vom entsprechenden Suffix an, wenn eine UPN-Suffixzuordnung definiert wurde. Andernfalls übergibt der Verbunddienst den UPN unverändert, also ohne das @-Symbol, wenn ein Suffix übergeben wird. Auf der Ressourcenseite wird der UPN ohne das @-Symbol akzeptiert, wenn ein beliebiges UPN-Suffix zulässig ist. Wenn nur ein bestimmtes UPN-Suffix zulässig ist, wird der UPN ohne das @-Symbol abgelehnt.

Allgemeiner Name

Für allgemeine Namensansprüche erfolgt die Zuordnung immer zu allgemeinen Namensansprüchen. Sie unterliegen keinen weiteren Regeln.

Benutzerdefiniert

Für benutzerdefinierte Anspruchstypen erfolgt die Zuordnung immer zu anderen benutzerdefinierten Anspruchstypen. Wenn beispielsweise eine eingehende Anspruchsgruppe (UPN, Custom=[MitarbeiterNr, SteuerzahlerID]) und eine Organisationsanspruchsgruppe (UPN, Custom=[Mitarbeiter, SSN]) vorliegen, können Sie Zuordnungen von MitarbeiterNr zu Mitarbeiter und von SteuerzahlerID zu SSN erstellen.

Gruppe

Für Gruppenanspruchstypen erfolgt die Zuordnung immer zu anderen Gruppenanspruchstypen. Wenn beispielsweise eine eingehende Anspruchsgruppe (UPN, Group=[Eins, Zwei, Drei]) und eine Organisationsanspruchsgruppe (UPN, Group=[X,Y,Z]) vorliegen, können Sie Zuordnungen von Eins zu Y, von Zwei zu X und von Drei zu Z erstellen.

Zuordnung Gruppe/UPN

Zusätzlich zu den oben beschriebenen Standardzuordnungen können Sie für Ansprüche auch eine spezielle Zuordnung Gruppe/UPN verwenden. Die Zuordnung Gruppe/UPN wird vom Ressourcenverbunddienst nur unterstützt, wenn eingehende Ansprüche eines Kontopartners vorliegen. In diesem Fall werden UPN-Anspruchstypen nicht UPN-Anspruchstypen zugeordnet. Stattdessen stellen Sie für die Zuordnung Gruppe/UPN eine geordnete Liste bereit.

Die Liste mit dieser Zuordnung könnte beispielsweise folgendermaßen lauten:

  1. Entw zu entwickler@internal.tailspintoys.com

  2. Test zu tester@internal.tailspintoys.com

  3. PM zu progmgr@internal.tailspintoys.com

Für eine eingehende Anspruchsgruppe (Common name=John Smith, Group=[Entw]) enthält die Organisationsanspruchsgruppe den Wert (Common name=John Smith, UPN=entwickler@internal.tailspintoys.com). Beachten Sie, dass die Liste geordnet ist. Daher ergibt die Anspruchsgruppe (Common name=John Smith, Group=[Entw,PM]) den Wert (Common name=John Smith, UPN=entwickler@internal.tailspintoys.com). Wenn der eingehende Anspruch über einen UPN verfügt, wird dieser überschrieben. Diese spezielle Zuordnungsregel unterstützt gruppenbasierte Ressourcenkonten, die auf Legacyressourcen zugreifen. Die Reihenfolge der Zuordnung Gruppe/UPN ist in der Vertrauensrichtlinie des Verbunddiensts angegeben.

Anspruchsüberwachung

Einige Gruppenansprüche und benutzerdefinierte Ansprüche können als überprüfbar eingestuft werden. Wenn die Überwachung aktiviert ist, wird damit zugelassen, dass der Name des Anspruchs im Sicherheitsereignisprotokoll offen gelegt wird, der Wert des Anspruchs wird jedoch nicht angegeben. Ein Beispiel für einen überprüfbaren Anspruch ist die Sozialversicherungsnummer. Der Name des Anspruchs, also Sozialversicherungsnummer, wird offen gelegt, aber der eigentliche Zahlenwert, der im Anspruch gespeichert ist, wird nicht offen gelegt. Der Wert des Anspruchs wird nicht überprüft, wenn der Anspruch erstellt oder zugeordnet wird.

Hinweis

Identitätsanspruchstypen sind immer überprüfbar.

Siehe auch

Inhaltsverzeichnis