Das Web-SSO-Szenario

Für viele Szenarien ist eine ADFS-Lösung vollkommen ausreichend. Solange als Backend nur mit Anwendungen auf Basis des IIS gearbeitet wird, braucht man keine Web SSO-Lösung mit Unterstützung heterogener Umgebungen.

Das Szenario

Das Szenario für Web-SSO ist relativ einfach (Bild 1): Für den Verzeichnisdienst für die Authentifizierung von Benutzern kann das Active Directory oder ADAM eingesetzt werden. Über einen Client wird auf einen oder mehrere Webserver zugegriffen. Und es gibt einen Federation-Server, der sowohl für die Authentifizierung als auch die Autorisierung des Ressourcenzugriffs verwendet wird.

Im einfachsten Szenario stehen alle Systeme bis auf den Client innerhalb eines Netzwerks, also entweder im internen Netzwerk oder in der DMZ (Demilitarisierte Zone der Firewall-Infrastruk tur). Komplexer wird es, wenn die Authentifizierung über Active Directory-Systeme innerhalb des lokalen Netzwerks erfolgen soll, weil hier ein Forest Trust aufgebaut werden muss. Darauf wird in diesem Artikel nicht eingegangen. Das Thema wird gesondert behandelt.

Die ADFS übernehmen in dieser Struktur die Authentifizierung des Benutzers und die Erstellung von Cookies sowie die Authentifizierung für Ressourcenzugriffe.

Die Infrastruktur

Die Infrastruktur für den Test der ADFS besteht aus insgesamt sechs Systemen. Als Minimallösung kann auch mit vier Systemen gearbeitet werden, während für den Aufbau komplexerer Infrastrukturen auch weitere Systeme erforderlich werden können, insbesondere wenn auch Firewalls und Router emuliert werden sollen. Die für den Test dieser und weiterer Federation-Strukturen verwendeten Systeme sind:

• Ein Active Directory-Domänencontroller als Identity Service Provider (IP/ISP), der die Authentifizierung von Benutzern übernimmt, die über Federation-Mechanismen auf andere Systeme zugreifen.

• Ein Active Directory-Domänencontroller in der Ressourcendomäne.

• Ein Web-Server als Ressource, auf die zugegriffen wird.

• Ein Client für den Zugriff auf die Ressource.

• Ein ADFS-Server für die Ressourcendomäne.

• Ein ADFS-Server für die Domäne mit den Identitäten.

Wenn man das vollständige Federation-Szenario für B2B-Umgebungen vor Augen hat, dann befinden sich der Client, der ISP und der ADFSServer für die Identitäten-Domäne innerhalb eines Forests. Die anderen drei Systeme gehören zur Ressourcendomäne.

In diesem Beispiel übernimmt der Domänencontroller der Ressourcendomäne allerdings die Aufgabe des Identity Provider, so dass die Struktur sich etwas unterscheidet.

Die Systemvoraussetzungen sind der Windows Server 2003 R2 für alle ADFS-Server sowie die Webserver. Für die Domänencontroller ist auch die Verwendung des R2 wegen der erforderlichen Schema-Erweiterungen empfehlenswert, aber nicht zwingend. In der Testumgebung wird mit dem Windows Server 2003 mit Service Pack 1 gearbeitet. Der Client muss Windows XP mit Service Pack 2 verwenden.

Zertifikate

In der Testinfrastruktur kommen selbst-signierte Zertifikate zum Einsatz. Dadurch ist es nicht erforderlich, die Zertifikatsdienste zu konfigurieren. Auf deren Einsatz im Zusammenspiel mit den ADFS werden wir in einer späteren Ausgabe von Expert’s inside Windows NT/2000 eingehen.

Die vorbereitenden Schritte

Neben der Konfiguration der Rechner, die sich für den Test in einem Subnetz befinden können, muss das Resource Kit für die IIS 6.0 heruntergeladen und auf allen Server mit den ADFS sowie auf dem Webserver installiert werden. Das Resource Kit enthält die Anwendung SelfSSL.exe, mit der selbstsignierte Zertifikate für den Test der ADFS erstellt werden können.

Außerdem müssen Benutzer und Gruppen eingerichtet werden. Da im beschriebenen Beispiel nur ein Forest und eine Domäne verwendet wird, die sowohl die Überprüfung der Identitäten als auch die Zugriffe auf die Ressourcen übernimmt, müssen alle Benutzer und Ressourcen in dieser Domäne erstellt werden. Minimal sind folgende Benutzer, Gruppen und Strukturen erforderlich:

• Zwei Benutzer, die für den Test einerseits von Claims- und andererseits Token-basierenden Anwendungen eingesetzt werden.

• Zwei globale Sicherheitsgruppen in der Identity Provider-Domäne (Account-Domäne), ebenfalls für die beiden Szenarien.

• Eine Organisationseinheit für die Benutzung der Federation-Funktionen in der Ressourcen-Domäne.

• Eine globale Sicherheitsgruppe in dieser Organisationseinheit. In dieser Gruppe werden allerdings noch keine Benutzer angelegt, sondern nur die Gruppe, die für die Steuerung von Berechtigungen erforderlich ist.

Die Verwendung einer eigenen OU ist natürlich keineswegs zwingend, schafft aber Klarheit in der Struktur. Der Webserver muss außerdem zu der Ressourcendomäne zugeordnet werden. In späteren Federation-Szenarien muss außerdem der Client der Domäne des Identity Provider zugewiesen werden.

Die Zertifikate

Der nächste Schritt ist die Erstellung der selbstsignierten Zertifikate und ihre Zuordnung zu den jeweiligen Standardwebsites. Dazu müssen die IIS zunächst auf dem Webserver und dem ADFSServer eingerichtet werden. Das geschieht wie immer über den Bereich Software in der Systemsteuerung und dort über Windows-Komponenten hinzufügen/entfernen. Die IIS werden im Bereich Anwendungsserver aktiviert. Microsoft empfiehlt, die Auswahl Anwendungsserver komplett zu wählen.

Für die Erstellung der Zertifikate muss in das Unterverzeichnis SelfSSL des Installationsverzeichnisses des IIS Resource Kit gewechselt werden. Dort kann das Programm selfssl.exe mit der Syntax

selfssl /t /n:cn=<fullyqualifieddomainname> /v:365

ausgeführt werden. Als Name ist der vollständige Hostname anzugeben (Bild 3). Der Parameter /v gibt die Gültigkeit des Zertifikats in Tagen an. Bei der Abfrage muss angegeben werden, dass das Zertifikat gleich der Standardwebsite der IISInstallation zugewiesen wird.

Zusätzlich ist es erforderlich, das Zertifikat des ADFS-Service Provider (Ressourcen-Server) zu exportieren und beim Webserver zu importieren, damit eine Vertrauensstellung auf der Ebene der Zertifikate besteht. Dazu starten Sie den Internetinformationsdienste-Manager, um die Eigenschaften der Standardwebsite zu öffnen. Das erstellte Zertifikat lässt sich hier bei Verzeichnissicherheit mit Zertifikat anzeigen öffnen. Im Register Details findet sich die Schaltfläche In Datei kopieren, mit der Sie den Kopiervorgang starten (Bild 4). Ein Assistent leitet durch diesen Prozess. Der private Schlüssel darf nicht exportiert werden. Als Dateityp muss DER-codiert-binär X.509(.CER) ausgewählt werden. Anschließend muss noch ein Dateiname angegeben werden, bevor der eigentliche Export erfolgen kann.

Im nächsten Schritt erfolgt der Import über die Anwendung Zertifikate. Dazu muss zunächst über das Startmenü mit mmc.exe eine neue MMC-Konsole gestartet werden, in welche das Snap-In Zertifikate aufgenommen wird, wobei die Zertifikate für das Computerkonto (!) auf dem lokalen Computer verwaltet werden.

In der Anwendung wählt man nun den Bereich Vertrauenswürdige Stammzertifizierungsstellen/Zertifikate. Anschließend lässt sich im Kontextmenü über Alle Aufgaben/Importieren der Importvorgang starten. Er wird durch einen Assistenten unterstützt (Bild 5). Das Zertifikat soll in den Ordner Vertrauenswürdige Stammzertifizierungsstellen gelegt werden, Damit ist der Import abgeschlossen und der ADFS-Server wird als vertrauenswürdig akzeptiert.

Der ADFS-Web-Agent

Nun geht es mit der Einrichtung der ADFS-Komponenten überhaupt erst los. Der erste Schritt ist die Einrichtung der ADFS-Web-Agents auf dem oder den Webservern, die verwendet werden. Dieser Installationsschritt erfolgt über den Bereich Software in der Systemsteuerung. Bei Windows-Komponenten hinzufügen/entfernen kann die Option Active Directory-Dienste und dort wiederum ADFS (Active Directory-Verbunddienste) gewählt werden. Bei den Optionen finden sich die ADFSWeb-Agents als die zu installierende Komponente. Dort können erneut Details eingestellt werden. Hier müssen beide Varianten von Anwendungen (Bild 6) ausgewählt werden. Nach der Auswahl von Weiter beginnt der eigentliche Installationsprozess. In diesem Rahmen wird auch das Microsoft .NET Framework 2.0 installiert, soweit das noch nicht geschehen ist. Da dieses sehr groß ist, dauert der Vorgang einige Minuten.

Federation Services

Weiter geht es mit der Einrichtung des Federation Service auf dem Service Provider. Hier muss die Option Verbunddienst beim Hinzufügen des ADFS ausgewählt werden. Es wird eine Warnung angezeigt, weil das Microsoft .NET Framework 2.0 installiert werden muss. Nach der Auswahl des Dienstes wird zu Beginn der Installation ein Dialogfeld angezeigt, in dem man festlegt, mit welcher Form eines Tokensignaturzertifikats gearbeitet und ob eine neue Vertrauensrichtlinie erstellt werden soll. In beiden Fällen müssen die Standardoptionen gewählt bleiben (Bild 7).

Da nicht mit Zertifikatsdiensten gearbeitet wird, muss ein selbstsignierendes Tokenzertifikat verwendet werden. Die Vertrauensrichtlinie kann nur übernommen werden, wenn nicht der erste Federation Server eingerichtet wird. Nach dem Kopieren der Dateien ist auch dieser Server vorbereitet.

Nun muss noch eine Zuordnung des lokalen Systemkontos auf den Federation-Servern zur Identität ADFSAppPool erfolgen, falls die Systeme auch als Domänencontroller konfiguriert sind. Da im Beispiel getrennte Systeme zum Einsatz kommen, ist das aber nicht erforderlich.

Konfiguration des Federation-Servers

Der nächste Schritt ist die Konfiguration des Federation-Servers. Dazu wird die Anwendung Active Directory-Verbunddienste im Menü Verwaltung auf dem Federation-Server verwendet. Hier ein erster Überblick, den wir im zweiten Teil der Serie vertiefen. Zu der Konfiguration gehören mehrere Schritte:

• Die Konfiguration einer Richtlinie für die Vertrauensstellung. Damit werden letztlich die Einstellungen für WS-Trust gesetzt.

• Die Festlegung der Claims, die für das Zusammenspiel von Systemen verwendet werden. In der deutschen Verwaltungsanwendung werden sie als Ansprüche bezeichnet, was in der Übersetzung zwar korrekt, für die Nutzung aber wenig hilfreich ist.

• Die Festlegung der Identitätsspeicher, gegen die die Authentifizierung erfolgt.

• Die Konfiguration der Anwendungen.

• Die Festlegung der eigentlichen Beziehung zwischen den beiden Parteien.

Alle diese Festlegungen lassen sich über die Anwendung Active Directory-Verbunddienste vornehmen.

Der erste Schritt ist die Konfiguration der Vertrauensrichtlinie oder Trust Policy. Die Vertrauensrichtlinie wird unterhalb von Verbunddienst angezeigt. Bei den Eigenschaften können die Festlegungen gesetzt werden. Der erste Schritt ist die Konfiguration der Verbunddienst-URI und des URLs für die Federation. Die URI sollte den Namen der Domäne enthalten, in der sich die Ressourcen befinden. Der URL sollte den vollständigen Servernamen enthalten (Bild 8).

Im Register Anzeigenamen sollte der Anzeigename auf den Namen der Domäne geändert werden. Weitere Einstellungen betreffen unter anderem die Zertifikate. In diesem Schritt sind noch keine Anpassungen erforderlich.

Der nächste Schritt ist die Konfiguration der Claims oder Ansprüche. Dazu wird im Bereich Organisationsansprüche ein neuer Claim erstellt. Geben Sie diesem einen eindeutigen, leicht nachvollziehbaren Namen. Der Anspruch wird in der Regel als Gruppenanspruch definiert, der die Zuordnung einer Gruppe steuert. Diese Zuordnung kann zu einer Gruppe erfolgen, die aus dem Active Directory ausgewählt wird.

Ein weiterer wichtiger Schritt ist die Festlegung des Kontospeichers. Das ist der Verzeichnisdienst, der für die Authentifizierung verwendet wird. Hier haben Sie die Wahl zwischen dem Active Directory und ADAM (Bild 9).

Ein weiterer Schritt ist die Festlegung der Anwendungen, die bei der Federation verwendet werden. Hier müssen alle Anwendungen angegeben werden, auf die zugegriffen wird und für die Zugriffe verwaltet werden. Für die Anwendung wird ein Name und ein URL festgelegt. Der URL muss bekannt sein, weshalb in der Regel vorher die Anwendungen auf den Webservern eingerichtet werden.

An dieser Stelle wird das Konzept noch einmal deutlich, weil die beiden unterstützten Arten von Anwendungen Webanwendungen sind, die über den Browser genutzt werden können. Da die ADFS derzeit nur das passive Requestor-Profile unterstützen, ist diese Einschränkung auch logisch.

An diesen verschiedenen Komponenten wird außerdem deutlich, dass das Konzept der Federation nicht trivial ist – man muss vorher genau planen, welche Systeme und Anwendungen in welcher Form zusammenarbeiten sollen.

Wie geht es weiter?

Im zweiten Teil der Serie wird die Konfiguration der Federation Services fortgesetzt. Dabei geht es darum, einerseits den Federation-Server und andererseits die Webanwendungen zu konfigurieren. Außerdem wird auf die Nutzung der Federation-Funktionalität eingegangen.