Tags: Active Directory, Identity-Management, Authentifizierung
Die Active Directory Federation Services (ADFS) 2.0 sind ein Meilenstein in Microsofts Plänen für ein Identitäts-Metasystem. Es handelt sich dabei um eine Infrastruktur, die eine Zusammenarbeit verschiedener Identitätssysteme über Unternehmensgrenzen hinaus erlaubt. ADFS 2.0 sind eine Erweiterung des Active Directory unter Windows Server 2008 (R2).
Die bisher praktizierten Verfahren zur Authentifzierung und Autorisierung in der Microsoft-Welt sind geprägt von den Anforderungen einer Firmen-IT, die sich nur hinter der Firewall abspielt. Angesichts der Notwendigkeit, dass Unternehmen immer untereinander kooperieren oder externe Projektmitarbeitern einbinden müssen, erweist sich ein Identitäts-Management als Bremse, wenn es erfordert, dass alle potenziellen Nutzer einer Ressource in einer internen Datenbank verwaltet und über sie authentifiziert werden.
Noch mehr trifft das zu, wenn Unternehmen beginnen, Cloud-Services zu nutzen. Es wäre ein Unding, die Benutzerverwaltung in jedem neuen Online-Dienst zu duplizieren. Um diese Beschränkungen aufzuheben, bedarf es einer Technik, die über Punkt-zu-Punkt-Vertrauensbeziehungen hinausgeht und sich über das Internet nutzen lässt.
Authentifizierung gegenüber externen Systemen wird anerkannt
Die im Rahmen des Geneva-Projekts entwickelten ADFS 2.0 realisieren ein Konzept föderierter Identitäten, indem sie Benutzer, die sich gegenüber vertrauenswürdigen externen Systemen (Identity Providern) ausgewiesen haben, als authentifiziert anerkennen.
Allerdings reicht eine solche Delegierung der Benutzeranmeldung alleine nicht aus, um User im Zusammenspiel heterogener Systeme für den Zugriff auf IT-Ressourcen zu autorisieren. Die unter Windows eingesetzte Kombination aus Security IDs (SIDs) und Access Control Lists (ACLs) wäre dafür nicht praktikabel.
Dieses etablierte Verfahren beruht darauf, dass der Anmeldedienst (Issuer) ein Kerberos-Ticket ausstellt, das die Identität des Benutzers und alle seine Gruppenzugehörigkeiten in Form von SIDs enthält. Die Zugriffsrechte werden ermittelt, indem diese SIDs mit jenen in der ACL verglichen werden.
Bei der Kooperation von heterogenen Systemen kann zum einen nicht davon ausgegangen werden, dass Angaben über die Attribute eines Benutzers immer in dieser Form übertragen werden. Zum anderen wäre es sehr umständlich, allen benötigten externen SIDs in die ACLs aufzunehmen.
Benutzerattribute jenseits von SIDs
Notwendig ist hier ein Mechanismus, der Angaben über den Benutzer in einer allgemein verständlichen Form macht. Die Rede ist dabei von Claims-basierten Identitäten. Bei Claims handelt es sich um Aussagen über bestimmte Attribute eines Nutzers, etwa seinen Namen, sein Gruppenzugehörigkeit, sein Alter oder seine Firma.
Zwar macht auch das von einem Domain-Controller ausgestellte Kerberos-Ticket auch Behauptungen über Eigenschaften des Users, aber primär über nummerische Werte, die Gruppenzugehörigkeiten ausdrücken.
Dagegen unterstützen die ADFS 2.0 die Security Assertion Markup Language (SAML) 2.0, in der beliebige und semantisch uneingeschränkte Angaben über einen Benutzer gemacht werden können. Da seine Merkmale nicht nur zur Autorisierung für bestimmte Ressourcen benötigt wird, sondern auch zur Personalisierung von Anwendungen oder Arbeitsumgebungen, könnte etwa auf diesem Weg die Lieblingsfarbe der betreffenden Person mitgeteilt werden.
Die Verwendung von Standards wie WS-Trust, WS-Federation oder SAML sind alleine keine Gewähr dafür, dass verschiedene Implementierungen miteinander kompatibel sind. Gerade Microsoft hat sich in der Vergangenheit mit eigenwilligen Umsetzungen von normierten Techniken unrühmlich hervorgetan. Ein Beispiel dafür ist die ursprüngliche Implementierung von Kerberos in Windows 2000.
Bei SAML hingegen stehen die Chancen für eine reibungslose Interoperabilität besser, nachdem die Liberty Alliance die SAML-Umsetzungen mehrerer Hersteller, darunter IBM, Microsoft, SAP oder Novell oder auf ihre Standardkonformität geprüft hat.
Übersetzung zwischen SAML, X.509 und Kerberos
Aufgrund der Offenheit von Claims-basierten Identitäten lässt sich absehen, dass die Bezeichnung oder die Werte, die ein Aussteller verwendet, in vielen Fällen von der Gegenstelle ("Relying Party") nicht verstanden werden. Die ADFS 2.0 sind daher nicht nur ein Security Ticket Service (=Issuer), der Claimsets ausstellt, sondern zugleich auch ein Identity Transformer.
Seine Aufgabe besteht einerseits darin, die eingehenden Claims zu überprüfen, ob sie tatsächlich aus der als vertrauenswürdig eingestuften Quelle stammen, und sie dann in das Format zu übersetzen, mit dem die Anwendung etwas anfangen kann.
Eine solche Umformung kann etwa aus SAML ein Kerberos-Ticket machen, weil die meisten Applikationen in der Microsoft-Welt dieses verstehen, SAML hingegen nicht. Bei Bedarf könnten die ADFS 2.0 alternativ auch ein X.509-Zertifikat ausliefern.
Die zwischen den externen Aussteller eines Sicherheits-Tickets und die konsumierende Anwendung (Relying Party) geschalteten ADFS 2.0 treten gegenüber Letzterer zudem als Aussteller des modifizierten Tickets auf. Daher erfordert die Applikation keinerlei Anpassungen, weder in Bezug auf das Format des Tickets noch hinsichtlich der Aussteller, denen sie vertraut.
Identity Transformer gegen die Sprachenverwirrung
Neben der technischen Konvertrierung obliegt es zudem dem Transformer, die eingehenden Claims in ihrer Bedeutung zu übersetzen. Wenn etwa das Partnerunternehmen für privilegierte Benutzer eine Gruppe namens "Manager" verwendet, in der Firma mit der Ressourcen-Domäne hingegen für diesen Zweck die Gruppe "Supervisors" gebräuchlich ist, dann muss der Administrator eine Regel erstellen, die den Claim automatisch übersetzt.
Die Vorteile einer solchen föderierten Claims-basierten Identität sind vielfältig. Sie erlaubt etwa feiner abgestufte Zugriffsregeln, weil die Anwendung nur die Claims vom Issuer anfordern muss, die sie exakt braucht.
Dabei kann sie auf heute automatisch übertragene Angaben verzichten, wenn sie dafür keine Verwendung hat und so die Privatsphäre des Nutzers besser achten. Wenn sie nur dessen Lieblingsfarbe benötigt, um den Hintergrund einzufärben, kann sie auf seinen Namen oder seine Gruppenzugehörigkeiten verzichten.
Single Sign on (SSO) für die Cloud
Neben der einfacheren Kooperation mit Partnerfirmen sind die ADFS 2.0 vor allem eine Schlüsseltechnologie für Microsofts Cloud-Konzept Software plus Service. Sie erlauben ein Single Sign on zwischen firmeninternen Systemen und Diensten, die etwa über Azure oder Amazon bezogen werden.
Schließlich helfen die ADFS 2.0 bei der Integration von firmeninternen Identitätssystemen. In vielen Unternehmen gibt es neben dem AD noch mehrere Directories, etwa weil bestimmte Applikationen ihre eigenen mitbringen und nur mit diesen funktionieren. Die ADFS können Informationen aus diesen Systemen abrufen und in einem Security Token zusammenführen.
Insgesamt kann man die Bedeutung des neuen Identitäts-Metasystems kaum überschätzen. Es erweitert das Identitäts-Management nicht nur über die Firewall hinaus, sondern wird auch die Zugriffskontrolle innerhalb der Microsoft-Welt in den nächsten Jahren bestimmen.
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
- Im Test: AD-Passwörter im Self Service zurücksetzen mit Specops uReset
- Read-only Domain Controller (RODC): Features und Voraussetzungen
- Microsoft fasst alle Authentifizierungsmethoden des Azure AD in einer Policy zusammen
- ManageEngine ADSelfService Plus: Passwort-Reset als Self-Service, MFA für Active Directory
- Azure AD: Bevorzugte Methode für Multi-Faktor-Authentifizierung festlegen
Weitere Links