MSDN Magazin > Home > Ausgaben > 2006 > November >  Single Sign-On: Eine Entwicklereinführung ...
Single Sign-On
Eine Entwicklereinführung in Active Directory-Verbunddienste
Keith Brown

Themen in diesem Artikel:
  • Bedeutung des Begriffs „Verbund“
  • Implementierung des Verbunds in ASP .NET-Anwendungen mit ADFS
  • Angebrachtes Vertrauen und Vorüberlegungen zur Sicherheit
In diesem Artikel werden folgende Technologien verwendet:
ADFS, ASP.NET
Eine der wichtigsten Komponenten von Windows Server® 2003 R2 sind die Active Directory-Verbunddienste (Active Directory Federation Services, ADFS). ADFS stellen die Lösung für einige Probleme dar; eins der offensichtlichsten davon ist die Automatisierung von Transaktionen zwischen Unternehmen. Im vorliegenden Artikel werde ich mich eingehender mit ADFS aus Sicht eines Entwicklers beschäftigen, der eine Webanwendung erstellt und dabei anderen Organisationen die Nutzung der Anwendung ermöglichen möchte (die Perspektive eines Administrators wird im Artikel von Matt Steele im TechNet-Magazin behandelt).
Auf welche Art von Problemen in der Unternehmensinteraktion wird hier Bezug genommen? Stellen Sie sich vor, ein Hersteller von Fahrrädern namens Fabrikam möchte eine Webanwendung bereitstellen, die es autorisierten Zwischenhändlern ermöglicht, Fahrräder und Ersatzteile zu Großhandelspreisen zu erwerben. Mehr als zweihundert Händler mit jeweils mehreren Mitarbeitern sind für die Anwendung zu berücksichtigen. Fabrikam benötigt eindeutig einen sicheren Anmeldemechanismus.
Eine offensichtliche Lösung wäre es, eine Datenbank zu erstellen, die alle einschlägigen Benutzernamen und Kennwörter enthält, aber diese wäre nur unter großem Aufwand zu verwalten. Wenn sich jemand telefonisch bei Fabrikam meldet und behauptet, Angestellter eines Zwischenhändlers zu sein, wie kann Fabrikam die Wahrheit dieser Behauptung überprüfen? Die wahrscheinlichste Lösung wäre es, eine Vertrauensperson beim betreffenden Händler zu kontaktieren, um dort den Status des vorgeblichen Angestellten zu überprüfen, bevor ein neues Kundenkonto angelegt wird. Führen Sie sich einmal vor Augen, was ein solches Benutzerkonto an Verwaltungskosten erfordern würde. Es kommt vor, das Benutzernamen oder Kennwörter vergessen werden oder sonstige Probleme auftreten. Und was gilt für den Fall, dass ein Mitarbeiter des Händlers entlassen wird? Wird sich jemand auf Händlerseite daran erinnern, Fabrikam mitzuteilen, dass das betreffende Benutzerkonto zu entfernen ist? Sollte dies nicht geschehen, kann der frühere Angestellte einfach von zu Hause im Namen des Händlers falsche Aufträge erteilen.
Kennwörter werfen auch ganz eigene Probleme auf. Mit der zunehmenden Rechenleistung von Computern sind Kennwörter zunehmend leichter aufzudecken, und viele Organisationen nutzen daher inzwischen sicherere Identifikationstechniken wie Smartcards. Da Fabrikam jedoch gezwungen ist, mit einer großen Zahl von Zwischenhändlern zusammenzuarbeiten, ist es fast nicht möglich, mit etwas anderem als Kennwörtern zu arbeiten.
Dabei sollte auch beachtet werden, dass Vertrauen hier eine wichtige Rolle zu spielen hat. Fabrikam muss den einzelnen Zwischenhändlern vertrauen, soweit es sich um bereitgestellte Listen der Mitarbeiter geht, die berechtigt sind, über die Webanwendung bei Fabrikam einzukaufen.

Eine Lösung mit ADFS
ADFS ermöglichen das Festsetzen von Vertrauensstellungen und verringern die Notwendigkeit, Kundenkonten bereitzustellen. Weshalb sollten Sie sich um die Einrichtung einer Kundenkontodatenbank für Ihre Anwendung kümmern müssen, wenn Ihre Händler bereits über Software verfügen, die ihre Benutzer eindeutig identifiziert?
ADFS stellen die Microsoft-Umsetzung des Passive Requestor Profile-Protokolls (Protokoll mit passivem Anfordererprofil) auf Webdienst-Verbundbasis dar (wobei „passiv“ hier andeutet, dass der Client nur einen Webbrowser erfordert, der Cookies und JavaScript unterstützt, es sich also um einen passiven Agent handelt, der keine besondere Codezeilen ausführt, um das Protokoll zu implementieren). Das Protokoll selbst funktioniert wie folgt: Rufen Benutzer von einem Händler aus über den Browser die Einkaufsanwendung von Fabrikam auf, wird dieser Browser letzen Endes wieder zu einer Website des Zwischenhändlers geleitet, dessen Mitarbeiter die Benutzer sind, was dazu führt, dass der Zwischenhändler die Benutzer authentifiziert. Dann wird der Browser wieder an Fabrikam verwiesen, wobei diese Weiterleitung auch eine gegengezeichnete Bestätigung des Zwischenhändlers umfasst, die besagt, dass die jeweiligen Benutzer tatsächlich Mitarbeiter des Zwischenhändlers sind und in seinem Namen auch die Anwendung nutzen dürfen. Das ist zugegebenermaßen eine vereinfachte Darstellung. Der entscheidende Aspekt ist hier jedoch, dass Fabrikam den Zwischenhändlern vertraut, was die Authentifizierung der jeweiligen Benutzer angeht, was für die Verbund-Technologie von zentraler Bedeutung ist.
Wenn ein Zwischenhändler über Software verfügt, die Webdienst-Verbund-PRP unterstützt, muss Fabrikam keine Benutzerkonten für die Mitarbeiter dieses Zwischenhändlers erstellen. Dementsprechend muss sich das Unternehmen auch keine Sorgen wegen Kennwort-Rücksetzungen machen. Wenn Benutzer beim Zwischenhändler die Position wechseln und daher nicht mehr im Einkauf tätig sind, so wird die Bestätigung des Zwischenhändlers für den Fall, dass diese Benutzer versuchen, auf Fabrikams Einkaufsanwendung zuzugreifen, klarstellen, dass diese Benutzer nicht mehr im Einkauf tätig sind, was den Zugriff auf die Anwendung blockiert. Voraussetzung hierfür ist jedoch, dass die Benutzerdaten auf Zwischenhändlerseite entsprechend angepasst werden. Sollten Benutzer den Zwischenhändler verlassen, können sie, sofern ihr Konto gelöscht wird, auch nicht mehr auf die Einkaufsanwendung von Fabrikam zugreifen. Durch die Verbundbeziehung zum Zwischenhändler erhält Fabrikam eine virtuelle Garantie dafür, dass jederzeit relevante und aktuelle Daten zur Benutzeridentität eingehen.
ADFS basieren auf Standards wie dem Webdienst-Verbund, der unter anderem von Microsoft, IBM, Verisign, BEA und RSA Security eingerichtet wurde. Die von Organisationen verwendete Software kann von Organisation zu Organisation stark variieren. Wenn Fabrikam Windows Server 2003 R2 mit ADFS verwendet, aber über Kunden verfügt, die IBM WebSphere oder BEA WebLogic verwenden, sollte dies keine Probleme aufwerfen, da WebSphere und WebLogic ebenfalls den Webdienst-Verbund implementieren.
Endbenutzer profitieren ebenfalls von der Verbundidentität. Statt sich mehr und mehr Kennwörter merken zu müssen, können Mitarbeiter im Einkauf einfach über ihren Browser auf die Anwendung von Fabrikam zugreifen und umgehend bestellen. Wenn das Authentifizierungssystem des Zwischenhändlers eine integrierte Anmeldung über einen Browser unterstützt, wie dies beispielsweise im Fall von Windows mit Internet Explorer® der Fall ist, müssen die Benutzer nicht einmal Anmeldeinformationen angeben; sie werden unbemerkt authentifiziert, und der Verbunddienst wird die örtlichen Gegebenheiten zu ihrer Identität in die gegengezeichnete Bestätigung für Fabrikam umwandeln, die ich bereits oben erwähnte. Das ist der geschlossene Kreis der Internetsicherheit: eine einzige Anmeldung für das gesamte Internet und über alle organisatorischen und technologischen Abgrenzungen hinweg.

ADFS-Architektur
Im Folgenden lernen Sie die verschiedenen Bestandteile von ADFS kennen, und einige Fachbegriffe werden erläutert. In jeder beliebigen Verbundbeziehung stellt eine Seite die Benutzer (Konten), und die andere die Anwendungen (Ressourcen). Wenn Sie ADFS installieren, konfigurieren Sie die zugehörigen Richtlinien zur Vertrauenswürdigkeit über das Snap-In zur ADFS-Verwaltung, das sich im Ordner „Verwaltung“ befindet, um so die Liste von Partnern festzulegen, mit denen Sie eine Verbundbeziehung aufbauen möchten. Benutzer auf Seiten des Kontopartners werden auf die für ADFS aktivierten Anwendungen des Ressourcenpartners zugreifen. Abbildung 1 zeigt die Struktur der ADFS-Vertrauensrichtlinien auf beiden Seiten einer Beziehung, wie sie über das Snap-In zur ADFS-Verwaltung einsehbar ist.
Abbildung 1 Richtlinie für zwei Partner(Klicken, um die Ansicht zu vergrößern) (Klicken Sie zum Vergrößern auf das Bild)
Auf beiden Seiten befindet sich jeweils der so genannte „Verbunddienst“. Jeder Verbunddienst macht eine Webanwendung zugänglich, wobei vorausgesetzt wird, dass der von den Benutzern verwendete Browser an diese Anwendungen weitergeleitet wird, um eine Anmeldung durchzuführen. Der Verbunddienst löst das „Impedance Mismatch“-Problem zwischen Konten- und Ressourcenpartnern, und zwar dergestalt, dass die Partner nicht einmal die gleiche Identitätstechnologie oder das gleiche Betriebssystem verwenden müssen. Auf Ihre Anwendung hat der Verbunddienst keine Auswirkung – das ADFS-Team stellt einen Web-Agent bereit, der über die ASP.NET-Pipeline als HttpModule ausgeführt wird, was Ihrer Seite die eigentliche Schwerstarbeit abnimmt. Sie müssen nur Ihre Anwendung für die Nutzung dieses Web-Agents konfigurieren und einige Konfigurationseinstellungen übermitteln, damit der Agent in der Lage ist, den Verbunddienst Ihres Unternehmens zu finden. Abbildung 2 zeigt die Grundstruktur von ADFS und die Wechselbeziehungen zwischen seinen verschiedenen Komponenten und den Browsern der Benutzer. Hier wird aufgezeigt, wie die Verhältnisse wären, wenn ADFS auf beiden Seiten der Verbindung eingesetzt würden. Es ist jedoch leicht vorstellbar, dass der Kontenpartner beispielsweise WebSphere mit einem IBM-Verzeichnisdienst im Hintergrund verwendet, mit einem Verbunddienst auf Java-Basis.
Abbildung 2 ADFS-Architektur 

Eine Einführung in die Verbundanmeldung
Wenn beispielsweise Alice, autorisierte Benutzerin eines Vertriebspartners von Fabrikam, mit Ihrem Browser zum ersten Mal Fabrikams Einkaufsanwendung aufruft, wird vom Web-Agent erfasst, dass bei ihr kein ADFS-Cookie vorliegt. Sie ist nicht angemeldet. Daher wird ihr Browser vom Web-Agent an den Verbunddienst von Fabrikam weitergeleitet, noch bevor ihre Anforderung bei der Einkaufsanwendung eingeht. Fabrikams Verbunddienst leitet den Browser nun an den Verbunddienst des Vertriebspartners weiter und fügt der Anforderung einen Bezeichner bei, der Fabrikams Verbunddienst genau identifiziert. Auf diese Weise erkennt der Verbunddienst des Vertriebspartners, welcher seiner Partner Anmeldeinformationen anfordert. Wenn Alices Browser nun den eigenen Verbunddienst erreicht, wird sie aufgefordert, sich zu authentifizieren. Da sie Mitarbeiterin eines Unternehmens ist, das die integrierte Authentifizierungsfunktion von Windows nutzt, erfolgt eine automatische Antwort von ihrem Browser und damit eine Anmeldung bei ihrem Verbunddienst. Wenn diese Anmeldung erfolgreich war, stellt ihr Verbunddienst ein Token in Security Assertion Markup Language (SAML) aus, das Alice eindeutig identifiziert, und leitet ihren Browser wieder an Fabrikams Verbunddienst weiter. Dabei wird das SAML-Token zusammen mit der ursprünglichen Anforderung im POST-Textkörper versendet (die ausgegebene Seite enthält JavaScript, das für die automatische Einreichung des Formulars mit versteckten Eingabeelementen sorgt). Auf Fabrikams Seite wird der Token-Inhalt erfasst. Dies führt zur Ausstellung eines weiteren SAML-Tokens, das den Anspruchssatz enthält, der letztendlich von der Verkaufsanwendung erfasst wird. (Weshalb zwei verschiedene SAML-Tokens verwendet werden, erkläre ich im Abschnitt über die Anspruchstransformation.) Dieses zweite Token wird mit der POST-Methode versendet und in einen Cookie von fabrikam.com geschrieben. Damit kann Alice nun die Einkaufsanwendung verwenden, bis ihr Cookie abläuft, was standardmäßig nach 10 Stunden der Fall ist.
Erinnern Sie sich noch daran, dass ein Web-Agent in der Einkaufsanwendung einen Anmelde-Cookie benötigte? Damit begann ja die gesamte Ereignissequenz. Jetzt liegt ein Cookie vor, und der Web-Agent analysiert ihn und erfasst die Ansprüche im SAML-Token, das von Fabrikams Verbunddienst ausgestellt wurde. Der Web-Agent gestattet nun die Ausführung der Webseite der Verkaufsanwendung. Wenn die Anwendung den Namen angemeldeter Benutzer ermitteln möchte, ist es nur erforderlich, den üblichen Speicherort zu überprüfen: HttpContext.User.Identity.Name.
Die Implementierung von IIdentity übermittelte üblicherweise, dass diese Daten dem Typ SingleSignOnIdentity angehörten. Gleichzeitig wurden so weitere nützliche Eigenschaften zugänglich gemacht, einschließlich der vom Kontenpartner verwendeten Authentifizierungsmethode, mit der Benutzer im eigenen Bereich authentifiziert werden. Aus dieser Klasse kann die Anwendung auch den vollständigen Anspruchssatz ermitteln, der vom eigenen Verbunddienst gesendet wurde.
Beachten Sie hierbei, dass die Partner-Verbunddienste nie direkt zueinander Kontakt aufnehmen. Die Kommunikation zwischen den Diensten erfolgt allein durch Browser-Weiterleitung und zugehörige Abfragezeichenfolgen und POST-Textkörper.

Absichern der Verbundanmeldung
Sehen Sie sich jetzt ein paar der Details genauer an, die veranschaulichen, wie die Anmeldung abgesichert wird. Ein Angriffspunkt wäre es zu versuchen, die SAML-Tokens aus der Übertragung herauszulesen und dann nach Bedarf wiederzugeben, um so sich so als legitimer Benutzer auszugeben. Um dies zu verhindern, erfolgt die gesamte Kommunikation über HTTPS. Dies ist von höchster Bedeutung. Wenn Sie versuchen, ADFS ohne bereits vorliegendes SSL-Zertifikat für die Standardwebsite in IIS zu installieren, gibt das ADFS-Installationsprogramm eine Warnmeldung aus und beendet die Installation.
Was hat es mit den Anmelde-Cookies auf sich, die Ansprüche enthalten? Wenn Benutzer ihre Berechtigungen für eine Anwendung verbessern möchten, könnten sie doch einfach weitere Ansprüche zum SAML-Token in ihren Cookies hinzufügen. Diese Art von Bearbeitung lässt sich jedoch erkennen, da jedes SAML-Token mit einem privaten Schlüssel signiert wird, der nur dem ausstellenden Verbunddienst bekannt ist. Das hat Auswirkungen für die Bereitstellung von ADFS. Wenn Sie die Rolle des Ressourcenpartners innehaben, müssen alle Kontenpartner Zertifikate für ihre jeweiligen Konto-Verbunddienste zur Verfügung stellen. Ihr Ressourcen-Verbunddienst verwendet das Zertifikat des Kontenpartners dazu, die Signaturen von SAML-Tokens zu überprüfen, die vom Verbunddienst ausgestellt werden. Der Web-Agent führt eine ähnliche Funktion aus, nämlich die Überprüfung aller SAML-Tokens, die beim Web-Agent über Anmelde-Cookies eingehen, darauf, ob sie vom Ressourcen-Verbunddienst signiert wurden.
Cookies, die über ADFS ausgestellt werden, sind immer mit einem Sicherheitsbit-Bit gekennzeichnet, das veranlasst, dass der Browser die entsprechenden Cookies nur über HTTPS, nicht über HTTP sendet. Wenn also ein Teil Ihrer Anwendung unter HTTP ausgeführt wird, wird es keinen Anmelde-Cookie geben, was bedeutet, dass Sie keinen Zugriff auf die Identitätsdaten der Benutzer haben. In diesem Fall würde der Benutzer für Sie anonym bleiben. Ich würde daher empfehlen, die gesamte Anwendung über SSL auszuführen, denn damit machen Sie es sich einfacher und verringern auch die Gefahr, dass vertrauliche Daten unberechtigten Dritten in die Hände fallen.
Die Auswirkungen von Fehlern beim siteübergreifenden Scripting (XSS) wären in einer Webanwendung mit ADFS verheerend, da sie jedes System befallen würden, in dem Cookies Anmeldesitzungen repräsentieren. Cookies können sehr leicht aus einer Anwendung gestohlen werden, die auf diese Art angreifbar ist, und ein gestohlener Cookie ist eine gestohlene Anmeldung. Als eine zusätzliche Sicherheitsmaßnahme laufen Anmelde-Cookies unter ADFS standardmäßig nach einem Arbeitstag ab. Sie können diese Ablaufzeiten allerdings in der Vertrauensrichtlinie von ADFS verändern. Wenn Sie sich nicht vollständig sicher sind, was XSS bedeutet und wie es sich verhindern lässt, nehmen Sie sich eine halbe Stunde Zeit, und gehen Sie die von mir verfasste XSS-Übungseinheit durch.

Benutzer, woher kommst du?
Fabrikam verfügt über viele Vertriebspartner, die die Rolle der Verbund-Kontenpartner ausfüllen. Wenn einer dieser Partner die Verkaufsanwendung verwendet, wie erkennt dann Fabrikams Verbundserver, an welchen Partner der Browser des jeweiligen Benutzers weiterzuleiten ist? Die Antwort: überhaupt nicht. Bei mehreren Partnern muss Fabrikams Verbundserver den Anmeldevorgang unterbrechen, um den jeweiligen Benutzern eine Liste der Partner anzuzeigen, aus der diese dann denjenigen auswählen, der sie authentifizieren kann. Dieser Schritt stellt die Identifikation des Ursprungsbereichs dar. Wenn Kunden bezüglich ihres Ursprungsbereichs lügen, beschert ihnen dies nur Unannehmlichkeiten, da sie nicht über die nötigen Anmeldeinformationen verfügen, um sich über andere Zwischenhändler zu authentifizieren.
Eines der Ziele einer guten ADFS-Anwendung ist es immer, solche lästigen Details vom Kunden fernzuhalten. Das Fahrradgeschäft Northwind kann diesen Schritt vermeiden, indem alle Benutzer des Geschäfts auf Fabrikams Website über eine Verknüpfung zugreifen, die über einen fast schon magischen Zeichenfolgenparameter in der Abfrage verfügen: „whr“. (Das könnte auch für "Which home realm?" stehen, d. h. „Welcher Ursprungsbereich?“) Wenn der Web-Agent diese Zeichenfolge in der Abfrage findet, löst er sie in der Aufbereitung aus der Abfrage heraus. Der Wert dieses Parameters ist der URI des Verbundservers des Partners (jeder Verbundserver ist mit einem URI gekennzeichnet). Das bedeutet für die Mitarbeiter bei Northwind, dass ihnen unter Umständen eine Verknüpfung wie die folgende angezeigt wird:
https://fabrikam.com/purchasing.aspx/?whr=urn:federation:
Northwindbikeshop
Das sind ausreichend Hinweise für ADFS, um zu vermeiden, dass eine interaktive Seite zur Identifikation des Ursprungsbereichs angezeigt wird.

Ansprüche und Transformation
Ich habe mich im vorliegenden Artikel schon mehrfach auf Ansprüche bezogen. Sie sind ein neues und zunehmend wichtiger werdendes Sicherheitskonzept für die Windows-Plattform und stellen eine allgemeine Möglichkeit dafür dar, Behauptungen zu Entitäten – beispielsweise Benutzer – abzugeben. Stellen Sie sich ein Kerberos-Ticket vor, das Bezeichner zum Benutzer und zu Domänengruppen des angemeldeten Benutzers enthält. Das ist letzten Endes nur ein Satz von Ansprüchen, die vom Domänencontroller signiert werden, der das Ticket ausstellte. Der Bezeichner für den Benutzer ist ein Identitätsanspruch. Diese Technik ist zwar nützlich für die Überprüfung oder Personalisierung, aber sie wird normalerweise nicht für die Zugriffskontrolle verwendet. Es ist viel wahrscheinlicher, dass die im Ticket aufgeführten Gruppen für Zugriffskontrollen verwendet werden. Wenn Sie beispielsweise der Gruppe „Manager“ angehören, ist es Ihnen vermutlich gestattet, umfangreiche Einkäufe zu tätigen.
ADFS unterstützen drei Arten von Ansprüchen: Identitätsansprüche, Gruppenansprüche und benutzerdefinierte Ansprüche. Ein Identitätsanspruch kann die Form eines Benutzerprinzipalnamens (User Principal Name, UPN), einer E-Mail-Adresse oder einer beliebigen Zeichenfolge, eines so genannten allgemeinen Namens, annehmen. Ein Gruppenanspruch ist boolesch (entweder Angehöriger oder kein Angehöriger) und muss nicht notwendigerweise eine Windows-Gruppe darstellen: Er kann genauso gut eine logische Rolle repräsentieren, die von der Anwendung verarbeitet werden kann. Ein benutzerdefinierter Anspruch enthält einen Zeichenfolgenwert. Alter, Geschlecht oder möglicherweise ManagerName könnten beispielsweise als benutzerdefinierte Ansprüche für ADFS konfiguriert werden. Diese verschiedenen benutzerdefinierten Ansprüche sollten Ihnen als Anlass dienen, sich über Datenschutzthemen Gedanken zu machen.
ADFS lösen über die Anspruchstransformation Probleme wie Datenschutz und andere praktische Probleme – z. B. verwendet nicht jedes Unternehmen die gleiche Terminologie, und nicht jeder Ressourcenpartner benötigt Informationen zu E-Mail-Adressen und Alter von Benutzern. Aus diesem Grund können Sie für jeden einzelnen Partner die ADFS-Vertrauensrichtlinie anpassen; so senden Sie nur die Ansprüche an den Partner, die dieser benötigt.
Jedes Unternehmen definiert einen Satz von Unternehmensansprüchen; man könnte sagen, das Unternehmen erklärt, welches Vokabular es versteht. Beispielsweise könnte Fabrikam einen Gruppenanspruch namens "Owner" definieren, um die Eigentümer von Fahrradgeschäften zu kennzeichnen. Andererseits könnte das Fahrradgeschäft Northwind die gleiche Rolle mit dem Anspruch "Manager" definieren. Das stellt kein Problem dar, solange die Bedeutung des Begriffs identisch ist, denn der Eigentümer von Northwind kann über seine ursprüngliche Verbund-Vertrauensrichtlinie den gesendeten Anspruch "Manager" dem Anspruch "Owner" zuordnen lassen, der von Fabrikam verstanden wird. Administratoren können solche Zuordnungen auf beiden Seiten einer Verbundbeziehung festlegen. Abbildung 3 zeigt ein Beispiel für eine Anspruchszuordnung in der Vertrauensrichtlinie eines Ressourcenpartners.
Abbildung 3 Anspruchszuordnung(Klicken, um die Ansicht zu vergrößern) (Klicken Sie zum Vergrößern auf das Bild)
Bestimmte Anspruchszuordnungen sind zu dynamisch, als dass ihnen statischen Zuordnungen in Vertrauensrichtlinien gerecht würden. Stellen Sie sich vor, ein Ressourcenpartner benötigt einen Anspruch des Typs „IsOfLegalVotingAge“ (Ist aktiv wahlberechtigt), um sicherstellen zu können, dass jemand über 18 Jahre alt ist, aber Sie bieten nur die Geburtsdaten der Benutzer als benutzerdefinierten Anspruch über Active Directory® an. In diesem Fall ist ein Modul für die Anspruchstransformation erforderlich, also eine Einrichtung, die eine verwaltete Klasse namens „IClaimTransform“ implementiert. Sie können dies an Ihre Vertrauensrichtlinie über das Eigenschaftenblatt der Vertrauensrichtlinie – siehe Abbildung 4 – übertragen. Dieses Modul wird zweimal aufgerufen: Zunächst, bevor normale Zuordnungen für die Vertrauensrichtlinien erfolgen, und anschließend nach diesem Vorgang; das ermöglicht Ihnen sowohl Vor- und Nachbereitung. Jede ADFS-Vertrauensrichtlinie ermöglicht das Installieren eines solchen Moduls, was bedeutet, dass Sie in der Lage sind, dynamische Anspruchstransformationen sowohl auf der Konten- als auch auf der Ressourcenseite eines Verbunds durchzuführen.
Abbildung 4 Modul für die Anspruchstransformation 

Wie entstehen Ansprüche?
Wenn Sie kein Modul zur Anspruchstransformation erstellen, das die Ansprüche dynamisch generiert, werden alle Ansprüche einem Kontospeicher entnommen, der entweder unter Active Directory oder Active Directory Application Mode (ADAM) läuft, wobei letzterer einen vereinfachten Verzeichnisserver auf Basis des Active Directory-Codes darstellt. Bei Kontenspeichern in Active Directory können Sie Gruppenansprüche einer oder mehrerer Gruppen in Active Directory zuweisen. Im Fall eines ADAM-Speichers müssen Sie den Namen eines Attributs des Benutzerobjekts angeben sowie einen Wert, der zu überprüfen ist – nur so können Sie festlegen, ob ein Gruppenanspruch an einen bestimmten Benutzer gesendet werden darf. Jeder benutzerdefinierte oder Identitätsanspruch wird direkt einem einzelnen Attribut des Benutzerobjekts im Verzeichnis zugeordnet.
Der Vorteil bei diesem Vorgehen ist, dass ein Administrator bereits im Unternehmensverzeichnis vorliegende Identitätsdaten für die Verbundarbeit mit Partnern nutzen kann, was in den meisten Fällen keine weitere Programmiertätigkeit erfordert.

Anonymität
Ein sehr interessanter Aspekt bei Systemen auf Anspruchsbasis ist die Tatsache, dass es oft überhaupt nicht erforderlich ist, Namen von Benutzern zu übertragen. Es ist denkbar, dass ein Partner nur daran interessiert ist, zu erfahren, ob die Benutzer jeweils berechtigt sind, die von ihnen eingereichten Anforderungen zu stellen. Allerdings ist es häufig praktischer für Partner, zumindest eine identifizierende Eigenschaft – Handle genannt – angeboten zu bekommen, da an dieser personalisierende Daten oder sonstige Informationen zu Benutzern festgemacht werden können.
Der anonyme Betriebsmodus wird durch eine spezielle integrierte Transformation für Identitätsansprüche unterstützt, die auch als erweiterter Identitätsschutz bezeichnet werden kann. Wenn Sie ein Kontenpartner sind und sicherstellen möchten, dass die bei Ihnen geführten Benutzer bei einem bestimmten Ressourcenpartner anonym bleiben, müssen Sie nur diese Funktion für den betreffenden Partner in Ihrer Vertrauensrichtlinie aktivieren. Statt
alice@northwindbikes.com
wird dem Partner etwas im Stil des Folgenden angezeigt:
tQZPfFuodGysa4t40oj+kM2vBIU=@northwindbikes.com
Zur Erstellung dieses Handle werden vom Verbunddienst der ursprüngliche Identitätsanspruch, der URI des Ressourcenpartners und ein Absicherungswert, der nur dem Verbunddienst bekannt ist, miteinander verschlüsselt – das Resultat wird in der ADFS-Terminologie als "Datenschutzschlüssel" bezeichnet. Das Einschließen des URI des Partners stellt sicher, dass die Handles für jeden Ressourcenpartner verschieden sind, was verhindert, dass aus ihrer Gesamtheit ein Datendossier über den Benutzer ermittelt werden kann. Der Datenschutzschlüssel wird integriert, um Wörterbuchangriffe zu erschweren.
Die Benutzeridentität ist zwar für den Ressourcenpartner nicht sichtbar, aber diese Funktion ist dennoch nachzuverfolgen. Für den Fall, dass eine Identität genau bestimmt werden muss, kann die verschlüsselte Identität in den Ressourcenprotokollen ermittelt werden und dem Administrator des Ressourcenpartners zugänglich gemacht werden. Dieser kann mit den Ereignisprotokollen zu diesem Konto feststellen, welchem Benutzer die fragliche Identität zugewiesen wurde.

Der Verbunddienstproxy
Wenn Sie den ADFS-Verbunddienst installieren, wird im IIS-Manager eine neue Webanwendung namens "adfs" angezeigt. Auf einer Ebene darunter befinden sich die Unterverzeichnisse "fs" und "ls", die für den Verbunddienst (federation service) und den Anmeldedienst (logon service) stehen. Der Anmeldedienst stellt im Prinzip nur das ADSF-Front-End auf Browserbasis dar; wenn Sie im zugehörigen Verzeichnis suchen, werden Sie einen Satz von ASPX-Seiten entdecken (übrigens können Sie diese Seiten anpassen, also lohnt es sich, sie genauer zu untersuchen). Hierher wird der Browser während einer Verbundanmeldung weitergeleitet. Ich habe den Begriff "logon service" (Anmeldedienst) nicht in der bisher veröffentlichten Dokumentation zu ADFS gefunden, aber es lässt sich einfach aus dem vorhandenen Code ableiten, dass er intern so bezeichnet wird. Im fs-Verzeichnis befindet sich eine Datei namens FederationServerService.asmx – der Webdienst, der das Back-End von ADFS darstellt; der technische Ausdruck lautet Security Token Service (STS).
Der Grund für diese Auftrennung ist, dass das Front-End (der Anmeldedienst) in einem Umkreisnetzwerk (häufig als DMZ = entmilitarisierte Zone bezeichnet) gehostet werden und mit dem Back-End des Verbunddienstes über einen ASMX-Webdienst kommunizieren kann, der sich im internen Netzwerk befindet. In dieser Konfiguration wird das Front-End als Verbunddienstproxy bezeichnet.
Ob Ihr Administrator den Verbunddienst mit einem Proxy oder einem separaten Computer aufteilt hat nur geringe Auswirkungen darauf, wie Sie Ihre Anwendung erstellen, aber es ist hilfreich, zu wissen, dass ADFS sich gut für Umkreisnetzwerke eignen.

ADFS-Aktivierung einer Webanwendung
Wenn Sie damit betraut wurden, eine Webanwendung zu erstellen, die ADFS-Anmeldungen unterstützt, müssen Sie einige Dinge beachten. Sie müssen in der Lage sein, die Datei „web.config“ einzurichten, um den ADFS-Web-Agent laden und konfigurieren zu können. Abbildung 5 zeigt die Datei „web.config“, die ich für die Musteranwendung dieses Artikels verwendet habe.
<configuration>

  <configSections>
    <sectionGroup name="system.web">
      <section name="websso" type=

        "System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, 
         System.Web.Security.SingleSignOn, Version=1.0.0.0, 
         Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null"/>
    </sectionGroup>
  </configSections>

  <system.web>

    <!-- we’re not using any of the standard ASP.NET auth techniques, 
         we’re using ADFS! -->
    <authentication mode="None" />
    <customErrors mode="Off"/>
    <sessionState mode="Off" />

    <!-- pull in ADFS assemblies -->
    <compilation debug=‘true’ defaultLanguage=‘c#’>
      <assemblies>
        <add assembly="System.Web.Security.SingleSignOn, Version=1.0.0.0, 
                       Culture=neutral, PublicKeyToken=31bf3856ad364e35, 
                       Custom=null"/>
        <add assembly="System.Web.Security.SingleSignOn.ClaimTransforms, 
                       Version=1.0.0.0, Culture=neutral, 
                       PublicKeyToken=31bf3856ad364e35, Custom=null"/>
      </assemblies>
    </compilation>

    <!-- pull in the module containing the ADFS web agent -->
    <httpModules>
      <add name="ADFS Web Agent" type=
          "System.Web.Security.SingleSignOn.WebSsoAuthenticationModule,
           System.Web.Security.SingleSignOn, Version=1.0.0.0, 
           Culture=neutral, PublicKeyToken=31bf3856ad364e35, 
           Custom=null" />
    </httpModules>

    <!-- the web agent looks here for its configuration -->
    <websso>
      <authenticationrequired />
      <eventloglevel>55</eventloglevel>
      <auditsuccess>2</auditsuccess>
      <urls>
        <returnurl>https://resource.local/web/</returnurl>
      </urls>
      <cookies writecookies="true">
        <path>/web</path>
        <lifetime>240</lifetime>
      </cookies>
      <fs>https://resource.local/adfs/fs/federationserverservice.asmx</fs>
    </websso>
  </system.web>

  <system.diagnostics>
    <switches>
      <!-- enables full debug logging -->
      <add name="WebSsoDebugLevel" value="255" /> 
    </switches>
    <trace autoflush="true" indentsize="3">
      <listeners>
        <!-- either create a c:\logs directory and grant Network Service 
             permission to write to it, or remove this listener -->
        <add name="MyListener" type=
            "System.Web.Security.SingleSignOn.
                 BoundedSizeLogFileTraceListener, 
             System.Web.Security.SingleSignOn, Version=1.0.0.0, 
             Culture=neutral, PublicKeyToken=31bf3856ad364e35, 
             Custom=null"
             initializeData="c:\logs\webagent.log" />
      </listeners>
    </trace>
  </system.diagnostics> 
</configuration>
Wenn die Datei „web.config“ eingerichtet ist, sollten Sie in der Lage sein, Anmeldungen von ADFS-Kontenpartnern anzunehmen. Der nächste Schritt ist das Treffen von Sicherheitsentscheidungen auf Basis der Ansprüche.
Um genau zu sein, gibt es zwei verschiedene ADFS-Web-Agents. Der eine ist der Web-Agent für tokenbasierte Anwendungen auf Windows NT®. Dieser Web-Agent erstellt eine reale Windows-Anmeldesitzung für Remotebenutzer. Er erstellt eine Anmeldung für den Benutzerprinzipalnamen über die S4U Kerberos-Erweiterungen, wie ich sie im April 2003 in meiner Kolumne „Security Briefs“ beschrieb (ein benutzerdefiniertes Authentifizierungspaket wird verwendet, wenn Windows Server 2003 nicht im systemeigenen Modus verwendet wird). Der Vorzug dieser Vorgehensweise ist, dass Sie diese Anmeldung darstellen können und Autorisierungsaufgaben an bestehende sichere Ressourcenverwaltungen abtreten können, beispielsweise das Dateisystem oder SQL Server™. (Wenn es sich dabei um Remoteressourcen handelt, müssen Sie auch den Protokollübergang in Active Directorry aktivieren.) Einer der größten Nachteile ist, dass Sie für jeden neuen Benutzer ein Benutzerkonto in Ihrer Domäne bereitstellen müssen, was einen Großteil der eigentlichen Vorzüge von ADFS aufhebt. (Allerdings müssen Benutzer ihr Kennwort für das Ressourcen-Konto nicht kennen, und es ist sehr wahrscheinlich, dass ihnen gar nicht bewusst ist, dass für sie noch ein weiteres Konto bereitgestellt wurde.)
Wenn Sie die Vorzüge des Verbunds nutzen möchten, müssen Sie Ihre Anwendung für das Erfassen von Ansprüchen einrichten, und es wird Ihnen nicht möglich sein, auf Identitätswechsel zurückzugreifen, da Sie über kein Windows-Domänenkonto verfügen werden, dass die Benutzer Ihrer Kontenpartner repräsentiert. Sie können den Web-Agent für anspruchsunterstützende Anwendungen verwenden, der keine Zuordnung mit Windows-Konten durchführt und Ihnen die eingehenden Ansprüche über HttpContext.User zugänglich macht. In meinem Beispiel bin ich so vorgegangen.
Es ist nicht besonders schwer, eine Anspruchsüberprüfung zu programmieren. Wenn Sie hauptsächlich mit Gruppenansprüchen arbeiten, müssen Sie sich eigentlich gar nicht viel mit Ansprüchen befassen. Überprüfen Sie einfach weiterhin mit HttpContext.User.IsInRole das Vorliegen von Gruppenansprüchen, wobei diese dann als Anwendungsrollen behandelt werden. Das bedeutet, dass Sie auch Steuerungsmethoden wie ASP.NET LoginView verwenden können, der z. B. seine Ausgaben auf Rollen stützt, die über die Eigenschaft HttpContext.User zugänglich gemacht wurden.
Wenn Sie den Wert der benutzerdefinierten Ansprüche einsehen möchten, müssen Sie ein bisschen neu programmieren. Dieses Beispiel sucht nach einen Anspruch namens „Title“:
string GetTitle() 
{
    SingleSignOnIdentity id = (SingleSignOnIdentity)User.Identity;
    SecurityPropertyCollection c =
        id.SecurityPropertyCollection.GetCustomProperties("Title");
    return (1 == c.Count) ? c[0].Value : string.Empty;
}
Ein interessanter Datenaspekt, der übermittelt wird, ist die Originalmethode, mit der die Kunden in ihrem jeweiligen Ursprungsbereich authentifiziert wurden. ADFS unterstützen vier Authentifizierungstechniken: Windows-integriert, SSL-Client-Zertifikat, Standardauthentifizierung und ASP.NET-Formularauthentifizierung. Sie können die verwendete Methode im Objekt SingleSignOnIdentity über die Eigenschaft AuthenticationMethod herausfinden. Verwechseln Sie das nicht mit der ursprünglichen in IIdentity verwendeten Eigenschaft AuthenticationType; Sie werden feststellen, dass diese immer WebSSO ausgibt, was im Prinzip besagt, dass die Anmeldung von ADFS durchgeführt wurde.
Eine weitere interessante Eigenschaft ist AuthenticatingAuthority, der URI des Kontenpartners, der den Kunden authentifizierte. Darüber hinaus ist es immer empfehlenswert, eine Abmeldeschaltfläche zur Verfügung zu stellen, d. h. die Eigenschaft SingOut Url könnte sich als nützlich erweisen.
Die Musteranwendung für diesen Artikel gibt alle öffentlichen Eigenschaften von SingleSignOnIdentity in einer Tabelle aus, wie in Abbildung 6 zu sehen ist. Darüber hinaus wird auch die Gesamtheit der Sicherheitseigenschaften ausgegeben, was im Prinzip alle Ansprüche zeigt, die in ihrer unveränderten Form gesendet wurden. Sie müssen jedoch zunächst ADFS einrichten, bevor Sie diese Anwendung ausführen können.
Abbildung 6 Beispielanwendung(Klicken, um die Ansicht zu vergrößern) (Klicken Sie zum Vergrößern auf das Bild)

Einstieg in ADFS in der Übungseinheit
Wenn Sie gerne etwas mit ADFS experimentieren möchten, müssen Sie sich zunächst die Zeit nehmen, eine passende Umgebung einzurichten. Als ich meine unternehmensübergreifende Einrichtung auf Anspruchsbasis erstellte, machte ich mir Notizen und fand so eine ziemlich schnelle Methode zum Erstellen eines Satzes von drei Virtual PC-Bildern, die einen Kontenpartner mit einem einzigen Clientcomputer sowie einen Ressourcenpartner repräsentieren. Ich habe die Notizen in meinem Wiki zugänglich gemacht. Einige der Notizen wirken vielleicht etwas knapp, aber wenn Sie bereits mit Virtual PC und Windows gearbeitet haben, werden sie Ihnen verständlich sein. Ich demonstriere dabei das Einrichten von Domänen mit SYSPREP, was Ihnen vielleicht neu ist. Sie können das Wiki ändern, indem Sie auf die Seite doppelklicken. Sie sind herzlich eingeladen, Kommentare für andere Leser einzufügen, aber versuchen Sie, sich kurz zu fassen, entsprechend meinen ursprünglichen Notizen.
Auf dem Wiki liegt auch eine Musteranwendung vor, einschließlich einer Config-Datei, mit der Sie Tests durchführen können. Kopieren Sie einfach die Dateien default.aspx und web.config in ein virtuelles Verzeichnis auf dem Bild des Ressourcenpartners; anschließend sollten Sie in der Lage sein, sich beim Kundencomputer anzumelden und mit dem Browser zur der Webanwendung der Partneranwendung zu surfen, um sich dann dort anzumelden.

Keith Brown ist einer der Gründer von Pluralsight, einem führenden Schulungsanbieter für Microsoft .NET. Keith ist der Autor des Pluralsight-Kurses „Applied .NET Security“ sowie mehrerer Bücher, einschließlich des „.NET Developer's Guide to Windows Security“, das gedruckt und im Internet erhältlich ist. Weitere Informationen finden Sie unter www.pluralsight.com/keith.

Page view tracker