Gründe für die Verwendung der anspruchsbasierten Identität
Letzte Änderung: Mittwoch, 16. Februar 2011
Gilt für: SharePoint Foundation 2010
Die anspruchsbasierte Identität ist ein Identitätsmodell für Microsoft SharePoint Foundation 2010 und Microsoft SharePoint Server 2010. Dieses Identitätsmodell umfasst Features wie die Authentifizierung bei Benutzern von Systemen, die auf Windows basieren oder nicht auf Windows basieren, mehrere Authentifizierungstypen, stärkere Authentifizierung in Echtzeit, eine größere Palette an Prinzipaltypen und die Delegierung von Benutzeridentitäten zwischen Anwendungen.
Unterschiedliche Authentifizierungssysteme
Die meisten Unternehmensanwendungen benötigen grundlegende Sicherheitsfeatures. Zumindest müssen Benutzer authentifiziert werden, und oft muss auch der Zugriff auf bestimmte Features autorisiert werden, damit nur Benutzer mit spezifischen Berechtigungen auf diese Features zugreifen können. Manchmal werden für diese Autorisierungsregeln Attribute benötigt, die in vorhandenen Benutzersicherheitstoken nicht enthalten sind; beispielsweise kann eine Verteilerliste aus Microsoft Exchange Server als Prinzipal zum Sichern einiger Objekte in SharePoint Server 2010 verwendet werden. Diese Sicherheitsfeatures sind in das Windows-Betriebssystem integriert und können normalerweise leicht in eine Anwendung integriert werden. Wenn Sie die integrierte Windows-Authentifizierung nutzen, müssen Sie kein eigenes Authentifizierungsprotokoll erstellen oder eine Benutzerdatenbank verwalten. Mithilfe von Zugriffssteuerungslisten (Access Control Lists, ACLs), Identitätswechsel und Features wie beispielsweise Gruppen können Sie Autorisierung implementieren, ohne viel Code zu schreiben.
Ähnlich wie unter Windows wird auch in SharePoint Foundation 2010 und SharePoint Server 2010 ein Satz von Features angeboten, mit dem Autorisierungsaufgaben erleichtert werden können. Für einige Objekte (beispielsweise für das Site-Objekt) geschieht dies automatisch im Hintergrund. Diese Richtlinie gilt unabhängig davon, welches Betriebssystem oder welche Anwendung Sie verwenden. Es ist fast immer besser, eng mit den integrierten Sicherheitsfeatures von SharePoint zu integrieren, als diese Features selbst neu zu erfinden.
Doch was geschieht, wenn Sie Benutzer erreichen möchten, die nicht über Windows-Konten verfügen? Was ist mit Benutzern, die Windows überhaupt nicht ausführen? In immer mehr Anwendungen wird diese Art des Zugriffs für diese Benutzertypen benötigt, was im Widerspruch zu den herkömmlichen Sicherheitsanforderungen zu stehen scheint. Anspruchsbasierte Identität soll als neues Identitätsmodell in SharePoint Foundation 2010 und SharePoint Server 2010 helfen, diese und andere Probleme zu bewältigen.
Unter Windows wird als Anmeldeinformationstyp für den Zugriff auf eine Unternehmensanwendung am häufigsten das Domänenkonto des Benutzers verwendet. Eine Anwendung, von der integrierte Windows-Authentifizierung verwendet wird, empfängt ein Kerberos-Ticket, das einen Client darstellt. Eine Anwendung, von der SSL (Secure Sockets Layer) verwendet wird, empfängt dagegen möglicherweise ein X.509-Zertifikat für den Client. Ein Kerberos-Ticket und ein X.509-Zertifikat sind sehr verschiedene Dinge, und die enthaltenen Daten, die vom Code des Betriebssystems analysiert, validiert und letztendlich präsentiert werden, sind ebenfalls sehr verschieden. Wenn Sie jedoch bedenken, was diese Elemente tatsächlich darstellen, wird ersichtlich, dass diese beiden Anmeldeinformationen viel gemeinsam haben.
Stellen Sie sich das folgende Szenario vor: Peter ist Benutzer und möchte mit seinem Windows-Domänenkonto auf einen Einkaufsdienst zugreifen. Peter wird vom Domänencontroller authentifiziert, und es wird ein Kerberos-Ticket erstellt, das einen Satz von Sicherheits-IDs (SIDs) enthält. Diese SIDs stellen Peters Benutzerkonto dar sowie die Domänengruppen, in denen er Mitglied ist. Die SIDs sind mit einer Signatur des Domänencontrollers in das Ticket eingebettet. Hinsichtlich der Identität erhält der Antragsteller (Peter) von einem "Aussteller" (dem Domänencontroller) ein Sicherheitstoken, mit dem er seine Identität nachweisen kann. Das gleiche Konzept gilt, wenn Peter stattdessen ein Zertifikat verwendet. Ein Zertifikat ist lediglich eine andere Art von Sicherheitstoken. In diesem Fall ist der Aussteller eine Zertifizierungsstelle (Certificate Authority, CA), und der Antragsteller ist Peter. Sowohl das Kerberos-Ticket als auch das Zertifikat sind im Grunde signierte Aussagen eines Ausstellers zu einem Antragsteller. Dies sind zwei verschiedene Methoden, mit denen eine vertrauenswürdige Autorität für einen Antragsteller bürgen kann. Jede signierte Anweisung kann als Sammlung von Forderungen betrachtet werden. Anders ausgedrückt: Der Domänencontroller erhebt beim Signieren der Liste der SIDs in Peters Ticket Ansprüche zu ihrer Identität. Jede SID wird zu einem Anspruch. Die Zertifizierungsstelle erhebt einen Anspruch zu Peters Identität, wenn das Zertifikat mit dem Namen und dem öffentlichen Schlüssel der Zertifizierungsstelle signiert wird. Der Name und der öffentliche Schlüssel sind Beispiele für Ansprüche im Zertifikat.
Ziel dieses neuen Identitätsmodells ist es, Identität so zu abstrahieren, dass die Abhängigkeit von bestimmten Anmeldeinformationstypen verringert wird, ohne die Sicherheit der Anwendung zu beeinträchtigen. Indem Sie Code für das Identitätsmodell in SharePoint Server 2010 schreiben, können Sie die Identität des Benutzers ohne Kerberos-Tickets delegieren und außerdem SAML-Token (Security Assertion Markup Language) verarbeiten. Dadurch erhalten Sie Zugang zu interessanten Identitätsarchitekturen wie beispielsweise der Verbundidentität.
Siehe auch
Konzepte
Erste Schritte mit dem sicherheits- und anspruchsbasierten Identitätsmodell