Integrierte Nutzung der Identitätsinformationen
Identity Federation
Identity Federation gehört zu den interessantesten Themen der IT überhaupt. Denn einerseits lassen sich mit Federation-Technik viele bestehende Probleme lösen, andererseits bietet die Federation aber auch sehr viel Potenzial für die Optimierung bestehender Geschäftsprozesse und die Etablierung neuer Geschäftsmodelle.
Um die vorhandenen Potenziale zu nutzen, gilt es, sich zunächst mit den Konzepten der Identity
Federation zu beschäftigen. Die Grundidee ist eine Trennung zwischen der Authentifizierung und der
Autorisierung und die "föderierte" Nutzung der Identitätsinformationen, also der Verbund mehrerer
Systeme.
Zwei wichtige Komponenten: Identity- und Service Provider
Die beiden wichtigsten Komponenten in diesem Modell sind der Identity Provider und der Service
Provider. Ein Identity Provider stellt Identitätsdaten bereit und übernimmt die Authentifizierung.
Ein Service Provider stellt einen Dienst bereit, auf den zugegriffen wird. Er führt die
Autorisierung der Zugriffe durch. Identity Provider und Service Provider kommunizieren auf Basis
von standardisierten Protokollen, die wiederum auf Webservices aufsetzen und damit sehr flexibel
einsetzbar sind – auch über Unternehmensgrenzen hinweg. Es gibt etliche Beispiele dafür, wie sich
Federation einsetzen lässt. Eines der bekanntesten Praxisbeispiele ist die Zusammenarbeit zwischen
Boeing und Southwest Airlines. Dabei geht es um den Onlinezugriff auf Handbücher, der nach
Benutzergruppen differenziert erfolgen soll und bei dem im Gegensatz zur früheren Bereitstellung
der Handbücher in Papierform beachtliche Kosten vermieden werden.
Die Herausforderung dabei ist, dass die Handbücher aus einem System von Boeing stammen. Wer was
sehen darf, ist jedoch bei Southwest Airlines zu entscheiden. Ein Pilot erhält andere Informationen
als eine Stewardess, die wieder andere als ein Wartungstechniker zu sehen bekommt. Der typische
Lösungsansatz wäre, die Benutzer von Southwest Airlines bei Boeing noch einmal anzulegen oder sie
dorthin zu synchronisieren. Dies ist jedoch aufwändig. Sobald man mehrere Datentöpfe hat, steigt
der Pflegeaufwand, während die Datenqualität abnimmt.
Mit Identity Federation kann dagegen eine Authentifizierung für die Zugriffe auf die Handbücher
bei Southwest Airlines erfolgen. Dort sind die Benutzer ohnehin vorhanden. Und es ist immer
bekannt, wer welche Rolle hat. Der Zugriff erfolgt anschließend auf das System von Boeing. Dieses
braucht nur eine Rolleninformation, um zu steuern, welche Informationen ein Benutzer angezeigt
bekommt. Es ist also unnötig, unzählige Benutzer doppelt zu pflegen.
Anwendungsbeispiel: Zugriff im Portal
Ein anderes Beispiel ist der Zugriff auf Anwendungen in einem Portal. Hier sollte eine einmalige
Authentifizierung am Portal erfolgen. Anschließend sollte nur noch entschieden werden, welche
Portlets ein Benutzer sieht und welche Aktionen er ausführen darf. Dazu gibt es häufig spezifische
Lösungen der einzelnen Portalsoftwareprodukte. Diese stoßen aber spätestens dann an ihre Grenzen,
wenn auch Anwendungen externer Partner in ein Portal integriert werden sollen. Mit Federation kann
ein Identity Provider die Authentifizierung am Portal übernehmen. Alle Portlets arbeiten als
Service Provider. Da Webservice-basierende Mechanismen die Arbeitsbasis bilden, lassen sich auch
Portlets von externen Partnern wie beispielsweise einem Reisebüro für die Buchung von
Geschäftsreisen einfach einbinden.
Vertrauen, zusätzliche Attribute und die Implementierung
Die genannten Beispiele verdeutlichen drei spezifische Herausforderungen der Federation. Die
erste ist, dass ein Vertrauen zwischen Identity Provider und Service Provider bestehen muss. Dies
ist allerdings in erster Linie eine organisatorische Herausforderung, in dem beispielsweise
vertraglich definiert wird, welche Stärke die Authentifizierung haben muss und wie die zentralen
Komponenten des Identity Providers – also Verzeichnisdienst und Authentifizierungsmechanismus –
geschützt werden.
Die zweite ist, dass je nach Anwendung unterschiedlich viele Informationen transportiert werden
müssen. Das Spektrum reicht von einer Ja-Nein-Entscheidung über die Identifikation eines
individuellen Benutzers bis hin zur Anforderung zusätzlicher Attribute, die beispielsweise
Rolleninformationen enthalten. Die Federation-Protokolle unterstützen aber die gesamte Bandbreite
dieser Anforderungen.
Schließlich stellt sich noch die Frage, wie man Federation implementieren kann. Dafür gibt es
zwei Ansätze: Entweder sind Anwendungen Federation-fähig, indem man die Authentifizierungs- und
Autorisierungsmechanismen entsprechend anpasst oder man schaltet eine Access-Management-Lösung vor.
Die meisten Produkte im Webaccess-Management-Umfeld können inzwischen als Federation Endpoint
arbeiten. Damit sind keine Anpassungen an den dahinter stehenden Anwendungen erforderlich. Da die
Federation-Unterstützung aber relativ einfach zu implementieren ist, wird die Entwicklung
mittelfristig zu einer direkten Integration von Federation in Anwendungen gehen.
Wie es bei neuen Themen üblich ist, gibt es bei der Federation leider zwei konkurrierende
Standardisierungsbestrebungen. Eine sind die Liberty-Alliance-Standards, von denen ein Teil
inzwischen bei der Standardisierungsorganisation OASIS gelandet ist. Die zweite sind die
WS-*-Standards (Webservices), die von Microsoft, IBM, BEA und einigen anderen Herstellern getrieben
werden.
Aktuell gibt es einerseits Bestrebungen, die Interoperabilität zwischen diesen Ansätzen zu
vergrößern. Andererseits ist auch zu beobachten, dass die Federation-Produkte der meisten wichtigen
Anbieter sowohl die WS-*- als auch die Liberty-Alliance-Standards unterstützen. In der Praxis gilt
allerdings derzeit, dass SAML 2.0, inzwischen bei der OASIS und ein wichtiges Element der
Liberty-Standards, die beste Integrationsbasis ist.
So hat zum Beispiel Kuppinger Cole und Partner im vergangenen Herbst eine Demonstration der
Interoperabilität zwischen verschiedenen Herstellern organisiert. Die schnellsten Anbieter haben es
innerhalb von drei Stunden geschafft, ihre Systeme für das Zusammenspiel zu konfigurieren, ohne
dass sie das jeweils andere System vorher gekannt hätten.
Einfachere Administration
Wie schon an den genannten Beispielen deutlich wird, ist ein Nutzen der Identity Federation die
einfachere Administration. Statt Benutzer an mehreren Stellen zu pflegen oder Verzeichnisse
aufwändig zu synchronisieren, gibt es einen zentralen Identity Provider, dem vertraut wird. Die
anderen Systeme agieren als Service Provider.
Es kann aber auch mehrere Identity Provider geben. Ein Beispiel dafür ist der Zugriff mehrerer
Zulieferer auf ein Portal eines Herstellers, bei dem die Verwaltung der Benutzer und deren
Authentifizierung jeweils beim Zulieferer erfolgt, der damit als Identity Provider fungiert. Auch
hier ist aber die Reduktion des administrativen Aufwands ein wichtiger Aspekt – umso mehr, als es
Fälle gibt, bei denen für einen einzelnen großen Zulieferer mehr als 10.000 Benutzerkonten bei
einem einzelnen Automobilhersteller verwaltet werden müssen. Und da jeder Zulieferer mehrere Kunden
und jeder Hersteller viele Zulieferer hat, multipliziert sich der hier entstehende administrative
Aufwand. Gerade an solchen Beispielen wird der Wert der Identity Federation deutlich. Man kann
schon durch die Reduktion des administrativen Aufwands eine deutliche Reduktion von Kosten
erreichen. Gleichzeitig ergibt sich aber auch eine viel höhere Flexibilität bei der Gestaltung von
Geschäftsprozessen, wenn die Benutzer nicht noch einmal gesondert angelegt werden müssen, sondern
man "nur" eine Vertrauensstellung zu einem vorhandenen Identity Provider definieren und dort
eventuell noch wenige zusätzliche Rollen pflegen muss.
Federation als Business-Modell
Zusätzlich entstehen aber neue Möglichkeiten für Geschäftsmodelle. So ist Covisint, früher vor
allem als B2B-Marktplatz für die Automobilindustrie bekannt, inzwischen dabei, sich als "Federation
Broker" zwischen Zulieferern und Herstellern – nicht nur in der Automobilindustrie – zu etablieren.
Damit wird beispielsweise der Aufwand für die Definition der Vertrauensstellungen reduziert, weil
jeder Zulieferer und Hersteller nur Covisint vertrauen muss. Die Zahl der Beziehungen ist
reduziert, das Modell wird noch einfacher.
Auf der anderen Seite macht Federation aber auch den Aufbau gemeinsamer Angebote einfacher.
Unternehmen können einfacher zusammenarbeiten und beispielsweise Informationen über einen Benutzer
weitergeben. So könnte ein Kunde sich bei einem Portal seines Automobilherstellers registrieren und
dort gleich Reifen bei einem Kooperationspartner ordern.
Dieser muss den Kunden gar nicht kennen, da der Automobilhersteller als Identity Provider
fungieren könnte und beispielsweise die Information über das Fahrzeug weitergibt. Dabei gibt es
sicherlich noch Privacy-Fragen, die zu klären sind. Es gibt aber in fast jedem Unternehmen Ideen,
die bisher nicht realisiert werden konnten, weil eben die Möglichkeit zur gemeinsamen Nutzung von
Identitätsdaten gefehlt hat.
Identity Federation ist, wie die Ausführungen der vorangegangenen Abschnitte schon andeuten,
darüber hinaus auch eine unverzichtbare Basis für Anwendungen, die dem Modell der SOA (Service
Oriented Architecture) folgen. Anders formuliert: Wer nicht nur flexible Geschäftsprozesse möchte,
sondern auch sichere Geschäftsprozesse, braucht Identity Federation im Speziellen und ein gutes
Fundament in Form einer Identity-Management-Infrastruktur im Allgemeinen.
Basis für sichere SOA-basierende Applikationen
Dazu gehört eine hohe Datenqualität beim Identity Provider, um eine verlässliche Basis für die
Authentifizierung zu bieten. Diese Qualität entsteht nur durch definierte Prozesse für den Umgang
mit Identitätsdaten. Dann kann man eine Authentifizierung für den Prozess durchführen. Die
genutzten Services können über die per Federation übergebenen Informationen zu den Benutzern die
Autorisierung durchführen.
Da Federation auf Basis von Webservices arbeitet, ist dies zwangsläufig der logische Ansatz für
serviceorientierte Anwendungen. Noch wichtiger aber ist, dass man damit auf alle Dienste im Kontext
des Benutzers zugreifen kann, also eine End-to-End-Security erhält. Man vermeidet also den heute so
oft zu findenden Ansatz, bei dem mit vollen Berechtigungen auf einen Service zugegriffen und über
den Code dann selektiert wird, was der Benutzer sehen darf – ein Ansatz, der von außen weder
steuerbar noch nachvollziehbar und damit streng genommen nicht "Compliance-fähig" ist.
Fazit: Identity Federation ist zu Recht aktuelles Thema
Identity Federation ist also zu Recht ein Hype-Thema – aber es ist gleichzeitig auch wesentlich
mehr. Die aktuellen Studien und Analysen von Kuppinger Cole und Partner deuten darauf hin, dass es
in 2007 eine deutlich steigende Zahl von Pilotprojekten geben wird. Aber erst ab 2008 wird Identity
Federation in der Breite genutzt werden. Dennoch ist es höchste Zeit, sich mit den Chancen zu
beschäftigen, die Federation-Lösungen sowohl für die Administration als auch die Gestaltung von
Geschäftsprozessen bieten.
Lesen Sie mehr zum Thema
