Anspruchsbasierte Identität – Übersicht und Konzepte

Letzte Änderung: Donnerstag, 18. März 2010

Gilt für: SharePoint Foundation 2010

Anspruchsbasiertes Identitätsmodell

Wenn Sie Ansprüche unterstützende Anwendungen erstellen, legt der Benutzer der Anwendung eine Identität als einen Satz von Ansprüchen vor. Ein Anspruch kann z. B. der Benutzername sein, ein anderer eine E-Mail-Adresse. Der Grundgedanke ist, dass ein externes Identitätssystem so konfiguriert ist, dass Ihre Anwendung bei jeder Anfrage des Benutzers alle benötigten Informationen erhält und eine kryptografische Garantie dahingehend gegeben wird, dass die erhaltenen Identitätsdaten von einer vertrauenswürdigen Quelle stammen.

Bei diesem Modell ist eine einmalige Anmeldung viel leichter durchzusetzen, und Ihre Anwendung ist nicht mehr für Folgendes zuständig:

• Authentifizierung von Benutzern

• Speicherung von Benutzerkonten und Kennwörtern

• Aufruf von Unternehmensverzeichnissen zum Nachschlagen von Benutzeridentitätsdetails

• Integration mit Identitätssystemen anderer Plattformen oder Unternehmen

In diesem Modell trifft Ihre Anwendung identitätsbezogene Entscheidungen basierend auf vom Benutzer vorlegten Ansprüchen. Hierbei kann es sich um eine einfache Anwendungsanpassung mit dem Vornamen des Benutzers oder eine Autorisierung des Benutzers für einen Zugriff auf Mehrwertfunktionen und Ressourcen in Ihrer Anwendung handeln.

In den folgenden Abschnitten und Themen werden die Begriffe und Konzepte zur besseren Veranschaulichung der anspruchsbasierten Identitätsarchitektur behandelt.

Identität

Unter "Identität" ist in diesem Kontext eine Gruppe von Attributen zu verstehen, die einen Benutzer oder eine andere Entität in einem System beschreibt, das Sie absichern möchten.

Anspruch

Stellen Sie sich einen Anspruch als eine Identitätsinformation vor (z. B. Name, E-Mail-Adresse, Alter oder Mitglied der Rolle "Vertrieb"). Je mehr Ansprüche Ihre Anwendung empfängt, desto mehr wissen Sie über Ihren Benutzer. Diese werden aufgrund der Übermittlungsmethode als "Ansprüche" und nicht als "Attribute" (wie ansonsten bei der Beschreibung von Unternehmensverzeichnissen üblich) bezeichnet. In diesem Modell schlägt Ihre Anwendung keine Benutzerattribute in einem Verzeichnis nach, sondern der Benutzer übermittelt Ansprüche an Ihre Anwendung, die von dieser geprüft werden. Jeder Anspruch stammt von einem Aussteller, und Sie vertrauen dem Anspruch nur in dem Maß, in dem Sie dem Aussteller vertrauen. Sie vertrauen z. B. einem Anspruch des Domänencontrollers Ihres Unternehmens mehr als einem Anspruch, den der Benutzer stellt.

Sicherheitstoken

Der Benutzer übermittelt eine Gruppe von Ansprüchen zusammen mit einer Anforderung an Ihre Anwendung. Bei einem Webdienst werden diese Ansprüche im Sicherheitsheader des SOAP-Umschlags übertragen. Bei einer browserbasierten Webanwendung gelangen die Ansprüche über einen HTTP POST-Befehl aus dem Browser des Benutzers in das System und können später in einem Cookie zwischengespeichert werden, falls eine Sitzung gewünscht wird. Unabhängig davon, wie diese Ansprüche eingehen, müssen sie serialisiert werden. An dieser Stelle kommen Sicherheitstoken ins Spiel. Ein Sicherheitstoken ist eine serialisierte Gruppe von Ansprüchen, die von der ausstellenden Stelle digital signiert wurde. Die Signatur ist wichtig, denn Sie gibt Ihnen die Gewissheit, dass der Benutzer nicht bloß Ansprüche erfunden und an Sie übermittelt hat. In Szenarien mit niedrigen Sicherheitseinstellungen, in denen Kryptografie nicht erforderlich oder erwünscht ist, kann mit unsignierten Token gearbeitet werden, was aber in diesem Thema nicht behandelt wird.

Eine der Hauptfunktionen in Windows Identity Foundation (WIF) ist die Möglichkeit des Erstellens und Lesens von Sicherheitstoken. WIF und Microsoft .NET Framework sind für sämtliche kryptografischen Aufgaben zuständig und legen Ihrer Anwendung eine Gruppe von Ansprüchen vor, die diese lesen kann.

Sicherheitstokendienst (Security Token Service, STS)

Ein Sicherheitstokendienst (STS) ist das Gefüge, in dem Sicherheitstoken gemäß den interoperablen Protokollen, die im Abschnitt "Standards" in diesem Thema beschrieben werden, erstellt, signiert und ausgestellt werden. Die Implementierung dieser Protokolle ist mit vielen Aufgaben verbunden, die aber allein von WIF bewältigt werden, sodass auch Personen, die keine Protokollexperten sind, einen STS bei sehr kleinem Aufwand einrichten und in Betrieb nehmen können.

WIF macht das Erstellen eines eigenen STS einfach. Sie müssen lediglich bestimmen, wie die Logik samt Durchsetzungsregeln (d. h. die Sicherheitsrichtlinie) implementiert werden soll.

Ausstellende Stelle

Es gibt viele verschiedene Typen ausstellender Stellen, so z. B. Domänencontroller, die Kerberos-Tickets ausstellen, oder Zertifizierungsstellen, die X.509-Zertifikate ausstellen. Der in diesem Thema behandelte spezifische Stellentyp stellt Sicherheitstoken aus, die Ansprüche enthalten. Diese ausstellende Stelle ist eine Webanwendung oder ein Webdienst, der Sicherheitstoken ausstellt. Sie muss in der Lage sein, angesichts der vertrauenden Zielseite und des Benutzers, der die Anforderung stellt, die ordnungsgemäßen Ansprüche zu stellen, und kann ggf. für die Interaktion mit Benutzerdatenspeichern zum Nachschlagen von Ansprüchen und Authentifizieren von Benutzern zuständig sein.

Unabhängig davon, welche ausstellende Stelle Sie wählen, spielt diese eine Kernrolle in Ihrer Identitätslösung. Wenn Sie die Authentifizierung aus Ihrer Anwendung ausklammern, indem Sie auf Ansprüche setzen, übergeben Sie die Zuständigkeit an diese Stelle und fordern sie auf, die Authentifizierung von Benutzern in Ihrem Auftrag zu übernehmen.

Vertrauende Seite

Wenn Sie eine Anwendung erstellen, die mit Ansprüchen arbeitet, erstellen Sie eine Anwendung mit vertrauender Seite. Synonyme für eine vertrauende Seite sind "Ansprüche unterstützende Anwendung" und "Anspruchsbasierte Anwendung". Webanwendungen und -dienste können vertrauende Seiten sein.

Eine Anwendung mit vertrauender Seite verwendet von einem STS ausgestellte Token und extrahiert aus diesen Ansprüche, die für identitätsbezogene Aufgaben verwendet werden. Der STS unterstützt zwei Typen von Anwendungen mit vertrauender Seite: ASP.NET-Webanwendungen und Windows Communication Foundation (WCF)-Webdienste.

Standards

Um Interoperabilität zu gewährleisten, werden im zuvor beschriebenen Szenario mehrere WS-*-Standards beschrieben. Die Richtlinie wird mithilfe von WS-MetadataExchange abgerufen, und die Richtlinie selbst ist gemäß der WS-Policy-Spezifikation strukturiert. Der STS macht Endpunkte verfügbar, die die WS-Trust-Spezifikation implementieren, welche beschreibt, wie Sicherheitstoken angefordert und empfangen werden. Die meisten aktuellen Sicherheitstokendienste stellen SAML-formatierte (Security Assertion Markup Language) Token aus. SAML ist ein branchenweit anerkanntes XML-Vokabular zum Abbilden von Ansprüchen auf interoperable Weise. In einem Szenario mit mehreren Plattformen ermöglicht dies die Kommunikation mit einem Sicherheitstokendienst auf einer gänzlich anderen Plattform und das Erreichen einer einmaligen Anmeldung in allen Ihren Anwendungen unabhängig von der Plattform.

Browserbasierte Anwendungen

Nicht nur intelligente Clients können mit dem anspruchsbasierten Identitätsmodell arbeiten. Browserbasierte Anwendungen (die als passive Clients bezeichnet werden) können dies auch, was im folgenden Abschnitt beschrieben wird.

Zunächst verweist ein Benutzer einen Browser an eine Ansprüche unterstützende Anwendung (die Anwendung mit vertrauender Seite). Die Webanwendung leitet den Browser an den Sicherheitstokendienst um, damit der Benutzer authentifiziert werden kann. Der Sicherheitstokendienst wird in einer einfachen Webanwendung gehostet, welche die eingehende Anforderung liest, den Benutzer mittels HTTP-Standardmechanismen authentifiziert und anschließend ein SAML-Token erstellen. Danach antwortet die Webanwendung mit einem ECMAScript (JavaScript, JScript)-Codefragment, das bewirkt, dass der Browser einen HTTP POST-Befehl auslöst, der das SAML-Token zurück zur vertrauenden Seite sendet. Der Hauptteil dieses POST-Befehls enthält die Ansprüche, die die vertrauende Seite angefordert hat. An dieser Stelle fügt die vertrauende Seite die Ansprüche häufig einem Cookie hinzu, damit der Benutzer nicht bei jeder Anforderung umgeleitet werden muss.