Die Active Directory Federation Services (Active-Directory-Verbunddienste) gibt es bereits seit Windows Server 2003 R2, also mittlerweile seit über acht Jahren. Erst in der letzten Zeit gewinnen diese Dienste an Bedeutung, weil sie für die Integration mit Cloud-Angeboten interessant sein können. Parallel betont Microsoft die Relevanz der ADFS, indem es in seinen Zertifizierungsprüfungen eine ganze Reihe von Fragen dazu stellt. Leider ist die Dokumentation dazu nicht besonders gut. Und auch weiterhin sind die ADFS eher eine exotische Funktion, nicht zuletzt, weil man sie nur sehr eingeschränkt testen und ausprobieren kann. Daher geben wir hier einen kurzen generellen Überblick über die Active Directory Federation Services. In einem weiteren Artikel stellen wir dann einige Hinweise zur Installation und zu typischen Stolperstellen zusammen.
ADFS-Versionen
Seit ihrer ersten Veröffentlichung in Windows Server 2003 R2 haben sich die ADFS deutlich weiterentwickelt. Handelte es sich zunächst um eine weitgehend proprietäre Technik, um die Anmeldung an Web-Applikationen zwischen zwei getrennten AD-Umgebungen zu erleichtern, geht es mittlerweile darum, die wichtigsten Industriestandards auch herstellerübergreifend zu unterstützen. Genau dort wird es leider schnell unübersichtlich, denn die Dokumentation der ADFS im Web bezieht sich auf die verschiedenen “historischen” Versionen, was nicht immer ausreichend deutlich wird.
Hier eine Übersicht über die verschiedenen Fassungen:
Seit Windows Server 2012 ist die Funktion als Rolle ins Betriebssystem eingebunden. Vorher handelte es sich um optionale Komponenten; die Versionen 1.1 und 2.0 standen als Download bereit.
Idee und Architektur
Die Active Directory Federation Services orientieren sich an zwei Grundkonzepten:
- Claims-based Authorization (Anspruchsbasierte Zugriffskontrolle) basierend auf Anmelde-Token
- Single-Sign On für Web-Applikationen
Das Prinzip trennt dabei strikt zwischen der Applikation, auf die jemand zugreifen möchte, und der Stelle, die die Anmeldedaten verwaltet und die eigentliche Anmeldung ausführt. Dabei geht das Grundszenario davon aus, dass die Verwaltung der Benutzer (hier auch “Identitäten” genannt) durch ein Unternehmen geschieht, üblicherweise die Firma, bei der die betreffende Person arbeitet. Die Applikation hingegen wird von einem anderen Unternehmen betrieben, typischerweise also eine Web-Applikation oder ein Cloud-Service.
In herkömmlichen Architekturen verwaltet ein Cloud- oder Applikationsanbieter die Benutzerkonten selbst: Jeder Benutzer legt sich bei dem jeweiligen Dienst ein eigenes Benutzerkonto an und meldet sich dann dort separat mit seinen Anmeldedaten an. Das hat zwei wichtige Nachteile: Zum einen müssen Anwender für jeden Dienst ein eigenes Konto mit Kennwort haben und die Anmeldedaten sicher verwahren. Zum anderen haben Unternehmen keine Kontrolle darüber, wo welcher Mitarbeiter ein Konto hat. Das erzeugt großen Aufwand und auch Sicherheitsprobleme. Wenn etwa ein Mitarbeiter das Unternehmen verlässt oder seine Aufgaben sich ändern, dann soll er wahrscheinlich keinen Zugriff mehr auf eine externe Web-Applikation haben, weil er dort ja beispielsweise Kosten für das Unternehmen verursachen könnte. Hier ist es nun schwierig für das Unternehmen, die einzelnen Benutzerkonten zu sperren oder zu löschen; oft wird es einfach übersehen oder vergessen.
Das Prinzip der “Federation” verlagert daher die Kontenverwaltung zurück in das Unternehmen. Vereinfacht gesagt, schließen der Anbieter der Applikation und das Unternehmen, das die Applikation verwenden möchte, einen Vertrag, der festlegt, in welchem Umfang die Dienste genutzt werden sollen. Im zweiten Schritt richten beide Seiten eine technische Infrastruktur ein, mit der das Nutzer-Unternehmen die Anmeldekonten und die Zugriffsrechte selbst verwaltet. Die Applikation akzeptiert dann diese Anmeldungen, weil sie auf Grundlage des Vertrags dem Nutzer-Unternehmen vertraut. So können die Verantwortlichen in dem Nutzer-Unternehmen selbst steuern, welche Anwender Zugriff haben, und diesen Zugriff auch selbst einschränken oder entfernen. Das kann zum Beispiel über klassische Gruppenmitgliedschaften geschehen: Wer in einer bestimmten Gruppe im eigenen Active Directory ist, darf auf die Web-Applikation bei dem Provider zugreifen und hat dort bestimmte Rechte.
Die Technik kann dabei nicht nur zwischen zwei getrennten Unternehmen zum Einsatz kommen, sondern auch innerhalb derselben Organisation. Dabei könnte beispielsweise eine Trennung zwischen verschiedenen Netzwerk- oder Sicherheitsbereichen das Ziel sein: Der Anwender nutzt eine Applikation in der DMZ oder ein privates Gerät, meldet sich aber mit seinem internen Konto aus dem Active Directory der Firma an.
Der Vorteil für den Anwender besteht darin, dass er mit einem einzigen Anmeldekonto auf verschiedene Dienste zugreifen kann. Er muss sich nicht verschiedene Kontendaten merken, oft ist es nicht einmal nötig, Benutzername und Kennwort mehrfach einzugeben.
Komponenten und Begriffe
Wie auch andere Systeme, die auf demselben Prinzip beruhen, unterscheiden die ADFS einige Komponenten und verwenden bestimmte Begriffe. Die wichtigsten stellen wir hier vor.
Die “Parteien” eines Verbunds haben ein definiertes Vertrauensverhältnis. Die Anmeldung geschieht mit Tokens, die Informationen in Form von Claims enthalten.
Grundsätzlich besteht eine “Federation” oder ein Verbund immer aus zwei Parteien. Die eine Partei (in der Abbildung links) ist üblicherweise der Kunde, der die Benutzerkonten verwaltet (Identity Provider). Die andere Partei ist der Anbieter der Applikation (Application Provider), der die Anmeldungen aus dem Netzwerk des Kunden akzeptiert. Beide Parteien tauschen für den Anmeldeprozess und die Zugriffssteuerung sogenannte “Security Tokens” aus. Diese ähneln den Kerberos-Tickets oder den Access Tokens in einem Windows-Netzwerk mit Active Directory: Bei der Anmeldung erhält der Benutzer ein solches Token, das seine Identität bestätigt und weitere Informationen enthält, beispielsweise Gruppenmitgliedschaften oder Abteilungszugehörigkeiten. Das Token liegt in Form eines XML-Dokuments vor, das von der ausgebenden Stelle (also vom Identity Provider) per Zertifikat verschlüsselt oder signiert ist. Dieses Token übergibt der Anwender (vereinfacht gesagt) der Applikation auf der anderen Seite, die es entschlüsselt und dadurch sicher sein kann, dass das Token von dem vertrauten Identity Provider stammt. Aufgrund der Vertrauensbeziehung (Trust Relationship) geht der Application Provider davon aus, dass der Identity Provider bei der Anmeldung des Benutzers nicht geschlampt hat und das Token daher tatsächlich eine gültige Anmeldung dokumentiert.
Die Informationen, die in dem Token stehen, bezeichnet man als “Claims”, was sich mit “Ansprüche” oder “Behauptungen” übersetzen lässt. Das können verschiedene Daten sein; welche genau, haben Kunde und Anbieter vorher vertraglich festgelegt und über ihre technische Infrastruktur umgesetzt. Es könnte sich etwa um einen Anmeldenamen sowie um einen Realnamen handeln, damit die Applikation den Benutzer namentlich ansprechen kann. Weiterhin können Daten enthalten sein, die den Zugriff innerhalb der Applikation festlegen: Gehört der Benutzer etwa der Rolle “Besteller” an und ist diese im Token hinterlegt, dann darf er Bestellungen ausführen. Ist der Mitglied der Abteilung “Vertrieb”, dann darf er auf Angebote zugreifen – und so weiter.
Diese Claims können aus ganz verschiedenen Daten zusammengesetzt sein. In einer Windows-Umgebung ist es üblich, mit Gruppenmitgliedschaften zu arbeiten, aber manchmal ist das nicht flexibel genug. Daher kann die Infrastruktur auch andere Werte heranziehen, etwa Textfelder aus dem Active Directory oder auch Daten aus separaten Datenbanken. Diese Informationen kodiert der Identity Provider in dem Token dann so, dass der Application Provider etwas damit anfangen kann. Die Informationen, die der Identity Provider hinausgibt, bezeichnet man als “Outgoing Claims”, diejenigen, die der Application Provider annimmt, sind “Incoming Claims”. Welche Daten der Kunde (also der Identity Provider) verwendet und wie er sie verarbeitet, legt er selbst organisatorisch fest. Der Application Provider seinerseits gibt dem Kunden vor, welche Arten von Claims er in seiner Applikation verwenden kann und wie diese formatiert sein müssen. Daher ist es oft nötig, dass der Kunde seine Claims für den Application Provider zunächst umformatiert oder “übersetzt”, bevor er sie in das Security Token schreibt.
Auf diese Weise lässt es sich erreichen, dass die tatsächlichen Anmeldedaten, die ein Benutzer verwendet, niemals das Netzwerk seines Unternehmens verlassen. Er meldet sich im Idealfall ganz normal mit seinen AD-Anmeldedaten an einem internen Domänencontroller an, und die ADFS erzeugen dann ein Security Token für den Application Provider, das aussagt: Diesen Benutzer haben wir überprüft. Das Token enthält dann nicht das Kennwort des Benutzers und auch keine weiteren Daten, die intern bleiben müssen. So lässt sich über die Infrastruktur ein hohes Sicherheitsniveau und gleichzeitig (zumindest potenziell) auch ein gutes Datenschutz-Niveau erreichen, weil vertrauliche Daten nie das interne Netzwerk verlassen müssen.
Übrigens verwenden viele “alltägliche” Applikationen genau dasselbe Prinzip. Viele Apps oder Web-Dienste, die man auch als Privatperson nutzt, akzeptieren etwa die Anmeldung mit einem Facebook- oder Twitter-Konto. Dabei kommt exakt derselbe Grundaufbau zum Einsatz. Die Applikation akzeptiert die Anmeldung von Facebook oder Twitter, weil sie diesen Diensten vertraut. Sie kennt aber weder den Anmeldenamen noch das Kennwort des Benutzers, weil sie diese Informationen gar nicht benötigt. Im Hintergrund erhält die Applikation ein Token von dem Anmeldedienst, das die gültige Anmeldung bestätigt.
Um diesen Grundaufbau haben sich verschiedene Protokolle entwickelt. Die wichtigsten davon, die auch die ADFS in der aktuellen Version unterstützen, sind:
- WS-Federation (Web Service Federation) und die gesamte Protokollfamilie namens “WS-*”
- SAML (Security Assertion Markup Language)
- OAuth (Open Authorization)
Anmeldeprozess
Die Anmeldung mithilfe der ADFS (oder eines verwandten Systems) geschieht in mehreren Schritten, die eine beachtliche Komplexität aufweisen. Wenn die technische Infrastruktur gut aufgebaut ist, bekommt der Anwender allerdings nahezu nichts davon mit.
Der Anmeldevorgang über ADFS in schematischer Form
In der Abbildung möchte der Anwender (unten links), der bei der Firma “Trey Research” arbeitet, auf eine Web-Applikation bei der Firma “A. Datum” zugreifen (unten rechts). Er öffnet also seinen Browser und gibt den URL der Applikation ein oder klickt auf einen Link, worauf sich die Web-Startseite der Applikation öffnet (Schritt 1 in der Grafik). Die Applikation stellt nun fest, dass der Benutzer noch nicht angemeldet ist. Sie sendet daher einen “Redirect” an den Browser zurück, also einen neuen URL, der auf den Anmeldeserver bei A. Datum verweist (Schritt 2). Der Browser verbindet sich also mit diesem Anmeldeserver, in der Abbildung als “Resource Federation Server” bezeichnet (Schritt 3). Dieser Server erkennt nun, dass es sich um einen Benutzer von Trey Research handelt (wie er dies erkennt, ist Sache des Application Providers, der dafür einen Mechanismus implementiert haben muss – er könnte etwa für verschiedene Kunden verschiedene Start-URLs nutzen, die die Anwender verwenden, oder er könnte auf der Startseite eine Auswahl per Dropdown anfordern). Daher sendet der Server einen weiteren Redirect an den Browser, der auf den internen Federation-Server bei Trey Research verweist (Schritt 4).
Der Browser wendet sich nun an den internen Server, in der Abbildung “Account Federation Server” (Schritt 5). Je nachdem, ob sich der Benutzer schon intern angemeldet hat oder nicht, könnte der Benutzer nun eine Anmeldeaufforderung sehen. Diese Anmededaten überprüft der interne ADFS-Server gegen das Active Directory (Schritte 6 und 7) und stellt dem Benutzer dann ein Security Token aus, das ihn zum Zugriff auf den Federation-Server von A. Datum berechtigt (Schritt 8). Per Redirect sendet der Browser dieses Token an den “Resource Federation Server” (Schritt 9), der es entschlüsselt und feststellt, dass es von dem vertrauten Federation-Dienst bei dem Geschäftspartner Trey stammt.
Der Fededation Server von A. Datum stellt dem User nun ein Security Token für die eigene Web-Applikation aus und sendet es zusammen mit einem URL-Redirect an den Browser zurück (Schritt 10). Nun ist der Benutzer fast am Ziel, und der Browser sendet das Security Token an den Webserver bei A. Datum, der die Applikation hostet (Schritt 11). Im Gegensatz zum allerersten Zugriff erkennt die Web-Applikation dank des Tokens nun die gültige Anmeldung des Benutzers und gestattet ihm den Zugriff.
ADFS-Architektur
Die Active Directory Federation Services sind nur eine von mehreren Implementierungen des oben beschriebenen Prinzips. Auch andere Hersteller haben die Technik umgestetzt und nutzen dafür teils deutlich andere Architekturen. Im Folgenden stellen wir den Aufbau der ADFS vor. Dabei konzentrieren wir uns auf die Seite des “Kunden”, also des Identity Providers. Auf der anderen Seite (beim Application Provider) kommen noch zahlreiche andere Fragen in den Fokus, weil es dort vor allem um die Entwicklung oder Anpassung der Applikation(en) geht.
Der Aufbau der ADFS in ihrer aktuellen Fassung
Das Kernstück der ADFS in Windows Server 2012 R2 ist der ADFS-Server oder Federation Server. Hierbei handelt es sich um einen Windows-Server (oder mehrere), der die Rolle “Active Direcory-Verbundserver” installiert hat. Dieser Server muss Mitglied des Active Directory sein und sollte keine anderen Anwendungen ausführen (das ist allerdings nur eine Best-Practice-Empfehlung, keine technische Voraussetzung). Neben den eigentlichen Diensten und Komponenten der ADFS (in der Grafik im blauen Kasten unten links) benötigt der ADFS-Server eine Konfigurations-Datenbank sowie mindestens einen Attributspeicher. Der ADFS-Server selbst führt die wesentliche Arbeit aus. Er authentifiziert Benutzer, sammelt die relevanten Daten (Attribute) über sie ein und stellt sie zu Claims und Token zusammen. Benötigt man für diesen Dienst eine Ausfallsicherheit, so kann man mehrere ADFS-Server als Farm installieren. Ähnlich wie bei Domänencontrollern sind hierzu keine Clusterdienste nötig, allerdings wäre dann ein Loadbalancing erforderlich.
Die Datenbank kann im einfachsten Fall auf dem Server selbst gespeichert werden. Sie speichert normalerweise nur Konfigurationsinformationen. Hierzu nutzt Windows dann die “Windows Internal Database” (WID), was technisch betrachtet eine Art SQL Server Express ist (nur ohne Verwaltungswerkzeuge). Alternativ kann man bei der ADFS-Installation auch einen separaten “vollwertigen” SQL Server angeben, was für sehr große Umgebungen auch zu empfehlen ist (dann auch gern als SQL-Cluster). Möchte man mehr als einen ADFS-Server betreiben, so ist dies allein noch kein zwingender Grund, einen eigenen SQL Server dafür zu nutzen, denn die erste (oder primäre) WID-Datenbank repliziert ihre Daten auf die Read-only-Kopien der anderen ADFS-Server. Die WID-Datenbanken können jedoch maximal mit fünf ADFS-Servern genutzt werden (was allerdings auch schon eine sehr große Umgebung wäre). Die WID-Implementierung unterstützt allerdings zwei ADFS-Funktionen nicht, nämlich SAML Artifacts und Token Replay Detection. Hierzu müssen größere Datenmengen gespeichert werden, was in einer WID-Datenbank nicht sinnvoll wäre.
Der oder die Attributspeicher enthalten Informationen über die Benutzer, die authentifiziert werden sollen und die Zugriffsrechte erhalten wollen. Standardmäßig ist das lokale Active Directory als Attributspeicher eingebunden, es lassen sich aber auch weitere Quellen wie etwa SQL-Server-Datenbanken angeben, wenn dort wichtige Informationen über die Nutzer liegen. Die Logik, nach der diese zusätzlichen Informationen ausgelesen und den Benutzern zugeordnet werden sollen, muss man dann allerdings selbst entwickeln (was normalerweise Programmierarbeit bedeutet).
In den meisten Fällen soll eine ADFS-Implementierung Zugriffe auf Applikationen außerhalb des eigenen Netzwerks ermöglichen. Oft sollen auch die Clients, die die Applikation (und damit die ADFS-Authentifizierung) verwenden wollen, vom Internet aus zugreifen. Hier ist es dringend zu empfehlen, nicht den ADFS-Server selbst an das Internet anzubinden, sondern in der DMZ einen ADFS-Proxy-Server für diesen-Zweck einzurichten (besser gesagt: Einen Reverse Proxy Server). Achtung: Diese Komponente war in früheren Versionen ein Teil der ADFS-Installationspakete, noch in Windows Server 2012 installierte man sie fast auf demselben Weg wie die ADFS-Dienste selbst. Seit Windows Server 2012 R2 hingegen ist dies eine eigene Rolle des Betriebssystems, die nun “Web Application Proxy” (WAP) heißt und Teil der Remotezugriffsdienste ist. Ein solcher Proxy wird immer auf einem separaten Server installiert (was logisch ist, denn er soll ja in einer DMZ laufen) und darf kein Mitglied des Active Directory sein. Auch hier kann man mehrere Proxies installieren und per Loadbalancing anbinden, um Lastverteilung und Ausfallsicherheit zu erreichen.
Aufbau einer ADFS-Serverfarm
Sobald ADFS strategisch eingesetzt werden soll, ist die Frage nach der Zuverlässigkeit zu beantworten. Hierbei bietet sich auf der Seite des Kunden (Identity Provider) ein Farm-Aufbau aus mehreren Servern an. Wie oben beschrieben, lassen sich die beiden Serverkomponenten ADFS-Server und ADFS-Proxy mehrfach installieren. Die Konfigurationsdatenbank kann auf einem separaten Datenbankserver oder auch einem Datenbankcluster laufen.
Die eigentliche Last auf den Servern ist in den meisten Umgebungen eher gering und dürfte nur selten ein Grund sein, mehrere Server einzusetzen. Microsoft spricht von mehreren hundert Tokens pro Sekunde, die von einem einzigen aktuellen ADFS-Server ausgestellt werden können. Tatsächlich geht es also eher um Ausfallsicherheit: Stehen mehrere Server zur Verfügung, so könnte einer ausfallen, ohne dass die Dienste insgesamt nicht erreichbar sind.
In einer solchen Farm ist der Zugriff auf die jeweiligen Dienste über einen Loadbalancing-Dienst zu gewährleisten. Dazu kommen Hardware-Loadbalancer in Frage, notfalls auch das Windows-eigene Network Load Balancing. Einen möglichen Aufbau zeigt die Abbildung.
Eine ADFS-Farm kann aus mehreren Systemen bestehen und sollte Loadbalancing einsetzen.
Einrichten des Verbunds mit dem Application Provider
Sobald die technische Infrastruktur auf der Kundenseite vorhanden ist, kann die Vertrauensbeziehung (Trust Relationship) zu dem Application Provider eingerichtet werden, der im Zusammenhang mit ADFS auch oft als “Relying Party” bezeichnet wird (denn er verlässt sich darauf, dass der Anmeldeprozess beim Kunden ordentlich verläuft). Das ist zunächst ein organisatorischer Prozess: Für die jeweilige Applikation ist zu klären, welche funktionalen Unterscheidungen durch die Authentifizierung ermöglicht werden sollen – oder einfacher: welche Berechtigungen die Applikation unterscheiden kann und welche Informationen sie dazu benötigt. Anbieter, die bereits Erfahrungen mit dieser Art der Anbindung haben, werden üblicherweise Anleitungen und Whitepapers dazu vorhalten.
Auf Basis dieser Informationen entscheidet der Kunde dann, welche Attribute er für seine Benutzer benötigt und wie sein ADFS daraus Claims erzeugen soll. In welchem Format diese Claims bei dem Application Provider ankommen müssen, sollte aus dessen Spezifikation hervorgehen.
Der eigentliche Trust zwischen den beiden Netzwerken ist dann technisch betrachtet meist recht einfach einzurichten. Hierfür sollte das System des Application Providers einen Satz von XML-Dokumenten erzeugen, die der Kunde online oder in Form von Dateien in seine ADFS-Konfiguration einspielt. Damit ist die grundlegende Vertrauensbeziehung hergestellt.
Je nachdem, welche funktionalen Anforderungen in der organisatorischen Klärung zu Beginn des Vorgangs identifiziert wurden, muss der Kunde nun in ADFS einen Satz von Regeln erzeugen, die beschreiben, welche Daten ADFS zu den Benutzern aus dem Attributspeicher liest, wie es diese zusammenstellt und wie es sie “übersetzt”, damit der Application Provider sie lesen und interpretieren kann. Solche Regeln kann man, sofern sie sehr einfach sind, über das grafische Administrationsprogramm zusammenstellen. Sobald etwas mehr Komplexität nötig ist, muss man sie jedoch in einer eigenen Regelsprache formulieren, was einigen Entwicklungs- und Testaufwand erzeugt.
ADFS kann eine sehr komplexe, mehrstufige Regelverarbeitung einsetzen, bei der mehrere Regeltypen zum Einsatz kommen können. Die “Acceptance Rules” geben an, unter welchen Umständen ein Benutzer authentisiert wird, also kurz gefasst: welche Benutzer Zugriff erhalten. Hierzu können Claims herangezogen werden, also Informationen über das Benutzerkonto. Die weiteren Regeln werden nur dann angewendet, wenn die Authentisierung erfolgt: Die “Transformation Rules” legen fest, wie die eingehenden Claims umgewandelt werden, bevor sie in das Security Token eingefügt werden (und damit zu ausgehenden Claims werden). Dies ist Teil der “Issuance Rules”, die den Ausstellungsprozess des Security Tokens steuern.
Wie oben angemerkt, können Regeln praktisch beliebig komplex werden. Dabei kann das Ergebnis einer Regel durch eine nachfolgende Regel weiter verarbeitet werden, was man als “Rule Chaining” bezeichnet.
Die Regelverarbeitung in ADFS erfolgt in mehreren Schritten.
Test- und Laboraufbauten
ADFS kann man nur dann “richtig” testen bzw. in einem Laboraufbau nachvollziehen, wenn man einen Application Provider tatsächlich anbinden kann. Das ist natürlich nicht ohne Weiteres machbar, denn natürlich verlangen die Provider Geld für ihre Dienste. Manche Beschreibungen im Web nutzen daher angepasste SharePoint-Installationen, die als Web-Applikation herhalten. Die ganze Komplexität mit Proxy und Webzugriff sowie mit den Spezialitäten, die ein “echter” Application Provider einfordert, lässt sich aber kaum nachbilden, um die Technik einfach kennenzulernen. Auf einem Microsoft-Blog ist eine Artikelreihe im Entstehen, die einen Labor-Aufbau beschreibt. Leider allerdings benötigen die Autoren offensichtlich deutlich mehr Zeit dafür, als sie geplant hatten. Trotzdem sind die Hinweise sehr hilfreich.
Weitere Informationen
[FAQ on ADFS – Part 1 – Ask Premier Field Engineering (PFE) Platforms – Site Home – TechNet Blogs]
http://blogs.technet.com/b/askpfeplat/archive/2013/07/22/faq-on-adfs-part-1.aspx
[Identity and Access Management: Single Sign-on Across Organizations and the Cloud – Active Directory Federation Services 2.0 Architecture Drilldown | Tech·Ed North America 2010 | Channel 9]
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/SIA326
[How to Build Your ADFS Lab on Server 2012 Part 1 – Ask Premier Field Engineering (PFE) Platforms – Site Home – TechNet Blogs]
http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-adfs-lab-on-server-2012-part-1.aspx
[How to Build Your ADFS Lab on Server 2012, Part2: Web SSO – Ask Premier Field Engineering (PFE) Platforms – Site Home – TechNet Blogs]
http://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-adfs-lab-on-server-2012-part2-web-sso.aspx
[How to Build Your ADFS Lab on Server 2012 Part 3: ADFS Proxy – Ask Premier Field Engineering (PFE) Platforms – Site Home – TechNet Blogs]
http://blogs.technet.com/b/askpfeplat/archive/2014/03/17/how-to-build-your-adfs-lab-on-server-2012-part-3-adfs-proxy.aspx
http://faq-o-matic.net/?p=5810