Federation-Technologien im Detail

Microsoft hat sich bei der Umsetzung von Federation für den Standard WS-Federation entschieden. Dieser Standard ist neben den Spezifikationen der Liberty Alliance einer der beiden relevanten Ansätze für die Realisierung von Federation-Lösungen. Liberty wiederum setzt auf die erweiterte SAML 2.0-Spezifikation. Die ersten SAML-Spezifikationen sind die Basis für viele der frühen Federation-Lösungen, die verschiedene Hersteller angeboten haben oder noch anbieten.

Die Grundidee

WS-Federation ist ein Web Service-Standard, wie der erste Teil der Bezeichnung bereits deutlich macht. Er gehört zu einer ganzen Reihe weiterer Standards, mit denen sichere Web Services unterstützt werden sollen. Durch die wachsende Bedeutung der Identity Federation hat er aber eine etwas hervorgehobene Stellung.

Die Grundidee ist, dass mit einer Token-basierenden Authentifizierung und „föderierten“ Vertrauensstellungen zwischen verschiedenen Authentifizierungsbereichen (Realms) gearbeitet wird. Der Begriff der Föderation bezeichnet einen Zusammenschluss und ist etwas redundant. Letztlich geht es darum, dass man verschiedene Authentifizierungsbereiche, also beispielsweise das Unternehmen A und das Unternehmen B oder den Verzeichnisdienst A und diesen nutzende Anwendungen und den Verzeichnisdienst B mit entsprechenden Anwendungen hat, die sich gegenseitig vertrauen. Das Konzept findet sich in ähnlicher Form bei Forest Trusts innerhalb des Active Directory – nur dort eben in einer proprietären Implementierung, die nicht für die plattformübergreifende Nutzung von Web Services geeignet ist.

Die Herausforderungen für die Umsetzung der Federation erstrecken sich auf mehrere Bereiche:

• Die Definition eines Tokens, das zwischen verschiedenen Authentifizierungsbereichen ausgetauscht werden kann und dem beide/alle Seiten vertrauen.

• Die Sicherung des Austausches dieser Informationen.

• Die Festlegung darüber, wer wem vertraut, also die Konfiguration der Vertrauensstellungen.

• Die Umsetzung der Informationen aus dem Token auf spezifische Zugriffsinformationen bei den Zielsystemen.

Entsprechend setzt sich der Standard WS-Federation wieder aus verschiedenen anderen Standards zusammen. Zu erwähnen sind hier insbesondere:

• WS-Security: Bei diesem Standard geht es zunächst um die Sicherheit von SOAP-basierenden Nachrichten (SOAP: Simple Object Access Protocol). Damit wird erreicht, dass Informationen sicher und unverändert übertragen werden können. Darauf basierend gibt es allgemeine Mechanismen für die Zuordnung von Sicherheits-Tokens zu Nachrichten und die Beschreibung dafür, wie binäre Sicherheits-Tokens, insbesondere X.509-Zertifikate und Kerberos-Tickets, codiert und in sicherer Weise übertragen werden können. Bezogen auf WS-Federation bedeutet das, dass damit eben die sichere Übertragung der erforderlichen Tokens zwischen den Teilnehmern der Federation-Beziehung erreicht wird.

• WS-Trust: Übernimmt die Definition und Verwaltung der Vertrauensstellung zwischen zwei Authentifizierungsbereichen und Mechanismen für die Anforderung und Bereitstellung von Sicherheits-Tokens. Der Standard setzt auf WS-Security auf.

• WS-Policy: Dieser Standard wird nicht zu den Sicherheits-, sondern zu den Metadaten-Spezifikationen gezählt. Hier geht es also darum, Anforderungen an Dienste, Präferenzen und Fähigkeiten zu beschreiben. Letztlich wird damit definiert, was verschiedene Systeme in einer Kommunikationsbeziehung können. An die Richtlinien können beispielsweise WSDL- und UDDIInformationen angefügt werden. Sie werden aber im Zusammenhang mit WS-Federation auch für spezifische Beschreibungen verwendet.

Dazu kommen noch weitere Protokolle. So dient etwa die WS-SecurityPolicy als Beschreibung dafür, wie die Zuordnung von mit WS-Policy definierten Richtlinien unter anderem zu den Standards WS-Security und WS-Trust erfolgt.

Der Grundansatz der Sicherheit für Web Services

Das Ziel von Web Services ist die Interoperabilität zwischen verschiedenen Systemen in heterogenen Umgebungen. Wie häufig bei der Entwicklung von Standards spielte das Thema Sicherheit bei der Entwicklung zunächst eine untergeordnete Rolle. Entsprechend findet man schon längere Zeit verschiedene Web Service-Standards, während die dazu gehörenden Sicherheitsstandards noch relativ jung sind.

Die Herausforderung dabei ist, dass sehr unterschiedliche Sicherheitsmechanismen erforderlich sind, da Web Services in unterschiedlichen Szenarien genutzt werden können. Die Anforderungen innerhalb von Unternehmen unterscheiden sich deutlich von denen, die es im B2BUmfeld oder bei Web Service Angeboten von Dienstleistern gibt. Entsprechend umfassend sind auch die Sicherheitsstandards.

Die Notwendigkeit für spezielle Sicherheitsstandards für Web Services entsteht vor allem daraus, dass mit End-to-End-Security gearbeitet werden muss. Zwischen dem anfordernden System (Requestor) und dem Zielsystem, also dem Web Service, können sich noch andere Systeme befinden. Ein Ansatz wie SSL, der sich jeweils nur auf die Verbindung zwischen zwei Systemen bezieht, ist daher nicht ausreichend. Es ist eine Lösung erforderlich, die Informationen über den gesamten Weg sichert – was in der Regel über die
erschlüsselung der Informationen erfolgt.

Innerhalb des Web Service-Modells kann ein Web Service bei eingehenden Nachrichten bestimmte Claims erzwingen. Diese müssen vom Requestor geliefert werden. Letzterer benötigt dafür wiederum ein Security-Token, um die Echtheit der Claims zu bestätigen und teilweise auch deshalb, weil die angeforderten Claims Informationen beinhalten, die in den Security-Tokens enthalten sind. Diese Security-Tokens müssen bei einem STS (Security Token Service) angefordert werden (Bild 1).

Dieses Grundmodell der Sicherheit von Web Services arbeitet mit einem STS, der sowohl vom Requestor als auch vom Web Service akzeptiert wird. Hier wird bereits deutlich, dass sich die Erfordernis für Identity Federation stellt, sobald die beiden Systeme nicht mit dem gleichen STS arbeiten. In diesem Fall ist eine wie auch immer geartete Umsetzung der erstellten Security-Tokens erforderlich.

Entsprechend vielschichtig gestalten sich auch die Web Service-Standards im Bereich der Sicherheit (Bild 2). Im Vergleich zur Abbildung sind inzwischen einige der Standards auf höherer Ebene Realität geworden, insbesondere WS-Policy, WS-Trust und WS-Federation. An anderen wie WS-Privacy wird aber noch intensiv gearbeitet.

Der Zusammenhang der Standards

WS-Security als der grundlegende Standard hat das Ziel, eine quality of protection zu liefern, indem die übertragenen Nachrichten gesichert werden. WS-Security wird für viele Bereiche benötigt und spielt beispielsweise auch im Kontext der Liberty-Standards eine Rolle, weil es um die generelle Frage geht, wie man Web Services absichern kann. Daher stellt WS-Security einen allgemein verwendbaren Ansatz für die Zuordnung von Security-Tokens zu Nachrichten auf SOAP-Ebene bereit. Der Ansatz ist erweiterbar und kann beispielsweise zusätzliche Token-Formate unterstützen.

WS-Security ist in jedem Fall erforderlich, wenn in sicherer Weise mit Web Services gearbeitet werden soll. Und da bei der Federation Identitätsinformationen über Web Services übertragen werden, ist der Mechanismus dafür unverzichtbar.

Die beiden Standards WS-Policy und WS-Trust setzen darauf auf. Die Ebene, auf der sich diese Standards befinden, wird auch als Policy Layer bezeichnet, weil hier Richtlinien für die Nutzung der WS-Security von Standards und Anwendungen auf höherer Ebene wie eben WS-Federation definiert werden. WS-Trust definiert, einfach gesagt, wer wem unter welchen Bedingungen vertraut.

WS-Federation benötigt nun wiederum die Standards auf der darunter liegenden Ebene, also WS-Security als Basis und WS-Policy sowie WSTrust für die Vereinbarung des Zusammenspiels zwischen den beteiligten Komponenten. WS-Privacy wird zukünftig eine größere Rolle spielen, weil damit gesteuert wird, wer welche Identitätsinformationen sehen darf. Das ist in komplexeren Federation-Szenarien und insbesondere im B2C-Umfeld unverzichtbar. Allerdings ist hier noch einiges an Standardisierungs- und Implementierungsarbeit erforderlich.

Federation

Federation ist ein Ansatz, der im Ergebnis ein Single Sign-On für verschiedene Anwendungen ermöglicht, indem die Sicherheits-Tokens, die von einem Identity Provider (und damit auch einem STS) bereitgestellt wurden, beim Zugriff auf Ressourcen akzeptiert werden, auch wenn dort eigentlich mit einem anderen STS gearbeitet wird – indem eben eine Vertrauensstellung direkt oder indirekt aufgebaut wird.

Dieses Zusammenspiel kann auf unterschiedliche Weise erfolgen. Dafür werden so genannte Profile definiert, die festlegen, wie Federation-Standards und -Technologien genutzt werden können. Innerhalb des Standards WS-Federation gibt es derzeit das Active Requestor Profile und das Passive Requestor Profile. Diese Profile sind erweiterte, spezifische Beschreibungen des generellen Frameworks, das durch WS-Federation vorgegeben wird. Es ist grundsätzlich denkbar, noch weitere solche Profile zu beschreiben. Die beiden bisher existierenden Profile werden weiter unten in diesem Artikel noch näher betrachtet.

Ein zentrales Element bei der Federation sind die Identity Provider. Dabei handelt es sich um eine spezielle Variante der STS. Sie übernehmen neben dem Ausstellen von Security-Tokens, die sie gegebenenfalls auch von anderen Systemen beziehen können, zumindest auch die Authentifizierung und die Zuordnung von Claims innerhalb der Security-Tokens, also beispielsweise die Zuordnung von Rolleninformationen.

Ein weiterer Aspekt, auf den WS-Federation abhebt, ist das Sign-Out. Neben der Authentifizierung muss auch sichergestellt werden, dass Sicherheits-Tokens nach dem Ende einer Sitzung aus dem Cache gelöscht und nicht von Angreifern wieder verwendet werden können.

Wichtige Punkte sind auch die Attribute und Pseudonyme. Attribute sind zusätzliche Informationen, die über eine Identität benötigt werden. Solche Informationen können innerhalb einer Federation-Beziehung angefordert werden. Attribute werden von einem Attribute Service geliefert. In vielen Fällen ist der Attribute Service mit dem Identity Provider integriert. Das Active Directory in Verbindung mit den ADFS stellt sowohl die Dienste des Identity Providers als auch des Attribute Service bereit, indem auf Informationen aus dem Verzeichnis zugegriffen werden kann.

Wichtig ist, dass es für unterschiedliche Attribute unterschiedliche Sicherheits- und Privacy-Regeln geben kann. Darüber wird gesteuert, wer welche Informationen sehen darf. Die Fähigkeiten von Attribute Services werden in den Richtlinien-Dokumenten beschrieben.

Pseudonyme sind andere Bezeichnungen für Benutzer. Diese Dienste sind wichtig, wenn ein Benutzer MartinK beispielsweise bei einem anderen System als martin@kuppinger.de dargestellt werden muss oder wenn mehrere Individuen in einer Rolle zusammengefasst werden. In der Regel werden auch diese Dienste integriert angeboten. Grundsätzlich wäre es aber denkbar, dass alle Dienste, also Identity Provider mit STS, Attribute Service und Pseudonym Service getrennt voneinander operieren (Bild 3).

Interessant ist schließlich auch noch die Rolle der Metadaten in einer Federation-Beziehung. Als Metadaten werden die beschreibenden Informationen bezeichnet, die festlegen, wie die Federation-Beziehungen funktionieren. Dazu gehören die Richtlinien sowie gegebenenfalls auch WSDL-Beschreibungen (Web Service Description Language, Festlegungen zur Funktionalität von Web Services) sowie Schemas (Strukturbeschreibungen für XML-Dokumente). Außerdem werden Informationen benötigt, um beispielsweise Identity Provider, STS und andere Komponenten zu identifizieren, die innerhalb einer Richtlinie (Policy) angegeben werden. Die Standards dafür bilden WS-Policy und, auf der Ebene darunter, WS-MetadataExchange, als Standard für den Austausch solcher Metadaten zwischen den an einer Kommunikation beteiligten Systemen.

Die Ziele der Identity Federation

• Reduktion der Kosten für das Identity Management,
  indem Identitätsinformationen nicht mehr mehrfach
  verwaltet werden müssen, sondern von einer vertrauten
  Organisation/einem vertrauten System bezogen
  werden.

• Sicherstellen der Autonomie der beteiligten Organisationen,
  indem unterschiedliche Systeme in einem
  heterogenen Umfeld zusammenarbeiten können.

• Aufbau flexibler Trust-Strukturen, mit denen die Anforderungen
  der beteiligten Organisationen sichergestellt
  werden.

• Sicherung der Anforderungen an die Privatheit (Privacy)
  von Identitätsinformationen.

• Verwendung offener Standards, um sichere, verlässliche
  Transaktionen für das Business und Individuen
  zu unterstützen.

Spezifische Sicherheitsanforderungen

Wie eingangs ausgeführt, resultieren aus der Arbeitsweise von Web Services und damit auch der darauf basierenden Federation einige spezifische Sicherheitsanforderungen. Im Detail sind das die folgenden im Standard spezifizierten Festlegungen:

• Es wird unbedingt empfohlen, dass die Kommunikation zwischen Diensten über WS-Security gesichert wird. Sowohl der Body als auch die Header der Nachrichten sollten in die Signatur eingeschlossen werden.

• Alle Nachrichten im Zusammenhang mit de Federation wie das Sign-Out oder der Austausch von Attributen sollten signiert werden. Nicht signierte Nachrichten sollten nicht verarbeitet werden.

• Alle Sign-Out-Anforderungen müssen signiert sein.

• Alle Nachrichten sollten vom STS signiert werden. Nicht von diesem signierte Nachrichten sollten nicht verarbeitet werden.

• Der Attribute Service sollte besonders geschützt sein, da er besonders sensible Informationen verarbeitet.

• Gleiches gilt für den Pseudonym Service. Die Informationen insbesondere zu Kennwörtern sollten sowohl bei der Übertragung als auch im Speicher verschlüsselt sein.

• Falls ein Security-Token nicht ohnehin verschlüsselt ist, sollte es nur in Nachrichten übertragen werden, die die Sicherheit und Integrität gewährleisten.

Die Konsequenz aus diesen Anforderungen ist, dass ein Minimum an Zertifikatsdiensten für den Aufbau von Federation-Beziehungen zwingend erforderlich ist. Das wird deutlich, wenn man sich – wie im folgenden Artikel – die genaue Arbeitsweise der ADFS betrachtet. WS-Security muss genutzt werden, um die Federation-Beziehungen abzusichern. In der Konsequenz müssen für den Aufbau einer Federation-Beziehung neben WSFederation auch WS-Security, WS-Trust und WSPolicy konfiguriert werden.

Passive Requestor Profile

Das Passive Requestor Profile ist das Verfahren, das bei der Authentifizierung von Systemen angewendet wird, die nicht direkt Web Services unterstützen und damit auch nicht direkt über die auf SOAP basierenden Federation-Nachrichten arbeiten können. Es handelt sich um Systeme, die HTTP 1.1 verwenden, also insbesondere Webbrowser.

Das Konzept der Zugriffe ist in Bild 4 illustriert. Der Zugriff auf eine Ressource erfolgt über HTTP. Das System, das die Ressource bereitstellt, antwortet mit einer Authentifizierungsanforderung, die nun vom Identity Provider des Requestors bearbeitet werden muss. Das ausgestellte Security-Token mit ergänzenden Informationen wie den Claims wird an die Ressource übergeben, die nach erfolgreicher Authentifizierung die Ergebnisse der Anforderung zurückliefert.

Nicht sichtbar sind in Bild 4 die zusätzlich erforderlichen Schritte, die für den Aufbau des Trusts erforderlich sind. Es wird vorausgesetzt, dass die Vertrauensstellung zu diesem Zeitpunkt bereits besteht und die Ressource damit das Security-Token akzeptiert.

In praktisch identischer Weise werden auch Sign-Out-Anforderungen verarbeitet, bei denen allerdings die Ressource das Sign-Out beim Identity Provider anfordert.

In vielen Situationen sind im Rahmen der Federation zusätzliche Attribute erforderlich. Das Verfahren für die Anforderung solcher Attribute ist in Bild 5 illustriert. Hier geht die Anforderung an den Client, der wiederum (implizit) mit dem Identity Provider und dessen Attribute Service zusammenarbeitet. Die Verarbeitung von Pseudonymen erfolgt praktisch identisch.

Damit nicht bei jeder Anforderung erneut der Zugriff auf den Identity Provider erforderlich ist, kann mit Artefakten oder Cookies gearbeitet werden. Artefakte beschreiben einen Requestor innerhalb einer Kommunikationsbeziehung und sind innerhalb des Passive Requestor Profiles als Cookies implementiert.

Active Requestor Profile

Das zweite bereits definierte Profil ist das Active Requestor Profile. Dieses Profil wird für Anwendungen eingesetzt, die Web Services direkt unterstützen. Federation-fähige Anwendungen und Clients können diesen Mechanismus verwenden. Die Interaktion mit dem Identity Provider und dem Service Provider ist damit viel direkter (Bild 6).

Hier wird deutlich, dass die Verarbeitung von Richtlinien unmittelbar erfolgt. Der Requestor kann diese anfordern und direkt Security-Tokens anfordern. Beim Passive Requestor müssen diese Schritte alle implizit über den Identity Provider erfolgen, da der Browser selbst nichts von der Federation mitbekommt. In diesem Fall kann der Requestor auch direkt ein Security-Token beim Identity Provider des Dienstes anfordern, während im passiven Profil die Umsetzung des Tokens dort übernommen werden muss. Das Verfahren ist deutlich effizienter und entlastet die Serverkomponenten.

Microsoft hat sich dennoch zunächst für die Umsetzung des Passive Requestor Profile entschieden, weil die Anzahl der Systeme, die mit dem Active Requestor Profile arbeiten können, noch gering ist. Der Standardansatz für Federation ist derzeit, dass bestehende Web-Anwendungen erweitert werden und mit dem Browser zugegriffen wird. Die Verwendung von Federation auf Anwendungsebene wird sich erst nach und nach durchsetzen. Man darf aber darauf gespannt sein, ob beispielsweise auch zukünftige Versionen des Internet Explorer die Rolle eines Active Requestor übernehmen können.

Security Tokens

Innerhalb der Federation auf Basis von WS-Federation können verschiedene Arten von Security-Tokens eingesetzt werden. Derzeit sind das die folgenden Varianten:

• X509v3, also digitale Zertifikate. Für Kommunikationsbeziehungen, die über Unternehmensgrenzen hinausgehen, ist das der nahe liegende Ansatz. Da ohnehin Zertifikatsdienste erforderlich sind, um die Signaturen und Verschlüsselungen bei WS-Security umzusetzen, bietet sich das Verfahren generell an.

• Kerberos ist der Mechanismus, der vor allem innerhalb von Unternehmen zum Einsatz kommen wird. Besonders interessant ist Kerberos, wenn Federation für den Aufbau von Vertrauensstellungen zwischen Active Directory-Forests eingesetzt wird.

• XrML (eXtensible Rights Markup Language) ist ein Mechanismus, mit dem Rechte und Nutzungsbedingungen für digitale Inhalte spezifiziert werden können.

• SAML (Security Assertions Markup Language) ist schließlich ein anderer Basisstandard im Bereich der Federation. Allerdings wird SAML im Rahmen von WS-Federation nicht vollständig unterstützt. Immerhin können aber Tokens entsprechend verarbeitet werden.

Die Ausführungen rund um ADFS werden sich in erster Linie auf die ersten beiden Varianten von Security-Tokens fokussieren.

Die wichtigsten Begriffe für Federation

Nachfolgend werden die wichtigsten Begriffe rund um die Identity Federation und die Web Service-Sicherheit vorgestellt. Wir verwenden hier bewusst durchgängig die englischen Bezeichnungen, da es für die meisten Begriffe keine gebräuchliche und unmissverständliche Übersetzung gibt.

• Security Token: Ein Security-Token, oft auch nur als Token bezeichnet, ist eine Repräsentation von sicherheitsrelevanten Informationen, also beispielsweise von X.509-Zertifikaten oder Kerberos-Tickets. Es kann sich aber auch einfach um Benutzernamen oder andere einfache Informationen handeln.

• Signed Security Token: Ein signiertes Token. In der Regel werden die Tokens digital signiert, um ihre Unverfälschtheit sicherzustellen. Nur in einfachen Szenarien, in denen beispielsweise nur ein Benutzer- oder Dienstname übergeben wird, erfolgt keine Signatur. Für X.509-Zertifikate und Kerberos-Tickets als die gebräuchlichsten Informationen in Tokens ist die Signatur dagegen Standard.

• Claims: Ein Claim ist eine Aussage über ein Subject. Diese Aussagen können vielfältig sein. Ein besonders wichtiger Aspekt gerade im Zusammenhang mit der Federation ist die Zuordnung einer Rolle zu einem Subject.

• Subject: Bezeichnet eine Person, einen Dienst oder eine andere Einheit, die auf Web Services zugreifen kann.

• Policy: Richtlinie, die die Verarbeitung von Security Tokens beschreibt.

• Requestor: Anforderndes System bei Web Services.

• Security Token Service: Ein System, das Security Tokens ausstellen kann, also beispielsweise ein KDC. In der Regel arbeitet ein Security Token Service (STS) gleichzeitig auch als Identity Provider.

• Active Requestor: Eine Anwendung, die innerhalb der Federation arbeitet und die Web Service-Nachrichten über SOAP generieren kann.

• Passive Requestor: Ein System, das Federation-Dienste nutzen möchte, aber nur mit HTTP 1.1 arbeitet, also typischerweise ein Browser.

• Profile: Ein Dokument, das beschreibt, wie ein Modell der Federation auf eine Klasse von Requestor-Systemen angewandt wird.

• Attribute Service: Ein Dienst, der zusätzliche Attribute zu Identitäten verwaltet und bereitstellt.

• Pseudonym Service: Ein Dienst, der alternative Namen zu Attributen verwaltet und bereitstellt.

• Trust: Eine definierte Vertrauensstellung zwischen zwei oder mehr Bereichen (Realms), für die definiert ist, in welcher Weise Identitätsinformationen übergreifend genutzt werden können.

• Realm: Ein definierter Bereich, innerhalb dessen die Sicherheitsadministration einheitlich erfolgt und zu dem Vertrauensstellungen definiert werden können.

• Identity Provider: Ein System, das authentifiziert und Claims sowie Security Tokens bereitstellt.

• Service Provider: Eine Ressource, auf die zugegriffen wird.