Federated Identity Management

Transkript

1 IAMaaS IDM RBAC AM/SSO PAM EDU FACHBERICHT Federated Identity Management IAM über die Grenzen des Unternehmens hinaus Autor: Michael Petri Hamburg, Deutschland Winterthur, Schweiz Wien, Österreich IPG AG Technoparkstrasse 2 CH-8406 Winterthur T info@ipg-ag.com

2 Inhalt 1. Einführung 3 2. Aufteilung von Authentifizierung und Autorisierung Die Authentifizierung durch den Claims Provider Tokens und Claims Die Autorisierung durch die claims-aware Applikation Attribute Based Access Control 7 3. Der Federated Trust Der Intermediary Die Virtualisierung der Authentifizierung Die Relying Party ist auch ein Service Provider Mehrwert dank Federated IDM Der richtige Umgang mit Tokens IAM und das Federated Identity Management Fazit Portrait Michael Petri IPG AG 18 Seite 2

3 1. Einführung Federated Identity Management hilft den Unternehmen, das stetige Wachstum von zu administrierenden Identitäten und Benutzerkonten unter Kontrolle zu bringen. Mit Cloud Computing und der allerorts vorhandenen Anbindung an das Internet werden vermehrt Applikationen ausserhalb der unternehmenseigenen Domäne genutzt. Die eigenen Mitarbeiter sind nicht mehr in der Lage alle Logins zu kennen. Das Unternehmen ist nicht mehr in der Lage, auch die externen Partner oder gar Kunden effizient zu verwalten. Dies führt zu einer ungebremsten Steigerung des Administrationsaufwandes, beginnend beim Service Desk. Verstärkt wird dies noch durch den Umstand, wenn eine sichere Authentisierung gefordert ist, für welche Hardware wie Kartenleser oder Token von Nöten ist. Ausserhalb des Unternehmens laufende Applikationen werden immer häufiger geschäftskritisch und sollen daher ins Identity & Access Management (IAM) integriert werden. Die Pflege der Identitätsattribute, das Provisioning und Deprovisioning dürfen nicht in der Eigenverantwortung des Mitarbeiters liegen. Sie müssen durch das Unternehmen in dazu vorgesehenen Prozessen kontrolliert werden. So entsteht plötzlich ein Anspruch an das IAM, über die Grenzen des Unternehmens hinaus zu wirken. Mit der Anbindung externer Applikationen entstehen neue Herausforderungen. Die Federation ist die aufstrebende Lösung dafür, welche Universitäten und Grosskonzerne schon lange verwenden. Der Nutzen der Federation ist dabei weitaus grösser als nur die Reduktion von Logins und die Implementation von komfortablem und sicherem Single Sign On (SSO) über die Grenzen des Unternehmens hinaus. Die Federation ist ein gegenseitiger Trust zwischen zwei Parteien. Der Claims Provider verwaltet die Identitäten seiner Mitarbeiter. Die Relying Party betreibt für die Mitarbeiter des Claims Providers eine Anwendung. Über den federated Trust werden Tokens mit Identitätsinformationen ausgetauscht. Der Claims Provider stellt die Tokens nach erfolgreicher Authentifizierung des Benutzers aus und die Relying Party verwendet die Tokens für die Autorisierung. Das System für Federated Identity Management ist eine Ergänzung zum bestehenden System für Identity & Access Management (IAM). Vorhandene Prozesse, Technologien, Konzepte und Produkte für das IAM behält man bei und erweitert sie, um auch den unternehmensübergreifenden Zugriff aus dem IAM kontrollieren zu können. IPG AG unterstützt als Experte Unternehmen aller Branchen, um die komplexe Welt von Identitäten und Benutzerkonten auch firmenübergreifend verwalten zu können. Die Erfahrung zeigt, dass oftmals mit dem Überschreiten der Unternehmensgrenze auch die Hoheit über die Benutzer und Prozesse verloren geht. Eine Hoheit, die aus rechtlicher Sicht nicht verloren gehen darf. Seite 3

4 2. Aufteilung von Authentifizierung und Autorisierung Authentifizierung und Autorisierung werden oft in einem Zug genannt. Doch diese zwei Vorgänge müssen nicht als unzertrennliches Paar betrachtet werden. Wer sich mit der Federation beschäftigt, muss sich mit der Schnittstelle zwischen diesen Vorgängen befassen und sich ihrer Abgrenzung bewusst werden. Bei der Federation werden die Authentifizierung und die Autorisierung auf zwei Parteien bzw. Unternehmen aufgeteilt. Das erste Unternehmen nennt man Claims Provider 1. Die Benutzer dieses Unternehmens nutzen eine Anwendung, welche ein anderes Unternehmen betreibt. Dieser Betreiber ist das zweite Unternehmen und wird als Relying Party bezeichnet. Die bereitgestellte Anwendung ist eine erweiterte Web-Applikation, welche aus dem Browser aufgerufen wird (nachfolgend claims-aware Applikation genannt) Die Authentifizierung durch den Claims Provider Der Claims Provider führt ein Directory mit den Identitäten all seiner Benutzer. Im Directory sind zu jedem Benutzer Attribute wie Name, Vorname, -Adresse, etc. sowie Gruppenmitgliedschaften hinterlegt. Die wichtigste Aufgabe des Claims Providers ist es, diese Identitäten auf eine sichere Art und Weise zu authentifizieren. Bei der Wahl des Authentifizierungs-Protokolls hat der Claims Provider nur zu berücksichtigen, dass es sich um ein sicheres Verfahren handeln soll. Zum Einsatz kommen heute meist Kerberos oder eine TLS-Client Authentifizierung. Die Authentifizierung des Benutzers gegen das Directory nimmt ein Security Token Service (STS) vor. Microsoft Active Directory Federation Services 2.0 (ADFS 2.0), Quest One Identity, CA SiteMinder und viele weitere Produkte für Federations-Endpunkte beinhalten einen solchen STS. Auch bestehende Entry Server beinhalten die Möglichkeiten für Federationen. Man kann diese weiter nutzen und ergänzen. Nach erfolgreicher Authentifizierung liest der STS die Attribute des Benutzers aus dem Directory aus und erstellt ein sogenanntes Token. Dieses Token wird im Hintergrund an den Browser des Benutzers übermittelt. Claims Provider Active Directory 2. Informationen beziehen Security Token Service (STS) 1. Benutzer authentifizieren und Token anfragen 3. Token erstellen und an Browser übermitteln Web-Browser Token Benutzer Abbildung 1: Ablauf der Authentifizierung durch den Claims Provider 1 1 Die Terminologie dieser Begriffe ist in der Literatur nicht einheitlich. Anstelle der Bezeichnung Claims Provider findet man auch die Bezeichnungen Identity Provider oder Asserting Party. Die Relying Party wird oft auch als Service Provider bezeichnet. Claims-aware Applikationen werden oft auch assertion-aware Applikationen genannt. Seite 4

5 2.2. Tokens und Claims Ein Token ist ein signiertes und verschlüsseltes XML-Dokument, welches der Claims Provider STS erzeugt. Später wird es von der Relying Party für die Autorisierung des authentifizierten Benutzers eingesetzt. Im Token sind Claims enthalten. Ein Claim ist ein Namen-Werte-Paar, welches den Benutzer beschreibt und für dessen Korrektheit der Claims Provider als Herausgeber verantwortlich ist. Die Anzahl und auch die Art der Claims kann frei gewählt werden, ausschlaggebend ist der Nutzen des Claims. Name, -Adresse und Gruppenmitgliedschaften sind klassische Beispiele für Claims, aber auch gegen die Schuhgrösse als Claim spricht nichts, wenn denn diese von Nutzen ist. Die Signatur des Ausstellers gewährt die Authentizität und Integrität der im Token enthaltenen Claims. Die Verschlüsselung garantiert zudem, dass die enthaltene Information von niemand anderem als dem Empfänger, also der Relying Party, gelesen werden kann. Ein Zeitstempel im Token gibt dessen Ablaufzeit an. Token Claim 1 Claim 2 Claim 3... Claim n Beispiele für Claims: - Name - Alter - -Adresse - Rollen -... Ablaufzeit Signatur Abbildung 2: Ein Token mit Claims und Beispielen für Claims 2.3. Die Autorisierung durch die claims-aware Applikation Der Claims Provider stellt auf Anfrage einer Relying Party die Tokens aus. Greift ein Benutzer auf eine claims-aware Applikation zu, wird er automatisch an den Claims Provider weitergeleitet. Dieser führt eine Authentifizierung durch und sendet das Token an die Relying Party. Diese entschlüsselt es und überprüft anschliessend die Signatur und den Zeitstempel. Ist all dies korrekt, kann die claims-aware Applikation die Claims für die Autorisierung verwenden. Claims Provider Security Token Service (STS) Relying Party 8. Autorisierung mit Claims claims-aware Applikation 5. Token für Relying Party ausstellen Token 4. Token für Relying Party anfordern 1. Zugriff anfragen Web-Browser 2. Weiterleitung zur Authentifizierung erforderlich Token 7. Token übermitteln Benutzer 3. und 6. automatische Weiterleitung Abbildung 3: Ablauf der Anmeldung mit SSO an einer claims-awaren Applikation Seite 5

6 Für die Verarbeitung solcher Tokens und damit eine Web-Anwendung zu einer claims-aware Applikation wird, können verschiedene Bibliotheken eingesetzt werden. Beispielsweise existiert in.net die Windows Identity Foundation (WIF), eine sehr umfangreiche Bibliothek mit einem modularen und erweiterbaren Aufbau. Der Aufwand, um eine Applikation claims-aware zu machen, ist damit minimal. Das bestehende Authentifizierungs-Modul, welches in der web.config aktiviert ist, wird mit dem Tool FedUtil auf die Module von WIF umgestellt. Sodann wird beim Aufruf der Applikation ein Token gefordert und es erfolgt automatisch eine Weiterleitung der Anfrage an den zuständigen Claims Provider zur Authentifizierung. Das zurückerhaltene Token wird dann vom WS-Federation Authentication Module (WSFAM) verarbeitet und validiert. Ist das Token gültig, wird vom Session Authentication Module (SAM) ein IClaimsPrinciple Objekt erstellt und in einem Cookie im Browser des Benutzers abgelegt. <<interface>> IPrinicpal - Identity: IIdentity <<interface>> IIdentity - AuthenticationType: String - IsAuthenticated: Boolean - Name: String + IsInRole(): boolean <<interface>> IClaimsPrinicpal - Identity: IClaimsIdentity <<interface>> IClaimsIdentity - Claims: Claim Claim - ClaimType: String - Issuer: String - OriginalIssuer: String - Subject: IClaimsIdentity - Value: String Abbildung 4: UML-Klassendiagramm des bekannten IPrinciple und dem neuen IClaims-Principle Das IClaimsPrinciple Objekt ist eine Erweiterung des bekannten IPrinciple, welches von allen konventionellen Authentifizierungs-Modulen für.net im Einsatz ist. Damit ist IClaimsPrinciple kompatibel mit IPrinciple. Die Autorisierungs-Entscheidungen, welche über die gesamte Applikation im Code verteilt erfolgen, funktionieren also weiterhin, sofern die Methode IPrinciple.isInRole(Rollenname) verwendet wurde. In diesem Fall wird das Claim Role abgefragt, denn dieses enthält die vom Claims Provider vergebenen Benutzerrollen. Damit integriert sich eine claims-aware Applikation in ein bestehendes RBAC-Konzept. Der Name des Benutzers ist wie bis anhin in einem IClaimsIdentity Objekt abgelegt. Andere Attributwerte bezog man früher oft aus dem Directory z.b. mittels LDAP-Abfragen. Dies ist bei claims-aware Applikationen nicht mehr notwendig. Eine Anbindung an das Directory und damit eine zusätzliche Abhängigkeit ist obsolet. Das gesuchte Attribut wurde bereits als Claim im Token mitgesendet und ist als Claim Objekt in der IClaimsIdentity referenziert. Auf diese Weise kann man möglicherweise auf ein Benutzerprofil in der claims-aware Applikation verzichten und - noch wichtiger - es entstehen neue Möglichkeiten für die Autorisierung: Für Autorisierungsentscheidungen kann man nun die Claims beiziehen. Seite 6

7 2.4. Attribute Based Access Control Diese neuen Möglichkeiten für die Autorisierung basierend auf Claims sind eine Umsetzung von Attribute Based Access Control (ABAC) 2. Um eine Autorisierungsentscheidung herbeizuführen, wird ein Regelwerk verarbeitet. In den Zugriffsregeln werden Attribute unter Verwendung von logischen Operationen untersucht. Es können drei Klassen von Attributen berücksichtigt werden: Identitäts-Attribute Ressourcen-Attribute Umgebungs-Attribute Bei Identitäts-Attributen handelt es sich um Informationen zum Benutzer, welcher auf eine Ressource zugreifen möchte. Bezogen auf die Federation handelt es sich typischerweise um Claims, welche der Claims Provider liefert. Die Ressourcen-Attribute umfassen Transaktionen aus der Anwendung, Metadaten von Dateien und dergleichen Informationen über das Objekt, auf welches der Benutzer zugreifen möchte. Die Umgebungs-Attribute beschreiben den erweiterten Kontext um den Zugriff. Sie enthalten einfache Informationen wie beispielsweise die Zeit, aber auch abstraktere, allgemeingültige Informationen beispielsweise zum Status des Systems oder Netzwerks bezüglich der Sicherheit. Abbildung 5: Autorisierung mittels Attribute Based Access Control Der Gestaltung von Zugriffsregeln mit ABAC sind kaum Grenzen gesetzt. Bei der Autorisierung kann man beliebig viele Attribute einbeziehen und diese mit logischen Ausdrücken verknüpfen. Auch mathematische Operationen oder Funktionen von Datum und Zeit kann man nutzen. Ein solch mächtiges, flexibles und feingranulares Regelwerk aufzubauen erfordert jedoch einigen Aufwand. Eine weitere Schwierigkeit bei ABAC ist, dass plötzlich einzelne Attribute autorisierungsrelevant werden und entsprechend sorgfältig zu pflegen sind. Dies führt zu neuen, ungern gesehenen Aufgaben und Verantwortungen für die HR-Abteilung. Es gilt daher exakt zu definieren, welche Identitäts-Attribute gepflegt sind und in ABAC-Zugriffsregeln verwendet werden dürfen. Sogleich drängt sich das Bedürfnis auf, auch die erlaubten Attributwerte festzulegen, was den administrativen Aufwand ansteigen lässt. Daher empfiehlt sich die Verwendung von ABAC nur in komplexen Situationen und nur mit minimaler Anzahl von Attributen. 2 E. Yuan und J. Tong, «Attribute Based Access Control (ABAC) for Web Services» [Online]. URL: [Zugriff am 22 Oktober 2012]. Seite 7

8 Als Alternative drängt sich eine Kombination aus ABAC und Role Based Access Control (RBAC) auf. Man erstellt weiterhin Rollen und weist sie den Benutzern zu. So wie es RBAC vorsieht. Die bestehenden IAM-Betriebsprozesse für Rollen können weiterhin genutzt werden. Im Token sind die Rollen als Role Claim enthalten und können von der claims-aware Applikation genutzt werden. Für die Autorisierung selbst setzt man, wo erforderlich, ABAC-Zugriffsregeln ein. Mit diesen Zugriffsregeln kann man Rollen und einzelne, ausgewählte Attribute kombinieren. Auch die Kombination von mehreren Rollen ist möglich. Seite 8

9 3. Der Federated Trust Kommen wir zurück zur Federation und betrachten dieses Konzept etwas detaillierter. Der Claims Provider und die Relying Party müssen sich gegenseitig vertrauen. Damit das gegenseitige Vertrauen ausgedrückt werden kann, besteht ein Federated Trust aus zwei unabhängigen Bestandteilen: Der Claims Provider richtet auf seinem STS ein Relying Party Trust ein. Damit erlaubt er die Herausgabe von Tokens an die Relying Party und äussert sein Vertrauen in die Reyling Party, dass sie sachgemäss und vertrauensvoll mit den bereitgestellten Claims umgeht. Die Relying Party richtet einen Claims Provider Trust ein. Sie vertraut dadurch auf die korrekte Pflege der Attribute durch den Claims Provider und der Authentizität der erhaltenen Tokens. Erst wenn der Relying Party Trust und der Claims Provider Trust eingerichtet sind, ist der federated Trust zustande gekommen. Da die zwei Parteien mit den zwei gegenseitigen Trusts einen Kreis formen (vgl. Abbildung 6), wird hier vom Circle of Trust gesprochen. Der Circle of Trust kann von jeder Partei ohne mitwirken der anderen Partei unterbrochen werden. Sobald dies geschieht, ist der federated Trust nicht mehr funktionsfähig. Relying Party Trust Claims Provider Relying Party (claims-aware Application) Claims Provider Trust Abbildung 6: Der Relying Party Trust und der Claims Provider Trust bilden gemeinsam einen federated Trust 3.1. Der Intermediary Ist der erste federated Trust eingerichtet, dauert es nicht lange bis zum zweiten, dritten und vierten. Je mehr Trusts eingegangen werden, umso lohnenswerter ist die Investition in das Federated IDM System. Das Federated IDM System ist eine Infrastruktur, die genutzt und ausgelastet werden will. Doch mit vielen Trusts stellt sich die Frage: Wie können all diese Trusts verwaltet werden? Soweit wir die Federation bis jetzt kennen, stellt dies in der Tat ein Problem dar. Wie die Abbildung 7 zeigt, führt der einfache Federated Trust tendenziell zu einer Vollvermaschung zwischen den Claims Providern und den Relying Parties. Noch schlimmer erscheint dies aus der Optik der Relying Party: Sie unterhält meist eine Vielzahl von claims-aware Applikationen. Weil jede dieser claims-aware Applikationen ein Endpunkt des Federated Trusts darstellt, sind zur Anbindung eines Claims Providers sogar mehrere Federated Trusts notwendig. Seite 9

10 Claims Provider 1 Federated Trusts Relying Party 1 (claims-aware Application) Claims Provider 2 Relying Party 1 (claims-aware Application) Claims Provider 3 Relying Party 1 (claims-aware Application) Abbildung 7: Vollvermaschung von Claims Providern und Relying Parties mit federated Trusts Natürlich ist dies nicht praktikabel. Deshalb wird in der Praxis ein einfacheres Verfahren angewandt. Dieses stellt Abbildung 8 dar und basiert auf einem Hub-and-Spoke-Modell. Die Spokes sind die Claims Provider und die claimsaware Applikationen. Als Hub kommt ein sogenannter Intermediary zum Einsatz. Der Intermediary ist ebenfalls ein STS. Gegenüber dem Claims Provider nimmt er die Rolle einer Relying Party ein. Aus Sicht der claims-aware Applikation erscheint der Intermediary wie ein Claims Provider. Die Anzahl der Trusts ist damit minimal gehalten und die Frage nach dem Verwaltungsaufwand entschärft. Claims Provider 1 Federated Trusts Relying Party Federated Trusts claims-aware Application 1 Claims Provider 2 Intermediary claims-aware Application 2 Claims Provider 3 claims-aware Application 3 Abbildung 8: Reduktion der federated Trusts mit der Einführung eines Intermediarys Es drängt sich die nächste Frage auf: Wer soll einen Intermediary betreiben? Die Antwort ist ganz einfach: die Relying Party. Der eine Grund wurde bereits erwähnt. Die Relying Party betreibt üblicherweise mehrere Anwendungen. Wenn ein zusätzlicher Claims Provider angebunden werden soll, dann würde dies bei der direkten Anbindung einen Change an jeder Applikation erfordern. Mit dem Konzept des Intermediaries hat eine claims-aware Applikation genau einen federated Trust, nämlich denjenigen zum Intermediary. Diesen Trust kann man alleinig durch die Relying Party verwalten und erfährt dadurch möglichst wenige Änderungen. Die Integration von neuen Anwendungen ist kostengünstig und rasch möglich. Die beiden nachfolgenden Kapitel gehen auf die zwei weiteren Gründe ein Die Virtualisierung der Authentifizierung Die claims-aware Applikation muss sich dank dem Intermediary nicht mehr um verschiedene Claims Provider kümmern. Ihr einziger Ansprechpartner für die Authentifizierung ist der Intermediary. Für diese Kommunikation muss die claims-aware Applikation nur ein einziges Federations-Protokoll unterstützen. Eine Implementation von Authentifizierungsprotokollen wie Kerberos, NTLM, Digest, TLS und was es alles gibt, ist bei der claims-aware Applikation nicht notwendig. Die sichere Authentifizierung ist Sache des STS beim Claims Provider. Sollte ein etabliertes Authentifizierungsprotokoll Schwachstellen aufweisen und durch ein neues ersetzt werden, so betrifft dies nur den STS, aber keinesfalls die claims-aware Anwendung. Seite 10

11 Die Wahrscheinlichkeit ist gering, dass ein STS als fertiges Produkt eines Softwarelieferanten eine Schwachstelle aufweist, die lange nicht behoben wird. Ebenso unwahrscheinlich ist es, dass das Produkt die aktuellen Authentifizierungsprotokolle nicht unterstützt. Schliesslich ist das Produkt zu diesem Zweck geschaffen und steht in einem harten Konkurrenzkampf mit anderen Produkten. Bei der Herstellung der claims-aware Applikation kann sich der Entwickler also auf die sichere Implementation eines Federations-Protokolls konzentrieren. Dies senkt den Entwicklungsaufwand und erhöht die Sicherheit der gesamten Anwendung. formular-basierte Authentifizierung zertifikat-basierte Authentifizierung Kerberos? Claims Provider?? Kerberos? Applikation Token Intermediary Token SAML? Kerberos Claims Provider Token WS-Federation WS-Federation SAML Token Applikation SAML formular-basierte Authentifizierung zertifikat-basierte Authentifizierung Abbildung 9: Eine Applikation muss nur noch ein Federatationsprotokoll (grün) implementieren und wird von allen Authentifizierungsprotokoll (gelb) unabhängig. Wie die Abbildung 9 zeigt, existieren nicht nur viele Authentifizierungsprotokolle (gelb), sondern auch etliche Federations-Protokolle (grün). Zu letzteren gehören die bekannten Protokolle Security Assertion Markup Language (SAML) und WS-Federation. Die grundlegenden Konzepte dieser Protokolle sind nahezu identisch. Die Resultate eines Vergleiches bezüglich Funktionalität, Sicherheit und weiterer Kriterien können aus der Dissertation von Hommel 3 entnommen werden. Viele STS unterstützen mehrere Federations-Protokolle, wodurch ein Intermediary auch Transformationen zwischen den Protokollen vornehmen kann. Somit funktioniert eine claims-aware Applikation, welche nur ein Federations-Protokoll unterstützt, mit jedem Claims Provider, jedem anderen Federations- Protokoll und jedem Authentifizierungsprotokoll. Aus Sicht der Applikation kann also durchaus von einer Virtualisierung der Authentifizierung gesprochen werden. 3 W. Hommel, Architektur- und Werkzeugkonzepte für föderiertes Identitäts-Management, München: Ludwig-Maximilians-Universität, URL: Seite 11

12 3.3. Die Relying Party ist auch ein Service Provider Setzt man diese Theorie der Virtualisierung der Authentifizierung konsequent um, kann sich ein Benutzer der Relying Party nicht mehr direkt an der claims-aware Applikation anmelden. Die claims-aware Applikation unterstützt keine Authentifizierungsprotokolle, sondern delegiert die Authentifizierung an den Intermediary. Damit muss sich auch ein Benutzer im Unternehmen der Relying Party bei einem Claims Provider authentifizieren. Auf den ersten Blick scheint dies ein unnötiger Umweg zu sein. Auf den zweiten Blick jedoch offenbart sich ein grosser Nutzen. Viele Vorteile einer Föderation gelten nicht nur unternehmensübergreifend, sondern auch unternehmensintern. Hierzu gehören: SSO mit einem sicheren Verfahren ist möglich. Zentrale Verwaltung und Durchführung der Authentisierung. Zentralisierung und Virtualisierung der Authentifizierung senken das Risiko für Sicherheitslücken. Die Applikationen verwenden ein einheitliches Authentifizierungsverfahren und eine standardisierte Anbindung. Die Applikationen benötigen keine Anbindung an das Directory, um Identitäts-Attribute zu beziehen. Der Entwicklungs- und Wartungsaufwand für Applikationen nimmt ab. Immer mehr Applikationen unterstützen Federationsprotokolle (z.b. SAP, SharePoint und viele weitere). All diese Gründe sprechen dafür, federated Trusts auch unternehmensintern einzusetzen. Dem widerspricht auch nichts, weil man die Infrastruktur eines Federated IDM Systems mehrfach nutzen kann. Weil der Intermediary ein vollwertiger STS ist, kann er in einer Mehrfachrolle agieren. Er ist erstens Ansatzpunkt für Föderationen zu anderen Unternehmen. Zweitens föderiert er mit den claims-aware Applikationen und drittens kann er Benutzer authentifizieren und als Claims Provider auftreten. In der Praxis verschmelzen die zwei Funktionen des Claims Providers und der Relying Party also wieder. Mit der Infrastruktur eines Federated IDM Systems kann ein Unternehmen somit beide Funktionen gleichzeitig übernehmen, mit anderen Unternehmen föderieren und die vorhandenen Föderationen selbst nutzen. Seite 12

13 4. Mehrwert dank Federated IDM Mit Federated IDM verlangsamt sich die Zunahme von Identitäten im unternehmenseigenen Directory. Dies reduziert den Aufwand für die Pflege der Identitäten. Man muss keine Identitäten von Partnern im eigenen Directory anlegen, sondern kann die bestehenden Identitäten im Directory des Partners nutzen. Die Zahl der Identitäten im eigenen Directory ist abhängig von der Anzahl eigener Mitarbeiter. Unabhängig von der Anzahl Personen aus Partnerunternehmen, welche auf die bereitgestellten claims-awaren Anwendungen zugreifen, bleibt der Verwaltungsaufwand für die Pflege des eigenen Directories konstant. Auch bei Business to Customer (B2C) kann man die Federation einsetzen. Public Identity Provider verwalten Identitäten von Privatpersonen. Hierzu gehören SwissID, LiveID, Facebook und viele weitere. Eine Federation mit diesen öffentlichen Claims Providern ist möglich. Es erlaubt dem Service Provider, seine Anwendungen an die Kunden bereitzustellen, ohne alle Kunden-Identitäten im Directory pflegen zu müssen. Trotzdem warten viele Unternehmen mit dem Aufbau eines Systems für Federated IDM zu. Sie zweifeln an der Rentabilität dieser Infrastruktur und sehen den Nutzen noch nicht. Weil ihre Partner noch keine Federationen unterstützen, fehlt der Anreiz, eine Infrastruktur für das Federation IDM möglichst rasch aufzubauen. Doch plötzlich ist der Bedarf da, eine Möglichkeit für einen federated Trust gegeben, doch das Federated IDM System fehlt dann. Der Aufwand für das Setup und den Betrieb ist zu gross für einen einzelnen federated Trust. Das notwendige Wissen und die Erfahrung fehlen. Zugegeben: Die Eintrittshürden sind hoch. Mit der Erkenntnis, dass eine Relying Party auch ein Claims Provider ist und man die Infrastruktur einer Federated IDM vielseitig nutzen kann, ist der Weg zur Rentabilität geebnet. Bei der Lancierung eines Federated IDM kann man keine sofortige Rentabilität erwarten. Zuerst muss das Potenzial eines Federated IDM Systems im Sinne einer Infrastruktur erkannt werden. Dieses liegt in der hohen Flexibilität und den vielfältigen Einsatzzwecken. Wie bei anderen Projekten im IAM-Umfeld ist ein stufenweiser Einstieg ratsam. Wo der erste Schritt erfolgt, ist nicht ausschlaggebend. Wichtig ist der zweite Schritt, welcher rasch auf den ersten folgen soll und kann. Der erste Schritt bringt hauptsächlich Kosten mit sich. Das lässt sich leider nicht verhindern. Mit dem zweiten Schritt beginnt man, das Potenzial zu nutzen und profitiert bereits von der Investition aus dem ersten Schritt. Den zweiten Schritt zu finden, ist einfach, denn man weiss nun, wie es geht und was man kann. Sobald der Bedarf für einen federated Trust plötzlich auftritt - und er tritt plötzlich auf - kann man zuschlagen, eine einfache Lösung bereitstellen und damit Kosten einsparen. Die Federation ist sehr flexibel. Wer sie einsetzen will, muss ebenso flexibel sein und frühzeitig die Grundlagen dafür schaffen Der richtige Umgang mit Tokens Die Sicherheit der federated Trusts basiert auf Kryptographie. Die Tokens sind verschlüsselt und signiert. Da auch Cookies zum Einsatz kommen, sind alle Verbindungen durch SSL geschützt. Der Inhalt der Cookies ist verschlüsselt und die Flags secure und httponly schützen das Cookie vor Diebstahl. Dank diesen Massnahmen gilt die Federation als sicher, sofern die eingesetzten Schlüssellängen und Cipher korrekt gewählt sind. Mit vielen federated Trusts zwischen vielen Unternehmen entsteht eine Art Netzwerk. Wie in einem Datennetzwerk können die Pakete bzw. die Tokens von einem Knoten zum nächsten wandern. Anders ausgedrückt sind federated Trusts transitiv. Die Folge ist in Abbildung 10 ersichtlich. Seite 13

14 Ein Unternehmen A unterhält einen federated Trust zu einem Unternehmen B. Dieses wiederum hat einen federated Trust zum Unternehmen C. Obwohl Unternehmen A mit dem Unternehmen C keinen direkten federated Trust hat, können Tokens des Unternehmens A zu der claims-aware Applikation C gelangen. Abbildung 10: erlaubter und unerlaubter Tokenfluss über federated Trusts Mit der Grundkonfiguration leitet ein STS Tokens unbeschränkt weiter. In manchen Fällen ist dies gewünscht, oft aber äusserst ungewollt. In den Tokens können sich sensitive Daten zur Identität des Benutzers befinden, welche der Claims Provider durch den Relying Party Trust einer Relying Party anvertraut. Durch diese Weitergabe von Tokens kann schlimmstenfalls sogar der Datenschutz des Claims Providers verletzt werden. Um den Tokenfluss zu kontrollieren, sind gemäss einer praktischen Empfehlung von John Craddock 4 (Microsoft) mehrere Massnahmen auf dem STS erforderlich: Der STS des Claims Providers darf nur die minimal notwendigen Claims für den Zugriff auf die claims-aware Applikation herausgeben. Jedem Token wird ein sogenanntes Marker-Claim beigefügt, welches den Ursprung des Tokens enthält (typischerweise der FQDN des Claims Providers). Ein Intermediary STS prüft den Marker-Claim und sendet das Token nur dann weiter, wenn der Claims Provider eine Weiterleitung über diesen federated Trust erlaubt. Empfängt ein STS ein unvollständiges Claim, d.h. ohne gültiges Marker-Claim, wird das Token verworfen. Ein federated Trust setzt voraus, dass der Partner vertrauensvoll mit den Tokens umgeht. Die Regeln zur Steuerung des Tokenflusses einzuhalten, ist eine Bedingung für die Vertrauenswürdigkeit. Diese und weitere Vereinbarungen zur Einhaltung von Gesetzen und Regeln muss man in einem Federations-Vertrag zwischen dem Claims Provider und der Relying Party klären. In einem solchen Vertrag geht es nicht nur um Datenschutz und Haftungsfragen, sondern auch um technische Aspekte zur Einhaltung von formalen Grundsätzen. 4 J. Craddock, «Active Directory Federation Services,Part 2: Building Federated Identity Solutions,» 18. Mai [Online]. URL: Seite 14

15 5. IAM und das Federated Identity Management Zweifelsohne besteht ein Zusammenhang zwischen dem Federated Identity Management und dem IAM. Wer das Federated Identity Management als einen Bestandteil des IAM Systems betrachtet, liegt nicht falsch. Schliesslich soll es in den Prozessen möglichst keinen Unterschied zwischen unternehmensinternen und -externen Applikationen geben. Viele Sicherheits- und Compliance-Anforderungen gelten gleichermassen. Nur technisch funktioniert der Zugriff auf die Applikation unterschiedlich, was in der Praxis zu einer Unterteilung in zwei ebenbürtige und sich ergänzende Komponenten führt. Ein Unternehmen mit einem etablierten IAM-System kann dieses durch Federated Identity Management erweitern. Am IAM-System sind bereits Quellsysteme wie das HR-System und interne Applikationen als Zielsysteme angeschlossen. Die etablierten Prozesse und Workflows erlauben die sichere, automatisierte Berechtigungszuweisung und (De-)Provisionierung von Benutzerkonten. Das IAM-System fungiert als ein Metadirectory, welches die Daten über die Identitäten in den Quellsystemen beschafft, sammelt und nur die notwendigen Identitätsattribute an die Zielsysteme weiterleitet. Identity & Access Management Gesetze Reglemente Konzepte Federated Identity Management Federations- Verträge Konzepte Prozesse Prozesse HR System Directory Anderer Claims Provider Anderes Quellsystem Applikation IAM Provisioning Security Token Service Andere Relying Party Claims-aware Application Applikation Konnektoren Konnektoren Benutzerkonten Datenbank Konnektoren Metadatenbank Federated Trusts Claims-aware Application Abbildung 11: Zusammenhang zwischen dem Identity & Access Management und dem Federated Identity Management Wenn eine Lösung für Federated Identity Management an das bestehende IAM-System angeschlossen werden soll, dienen zwei Systeme als Schnittstelle: ein Directory zur Authentifizierung, wie zum Beispiel das Active Directory eine Datenbank mit Benutzerkonten und Identitäts-Attributen Theoretisch könnte man das Directory für beide Funktionen einsetzen. Die Funktionalität vieler Directories würde es erlauben. Eine Trennung bietet sich aber nicht nur zu didaktischen Zwecken an. Durch eine Auslagerung der Benutzerkonten und Identitäts-Attribute in eine SQL-Datenbank steigt die Flexibilität bezüglich der Erweiterbarkeit des Schemas und ermöglicht einfache Abfragen mit hoher Performance. Den Account im Directory nutzt das Federated Identity Management System für die Authentifizierung von Benutzern. In der zusätzlichen Datenbank liegen die Benutzerkonten für die Applikationen, welche über die Federation angebunden sind. Das IAM-System legt pro Benutzer und Applikation ein entsprechendes Benutzerkonto an. Es ist möglich, dem Benutzerkonto eine Gültigkeitsdauer zu geben und nur diejenigen Attribute zu hinterlegen, welche der Applikation preisgegeben werden dürfen. Seite 15

16 An das Directory und die Datenbank mit den Benutzerkonten ist das Federated Identity Management System angebunden. Seine Aufgaben sind die Pflege von Verbindungen zu externen Applikationen anderer Organisationen oder die Bereitstellung eigener Applikationen für eine Federation. Existiert noch kein IAM-System, ist dies nicht tragisch, denn Federated Identity Management ist trotzdem möglich. Nur von den hohen Synergien zwischen dem IAM und dem Federated Identity Management kann nicht profitiert werden. Die Datenbank mit Benutzerkonten entfällt. Das Federated IDM-System muss stattdessen mehrere Quellsysteme anbinden, um alle benötigten Attribute zu beschaffen. Diese zusätzlichen Schnittstellen bringen Mehraufwand und Kosten. Die Authentifizierung erfolgt weiterhin gegen das Directory. Für das Federated IDM System ist die Ermittlung, ob ein Benutzer eine externe Applikation nutzen darf, nur aufwändig möglich. Unabhängig davon, ob ein IAM-System im Unternehmen vorhanden ist, kann man ein Federated Identity Management einführen und damit sicheres Single Sign On (SSO) über die Grenzen des Unternehmens ermöglichen. Seite 16

17 6. Fazit Viele Unternehmen zögern mit der Einführung eines Federated IDM-Systems und stellen die Rentabilität dieser Infrastruktur in Frage. Dabei entsteht der Nutzen der Federation erst mit seinem flexibel erweiterbaren und vielfältigen Einsatz. Wer die Einsatzmöglichkeiten der Federation erkennt und einen ersten Schritt in Richtung deren Umsetzung geht, findet darin rasch einfache Lösungen für plötzlich auftretende Probleme. Federated IDM bietet einfache Möglichkeiten, um SSO über Unternehmensgrenzen hinaus zu ermöglichen. Man kann es aber auch für SSO auf unternehmensinterne Anwendungen nutzen, was eine bessere Auslastung der Infrastruktur zur Folge hat. Immer mehr Anwendungen, die im unternehmenseigenen Rechenzentrum laufen, unterstützen die Federation als sicheres Verfahren für die zentralisierte Authentifizierung. Ein früher Einsatz dieser etablierten Technologie zahlt sich aus. Wer jetzt Erfahrungen mit Föderationen sammelt, ist in naher Zukunft gerüstet für die nächste Stufe der Vernetzung mit Partnern, Lieferanten und Kunden. Die Experten von IPG AG können Sie beim Aufbau eines Federated IDM Systems beraten und unterstützten. Unsere langjährige Expertise über Zugriffsmodelle, Prozesse, Rechtsgrundlagen und IAM-Systeme kann Ihnen zu einem erfolgreichen Start mit dem Federated Identity Management verhelfen. So konzipierte und implementierte IPG AG bei einem Schweizer Handelsbetrieb die Anbindung des Filialnetzes. Über Händler und Servicepartner können dadurch zuverlässig und sicher auf zentrale Anwendungen zugreifen und untereinander Daten austauschen. Seite 17

18 7. Portrait 7.1. Michael Petri Michael Petri, Bachelor in Informatik der Zürcher Hochschule für angewandte Wissenschaften, ist Consultant für Identity & Access Management bei der IPG AG in Winterthur. Er verfügt über fundiertes Wissen und Erfahrung in Federated Identity Management. Er analysiert bestehende Berechtigungsmanagement-Umgebungen und etabliert neue Rollenmanagement-Prozesse und Rollenmodelle IPG AG Als Experte für Identity & Access Management bietet IPG AG Lösungen für den umfassenden Schutz von Benutzerdaten und Zugriffsrechten an; dies für Unternehmen und Verwaltungen der gesamten Wirtschaft. Der Integrationsexperte ist auf die Planung und Implementierung von Lösungen für die Verwaltung von Benutzerdaten und Zugriffsrechten spezialisiert. Die langjährige Projekterfahrung garantiert ein umfassendes Verständnis für alle Themen rund um das Identity & Access Management. Die Experten von IPG AG unterstützen in den Themen: Identity & Access Management as a Service Identity Management & Provisioning Role Based Access Control Access Management & Single Sign On Privileged Access Management Education Mit praxisorientierten Prozessen und fundiertem Informatik-Wissen bauen die Experten Brücken zwischen Organisation und Informatik. Viele Kunden aus allen Branchen vertrauen auf die Funktion des Enablers IPG AG. Als bevorzugter Umsetzungspartner für Software-Hersteller ist IPG AG in den Marktregionen Schweiz, Deutschland und Österreich in Winterthur, Hamburg und Wien ansässig. Weitere Informationen zu IPG AG finden Sie auf Seite 18