In einer reinen Cloud- Architektur verwaltet ein Applikationsanbieter (Application Provider) die Benutzerkonten selbst: Es wird für jeden Benutzer beim jeweiligen Dienst ein Benutzerkonto (Identität) angelegt und auch dort verwaltet. Der Benutzer muss sich dann dort explizit mit den Anmeldedaten seines Benutzerkontos anmelden.
Das hat gewichtige Nachteile: Zum einen müssen Anwender für jeden Dienst ein eigenes Konto mit den Kontodaten und Kennwort haben und die Anmeldedaten sicher verwahren. Das erzeugt i.d.R. hohen Verwaltungsaufwand beim Anwender. Zudem ist das Verfahren sehr fehleranfällig.
Sobald Unternehmen die Nutzung von Cloud Services zulassen, haben sie keine Kontrolle über das Nutzungsverhalten der Mitarbeiter im Internet. Das erzeugt großen Aufwand und enorme Sicherheitsprobleme (Datenfluss).
Verlässt ein Mitarbeiter das Unternehmen oder ändern sich seine Aufgaben, wird es schwierig, seinen Zugriff auf externe Web- Applikation zu unterbinden, wenn er sie nicht mehr benötigt werden. Im günstigsten Fall fallen nur Nutzungskosten für das Unternehmen an, im ungünstigen Fall fließen unternehmensrelevante Daten ab, die zu großen Schäden führen können.
Leider ist es aus technischen (Username und Passwort liegen nicht vor) und – teilweise – rechtlichen (wem gehört den der Account?) Gründen 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 deshalb die gesamte Benutzerverwaltung zurück in das Unternehmen.
Dabei trennt das Prinzip der Federated Identity strikt zwischen der Applikation, auf die jemand zugreifen möchte, und der Stelle, die die Anmeldedaten verwaltet und die Anmeldung ausführt. Dabei setzt man voraus, dass die Verwaltung der Benutzer (“Identitäten” genannt) intern geschieht, üblicherweise in dem das Unternehmen, für das die betreffende Person arbeitet. Die Applikation hingegen wird von einem anderen Unternehmen betrieben, typischerweise eine Web-Applikation oder ein Cloud-Service.
Um eine Ferderation Identity zu nutzen schließen der Applikationsanbieter (Application Provider) und das Unternehmen, das die Applikation verwenden möchte (Identity Provider), einen Vertrag, der den Nutzungsumfang der Applikation regelt.
Auf der Grundlage des Vertrags verbinden sich beide Unternehmen
technisch in einen sog. Trust. Im Trust wird die technische Umsetzung des oben geschlossenen Vertrages umgesetzt. Er ist Voraussetzung für die Akzeptanz der Applikation für die Anmeldungen.
So kann der Identity-Provider steuern, welche Benutzer welche Berechtigung zum Zugriff haben. Er kann diesen Zugriff zum Beispiel über klassische Gruppenmitgliedschaften einschränken oder entfernen: Wer in einer bestimmten Gruppe im eigenen Active Directory ist, darf auf die Web-Applikation bei dem Provider zugreifen und hat dort die Rechte, die er für seine Tätigkeit benötigt.
Die Methodik 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 Benutzer liegt in der einfachen Handhabung seiner Identität. Er muss nicht mit verschiedene Kontendaten arbeiten, sondern meldet sich nur einmal in seinem Netzwerk an.
Die technische Unterstützung erfährt die Federation durch den Microsoft Active Directory Federation Services (AD FS). AD FS wird seit Windows Server 2003 R2 entwickelt und eingesetzt. Allerdings gewinnt dieser Dienst erst durch die Nutzung von Cloud Services wie Azure und Office 365 an Bedeutung, weil es für die Integration interessant ist.