Suchen

Identitäts- und Zugriffs-Management Schritt für Schritt - Teil 4 Identity Federation: SAML-Federation-Techniken für externe Nutzer

Autor / Redakteur: Ralf Fabian, Senior Consultant Technical Sales , CA Deutschland GmbH / Peter Schmitz

Angesichts der wachsenden IT-Durchdringung der heutigen Geschäftswelt ist die Öffnung gegenüber Externen beinahe schon Normalität. Kunden, Partner und Mitarbeiter erwarten, dass sie jederzeit und überall auf wichtige Anwendungen, Informationen und Services zugreifen können. Die Öffnung nach außen zieht zugleich erhebliche Sicherheits-, Management- und Compliance-Herausforderungen nach sich. Welche Gefahr in einem unautorisierten Zugriff oder im Erschleichen einer Identität lauern, lässt sich leicht ausmalen.

Firmen zum Thema

Mitarbeiter und Partner erwarten jederzeit und überall auf Unternehmensdaten und Services zugreifen können. Federation-Techniken sind dafür ein sicherer Weg.
Mitarbeiter und Partner erwarten jederzeit und überall auf Unternehmensdaten und Services zugreifen können. Federation-Techniken sind dafür ein sicherer Weg.
( Archiv: Vogel Business Media )

Haben Sie schon einmal ein KFZ ge- oder verliehen? Dann sind Ihnen die grundlegenden Prinzipien der Federation wohl vertraut. Mit der Schlüsselübergabe wird einer fremden Person Zugang und Nutzungsmöglichkeit interner Ressourcen eingeräumt. Im Unternehmensumfeld ist dieser Prozeß allerdings weitaus komplexer und problemanfälliger.

Sicherheitsarchitekten sind gefordert, die Aspekte Vertraulichkeit, Integrität, Autorisierung und Authentizität bzw. Authentifizierung intern und extern zu realisieren. Sie müssen mit Hilfe entsprechender Sicherheitstechniken die Vertrauensbeziehungen dynamisch aufbauen und wieder lösen – sowohl innerhalb der Unternehmensorganisation als auch mit Partnern und Lieferanten.

Bildergalerie

Identity Federation als zuverlässiges Verfahren zur Kontolle der Identitäten

Identity Federation (Identitätsverbund), wie es CA Technologies mit den föderalen Sicherheitsdiensten des CA Federation Manager unterstützt, stellt hierzu die Techniken und Verfahren bereit, um eine zuverlässige Authentifizierung, Vergabe und Kontrolle der Zugriffsrechte zwischen den Systemen und Ressourcen über verschiedene Sicherheitsbereiche (Domänen) hinweg zu koordinieren. Der anfordernde Benutzer muss nur einmal seine Identität belegen.

Wird die Autorisierung bestätigt, hält sie automatisch den Berechtigungsnachweis – quasi den „Schlüssel“ – in der Hand, die „fremden“ Ressourcen nutzen zu dürfen. Dabei muss die Federation-Lösung alle Kooperationsformen abbilden können, die im realen Wirtschaftsleben geschlossen werden. Zu guter Letzt muss gewährleistet sein, dass die User-Sitzung nach Transaktionsende auf allen beteiligten internen und externen Systemen ordnungsgemäß terminiert wird.

Um im Bild zu bleiben: Es darf nicht der Schlüssel im Zündschloss vergessen werden, wenn der Fahrer am Ziel angekommen ist. Ansonsten könnte ja ein Unberechtigter die Gelegenheit zur Spritztour nutzen.

Inhalt

  • Seite 1: SAML-Federation-Techniken für externe Nutzer
  • Seite 2: Identity Federation setzt Planung voraus
  • Seite 3: SAML als universaler Web Single Sign On

Identity Federation setzt Planung voraus

Die Einrichtung einer Identity Federation setzt einige Überlegungen zur Technik und Organisation voraus. Dazu zählt zum einen ein gemeinsames Verständnis zum Umgang mit Identitäten, Rollen und Benutzerkonten. Zum anderen muss Einvernehmen darüber bestehen zu den Authentifizierungs- und Berechtigungsattributen.

Im Groben verwaltet ein Identity-Provider (Identitätsanbieter, IdP) als vertrauenswürdige Komponente Authentifizierungsattribute und stellt Berechtigungen bereit. Konsument dieser Identitätsinformationen ist die angeforderte Ressource einer Domäne (Service-Provider, SP) im Verbund, die den Nachweis zu Rollen und Gruppenzugehörigkeit akzeptiert als „Schlüssel“ zur Nutzung der gewünschten Systeme bzw. Ressourcen. Und natürlich muss der Austausch auf standardisierten Pfaden erfolgen.

In diesem Kontext ist weiterhin der wichtigste Standard die SAMLSecurity Assertion Markup Language (SAML), wenngleich im Rahmen der WS Security-Anstrengungen auch im Rahmen von Web Service-Szenarien Federation-Techniken spezifiziert werden. Das Gute ist, dass beide Standards miteinander „können“ und SAML als Berechtigungs-„Token“ der WS Security genutzt werden darf.

Security Assertion Markup Language (SAML) als Schlüssel-Standard

SAML wurde vor rund neun Jahren auf Initiative einer Abteilung von CA Technologies im Verbund mit anderen Unternehmen bei OASIS (Organization for the Advancement of Structured Information Standards) „geboren“. Hinter der Spezifikation verbirgt sich ein offenes Rahmenwerk auf Anwendungsebene zur Freigabe von Sicherheitsinformationen unter Verwendung von XML-Dokumenten. Die grundlegenden „Bausteine“ hier Assertions, Protokolle, Bindings und Profile. In den Assertions werden Informationen zu Authentifizierung und Autorisierung –quasi die Zugangsschlüssel – verwaltet.

Das Protokoll definiert, wie SAML-Assertions angefordert und ausgetauscht werden. Bindings regeln den Nachrichtenverkehr über Standard-Transportprotokolle. In Profilen wiederum wird das Zusammenspiel dieser Komponenten festgelegt. Hierzu zählen in der aktuellen Version 2.0 eine Reihe diverser Client-Zugänge (Web Browser oder andere Systeme).

Des Weiteren ermöglicht die Verwaltung so genannter Name Identifier die anonymisierte Kopplung bestehender Nutzer- oder Gruppenkonten, damit der anfordernde SP keine Rückschlüsse auf Zugangschlüssel beim Identitätsanbieter oder anderen Service-Providern ziehen kann. Das Logout-Profil dient in übergreifenden Nutzersitzungen für ein sicheres Abmelden bei allen beteiligten Anwendungen (Service Providern). In der Version 2.0 wird zudem eine WAYF (Where Are You From)-Funktion definiert. Damit kann sich ein Nutzer direkt beim Service-Provider anmelden, der den zugeordneten Identity Provider identifiziert. Zuvor musste die Anmeldung ausschließlich beim IdP erfolgen.

Inhalt

  • Seite 1: SAML-Federation-Techniken für externe Nutzer
  • Seite 2: Identity Federation setzt Planung voraus
  • Seite 3: SAML als universaler Web Single Sign On

SAML als universaler Web Single Sign On

SAML schlüpft heute häufig in die Rolle eines universalen Single Sign On (SSO) für Browser-basierenden Zugriff auf Anwendungen in fremden Sicherheitszonen. Dabei werden mit dem Post- und Artifact-Profil zwei unterschiedliche Zugangswege (siehe Kasten) geboten.

Der Hauptunterschied zwischen beiden Verfahren ist, dass im Post-Fall die Assertion vom IdP über den Browser an den Service-Provider weitergeleitet wird. Dagegen wird im Artifact-Profil „nur“ eine Referenz bzw. ein Zeiger auf das Artifact transportiert. Um im Bilde zu bleiben, erhält der Nutzer im erstgenannten Falle den Schlüssel, während im zweiten Profil „nur“ ein „Zettel“, mit der Bestätigung der Berechtigung, übermittelt wird.

Gemeinsam ist beiden Fällen, dass der Nutzer im Anschluss „fahren darf“ –also die angeforderte Ressource nutzen darf. Allerdings impliziert die jeweilige Profilwahl spezifische Anforderungen in der Infrastrukturgestaltung.

Im Falle des im Grunde einfacher klingenden Post-Szenarios werden über den Browser größere Datenmengen „gepostet“, da Nachrichten signiert werden müssen. Dabei muss der Browser darauf vorbereitet sein, Java-Skripte ausführen zu dürfen. Das Artifact-Profil verlangt hingegen eine eigene Verbindung zwischen der Prüfinstanz (IdP) und dem Service zu schalten. Dieser Kanal muss dann zumindest auf Transportebene (SSL) gesichert sein, da die Assertions unverschlüsselt ausgetauscht werden. Es steht zudem frei, die Assertions ebenfalls zu signieren, um einen zusätzlichen Schutz zu erlangen.

Allein die Wahl des SSO-Profils im Rahmen der SAML-Spezifikation bedingt eine unterschiedliche Gestaltung der Sicherheits-Infrastruktur. Das gilt für die oben erwähnten weiterreichenden Profile nicht minder. SAML selbst behandelt auch nur den abgegrenzten Bereich im gesamten Sicherheitskontext. Es werden Informationen zur Authentifizierung und Autorisierung sowie zur Identität unabhängig von der Anwendung transferiert. Wie diese Informationen zustande kommen, ist nicht vorgegeben.

Organisatorische Aspekte dürfen neben der Technik nicht vergessen werden

Ebenso wenig befasst sich der OASIS-Standard mit dem Provisioning/De-Provisioning von Nutzerkonten in den Anwendungen bzw. Services oder der tatsächlichen Autorisierung von Benutzern zu Beginn einer Sitzung. Das ist allerdings nicht zwingend ein Nachteil, da die für diese Aufgaben bekannten Techniken und Standards problemlos mit SAML kooperieren. Darüber hinaus hält eine Lösung wie CA Federation Manager eine Agenten-Komponente vor. Hiermit sind Geschäftspartner in der Lage, auch ohne eine vollständige SAML-Assertion den Zugangsschlüssel zu verarbeiten (siehe Kasten).

Neben der technischen Basis dürfen die organisatorischen und rechtlichen Aspekte nicht vernachlässigt werden. Denn eine Föderation impliziert, dass die Partner zumindest teilweise von den Sicherheitssystemen und Praktiken des jeweils anderen abhängig sind. Die Anforderungen und die Handhabung der Haftpflicht, die Maßnahmen im Falle einer tatsächlichen Sicherheitsverletzung bzw. die Kontrollmöglichkeiten oder die Handhabung von Problemfällen müssen vertraglich festgehalten werden.

Wer sich ein KFZ leiht, erwartet ja ebenfalls, dass technisch alles in Ordnung ist und der notwendige Versicherungsschutz vorhanden ist. Und der „Verleiher“ darf zu Recht davon ausgehen, dass er sein Fahrzeug wohl behalten zurückerhält und im Schadensfalle die Regelung eindeutig ist.

Inhalt

  • Seite 1: SAML-Federation-Techniken für externe Nutzer
  • Seite 2: Identity Federation setzt Planung voraus
  • Seite 3: SAML als universaler Web Single Sign On

(ID:2046795)