Eine Vielzahl von Benutzerkennungen und Zugriffsberechtigungen sind nicht nur für jeden einzelnen Anwender lästig und fehleranfällig, sie behindern auch einen reibungslosen und effizienten Prozessablauf bei komplexen Transaktionen über verschiedene Sicherheits- oder Organisationsbereiche hinweg. Weitaus hilfreicher wäre es, die Systeme der in einem föderativen Szenario miteinander assoziierten Firmen zu integrieren, sodass alle Partner die Sicherheits- und Berechtigungsinformationen auf definierte und kontrollierte Weise gemeinsam nutzen – ganz analog zur ebenfalls auf gegenseitigem Vertrauen beruhenden Geschäftsbeziehung.
Die Freigabe digitaler "Identitäten" mit dem Ziel, Anwendungen in verschiedenen Sicherheitsdomänen das Arbeiten miteinander zu ermöglichen, regelt Identity Federation (Identitätsföderation). Als eine Art überbetriebliches Single-Sign-on liefert sie Unternehmen die technische Grundlage, verschiedene Sicherheitsdomänen zusammenzuschließen, um Benutzerkennungen und Zugriffsberechtigungen auszutauschen. Die Identitätsföderation ermöglicht es Benutzern und Anwendungen mit autonomen internen Geschäftseinheiten, externen Geschäftspartnern und Drittanbietern so nahtlos zusammenzuarbeiten, als ob diese Teil derselben Sicherheitsdomäne wären, obgleich die Domänen in Wirklichkeit weitgehend unabhängig voneinander bleiben.
Unternehmen, die Teil einer Identitätsföderation sind, bauen hierzu vertrauenswürdige Beziehungen untereinander auf. Zu diesem Zweck geben sie "Sicherheitstickets" an ihre Benutzer aus, die von den darauf vertrauenden Partnern verarbeitet werden können. Föderationsstandards laufen im Wesentlichen auf eine Definition dieser Tickets hinaus, definieren also deren Struktur und Inhalt, die Art der Weitergabe, Verwaltung und Validierung sowie die Frage, welche Services sie ermöglichen können.
Identitätsföderationen können in zwei grundlegenden, eng verwandten Formen – browserbasiert oder dokumentenbasiert – implementiert werden. Der Schwerpunkt der browserbasierten Föderationsmethode (vgl. Beispiel im Kasten) liegt auf der Unterstützung von Live-Benutzern, die über Standard-Internet-Browser auf Web-Anwendungen oder -Services zugreifen. In diesem Fall ermöglicht die Föderation einem authentifizierten Benutzer von einer Sicherheitsdomäne im Web zu einer anderen zu wechseln, ohne erneut seine Zugangsdaten eingeben zu müssen.
----------Anfang Textkasten----------
Browserbasierte Szenarien ermöglichen im Prinzip Endbenutzern mithilfe von Identitätsinformationen ein Single-Sign-on über die Grenzen partnerschaftlich verbundener Unternehmen (Föderation) hinweg. Bei einer Föderation mit Kontoverknüpfung beauftragt beispielsweise die Firma example.com ihren Partner unserekasse.com mit der Verwaltung der Krankenversicherungsleistungen ihrer Mitarbeiter. Meldet sich eine Mitarbeiterin beim Mitarbeiterportal arbeitnehmer.example.com an und klickt auf die Verknüpfung zu ihren Versicherungsleistungen , so gelangt sie dadurch ohne Weiteres auf die Website von unserekasse.com mit all ihren persönlichen Versicherungsinformationen, ohne sich dort explizit anmelden zu müssen. Als Teile der Föderation werden die Konten zum Zeitpunkt der Browser-Umleitung automatisch verknüpft.
Ein weiteres browserbasiertes Szenario stellt die rollenbasierte Föderation dar: Kauft etwa example.com Teile von einem Partnerunternehmen MeinLieferant.com, so kann sich ein Techniker des Unternehmens am Mitarbeiterportal authentifizieren und per Verknüpfung direkt auf Informationen des Zulieferers zugreifen. In diesem Szenario ist es nicht erforderlich, dass MeinLieferant.com Benutzeridentitäten für sämtliche Mitarbeiter verwaltet: Er muss jedoch weiterhin den Zugriff auf vertrauliche Teile der eigenen Website kontrollieren. Dazu verwaltet der Partner eine begrenzte Anzahl von Profil-Identitäten, die Rollen (Mitarbeiterfunktionen) der Benutzer von example.com zugeordnet sind. Abhängig von der Rolle werden dann ausgewählte Benutzerattribute von example.com unter Anwendung der Föderationsstandards gesichert an MeinLieferant.com geschickt.
----------Ende Textkasten----------
Dokumentenbasierte Föderationen beruhen hingegen auf XML-Files (vgl. zweiten Kasten), die unter Nutzung von Web-Service-Standards zwischen zwei Sicherheitsdomänen ausgetauscht werden. Dabei ist es gleich, ob die Aktionen von einem Live-Benutzer über eine Client-Anwendung oder von einer Anwendung selbst ausgelöst werden, die ohne manuellen Eingriff arbeitet. Notwendig ist in jedem Fall die Definition von Strukturen der XML-Dokumente, Speicherorte und Zugangsdaten, um die Serviceanforderungen von Web-Services einer Partnerorganisation zu ermöglichen.
----------Anfang Textkasten----------
Dokumentenbasierte Föderationen laufen über verkettete Web-Services ab – als so genannte Web Service Flows. Unterhält beispielsweise example.com eine Kaufvereinbarung mit Unserhersteller.com und dieser eine Geschäftsbeziehung mit MeinLieferant.com, so könnte sich ein Nutzer per Benutzernamen und Passwort bei seiner Beschaffungsanwendung anmelden und durch bloßen Klick auf "Unserhersteller" ein Bestellformular ausfüllen und absenden. Die Beschaffungsanwendung in einem föderativen System wandelt dann das HTML-Formular in ein XML/SOAP-Dokument um, das in den Envelope Body einer XML-Nachricht eingefügt wird. Anschließend fügt die Beschaffungsanwendung die Zugangsdaten des Endbenutzers zusammen mit der Organisationsidentität von example.com in den Envelope Header der Nachricht ein und sendet diese an den Beschaffungs-Web-Service von Unserhersteller.com. Dessen Sicherheitsservice authentifiziert die eingehende Nachricht und verarbeitet die Anfrage.
Nach Abschluss dieses Prozesses sendet der Beschaffungs-Web-Service in einer weiteren XML/SOAP-Nachricht eine Anfrage an MeinLieferant.com. Diese Nachricht enthält ein Security-Token von Unserhersteller.com im Envelope Header und im Envelope Body die Liste der zu liefernden Teile sowie die Lieferinformationen des Endbenutzers. Der Liefer-Web-Service authentifiziert die Anfrage und verarbeitet den Auftrag. Umgesetzt wird ein solches Szenario nach dem so genannten Sender-Voucher-Modell, wobei der Intermediär (Voucher-Instanz) für Autorisierung und Authentifizierung des WS-Security SAML-Token-Profile und der SAML-Assertion zuständig ist.
Eine andere Spielart dokumentenbasierter Föderation ist ein allgemeiner Token-Dienst (Holder-of-Key Scenario): Dabei signiert die Anwendung des Nutzers dessen Anfrage und schickt das Anwenderpasswort (bzw. Ticket) zu einem vertrauenswürdigen Token-Service – in unserem Beispiel an Unserhersteller.com. Nach erfolgreicher Authentifizierung generiert dieser die SAML-Assertion für den Nutzer, signiert diese und schickt sie als SAML-Token an die Anwendung des Nutzers zurück. Diese fügt ohne weiteren Nutzereingriff das SAML-Token in einen WS-Security-Header als Teil eines SOAP-Requests ein und schickt diesen an den Web-Service von MeinLieferant.com. Dort werden die SAML-Assertion-Signatur (Token) und die Signatur des Nutzers im Inhalt der Nachricht daraufhin überprüft, ob beispielsweise das Token tatsächlich von einem "Trusted Partner" ausgegeben wurde und der signierende Nutzer im Nutzerverzeichnis existiert.
----------Ende Textkasten----------
Unabhängig von der jeweiligen Ausprägung zählen zu den grundsätzlichen Aufgaben einer Föderation in erster Linie die Beschreibung von Identitätsdaten (vulgo: Security-Tokens), Autorisierung und Authentifizierung, Attributfreigabe, Protokolle für den Austausch von Security-Tokens sowie Methoden für Vertrauensbeziehungen. Für diese unterschiedlichen Aspekte existieren bereits eine Reihe zum Teil konkurrierender Standards und Spezifikationsentwürfe, die im Folgenden vorgestellt werden.
![[Illustration]](06-6-038-1.jpg)
Abbildung 1: Standards und Protokolle im Zusammenspiel – während SSL einen sicheren Tunnel für die geschützte Übertragung eines XML-Dokuments an einen Web-Service-Provider bildet, können XML Encryption und XML Signature bestimmte Teile eines Dokuments schützen (z. B. für SOAP-Nachrichten).
Die bekannten Web-Sicherheitsstandards für die Übertragungsmedien (SSL bzw. HTTPS) tragen übrigens wenig zur Unterstützung einer Föderation bei, da sie nur den Transport(weg) sichern, nicht aber die Nachrichten selbst. Neben ungenügenden Ausdrucksmitteln zur Identität des Aufrufers eines Web-Service oder der Session-Dauer ist es nicht zuletzt die ausschließliche Behandlung von Punkt-zu-Punkt-Verbindungen zwischen zwei direkt kommunizierenden Beteiligten (Client und Server), die dem SSL-Einsatz für mehrstufige Web-Services widerspricht.
Eine Möglichkeit, Vertraulichkeit, Integrität und Authentizität von XML-Inhalten auf Anwendungsebene zu verwirklichen, stellen XML Encryption und XML Signature dar (RFC 3275 – vgl. <kes> 2001#3, S. 20). Erstere liefert eine Syntax für die selektive Verschlüsselung und Dekodierung von XML-Dokumenten oder -Dokumentenblöcken, anhand der ein Empfänger erkennt, was verschlüsselt ist, und so das Quelldokument wiederherstellen kann. XML Signature ermöglicht Integrität und Urheberschaft verbindlich zu validieren (non-repudiation). Autorisierung und Authentifizierung im Rahmen einer Föderation müssen jedoch von den darauf aufsetzenden Schichten umgesetzt werden, die innerhalb eines XML-Dokuments die sicherheitsrelevanten Informationen festlegen, diese beispielsweise als Security-Ticket ausdrücken und so die Zugangskontrolle bei XML-Content regeln (vgl. Abb. 1).
Im Januar 2001 wurde das OASIS Security Services Technical Committee (SSTC, [1]) von einer Abteilung von CA im Verbund mit anderen Unternehmen ins Leben gerufen, um einen geeigneten Sicherheitsmechanismus für Web-Services zu entwickeln. Mit der Security Assertion Markup Language (SAML) forciert das Gremium die Spezifikation eines offenen Rahmenwerks auf Anwendungsebene zur Freigabe von Sicherheitsinformationen unter Verwendung von XML-Dokumenten. Die SAML-Spezifikation umfasst in der Hauptsache Assertions, Protokolle, Bindung und Profile.
In Assertions werden Informationen zu Authentifizierung, Autorisierung sowie weitere Session-Attribute hinterlegt: Authentication Assertions bestätigen, dass bestimmte Benutzer auf geschützte Ressourcen zugreifen dürfen. Attribute Assertions bestätigen, dass einem Benutzer oder einem Web- Service bestimmte statische Attribute (Rollen, Funktionen) oder dynamische Attribute (Kontostand etc.) zugeordnet sind. Authorisation Decision Assertions stellen fest, ob und wie auf eine spezifische Ressource zugegriffen werden darf.
Sämtliche SAML Assertions enthalten die folgenden allgemeinen Informationen:
Die Assertions werden von so genannten Autoritäten (Assertion Issuing Authorities) ausgegeben; in der Praxis können alle drei Arten von Assertions von einer einzigen Autorität erzeugt werden. Das SAML-Protokoll definiert, wie SAML-Assertions angefordert und übermittelt werden: Die Anforderung (Request) wird von einem SAML-fähigen Client gestartet, die Antwort erfolgt von einem Sicherheitsdienst aus. Ein SAML-Request kann Anfragen zu Authentifizierung, Attribute und Zugriffsentscheidungen enthalten – all diese Requests werden von einem SAML-Response erwidert, der ein oder mehrere Assertions umfasst.
SAML-Bindings legen fest, wie Request-Response-Nachrichten über Standard-Übertragungsprotokolle abgebildet werden: SAML definiert ein SOAP-over-HTTP-Binding (SOAP: Simple Object Access Protocol), lässt grundsätzlich aber andere Bindings zu. Die SAML-Profile spezifizieren, wie Assertions in ein Nachrichten-Framework oder ein Protokoll eingebunden und wieder extrahiert werden. SAML definiert als Part der WS-Security-Spezifikation (s. u.) ein WS-Security-Profil sowie ein Web-Browser-Profil mit Pull- und Push-Methode. Beim Pull übermittelt der Browser ein so genanntes SAML-Artefakt (Referenz zu einer Assertion) auf einem URL-Query-String; die korrespondierende Assertion wird im Anschluss mittels SOAP-over-HTTP-Binding von der Zielseite "gezogen". Im Rahmen der Push-Methode wird dagegen die Assertion direkt in einem HTML-Formular an den Empfänger übertragen.
Mit den beschriebenen Techniken ist SAML grundsätzlich in der Lage, die drei Anwendungsfälle Single-Sign-on (SSO), verkettete Transaktionen sowie Autorisierungs-Services abzudecken. Für die Einschätzung von SAML als wahrscheinlich wichtigstem der gegenwärtig unterstützten und implementierten Föderationsstandards hat die Übernahme der im März 2005 verabschiedeten Spezifikation SAML 2.0 durch das Liberty Alliance Project [2] entscheidenden Anteil.
<saml:Assertion AssertionID="10.255.1.3.1034108172377" IssueInstant="2002-10-08T20:16:12.377Z"
Issuer="TransactionMinderSAMLIssuer" MajorVersion="1" MinorVersion="0" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2002-10-08T20:16:12.307Z" NotOnOrAfter="2002-1008T22:16:12.307Z"/>
<saml:AuthenticationStatement AuthenticationInstant="2002-10-08T20:16:12.307Z" AuthenticationMethod="urn:oasis:names:tc:SAML…">
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0…" NameQualifier="Domain Name">
christofer muhm
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>http://www…/>
<saml:SubjectConfirmationData>
R1VD8fkkvlrhp…
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
Abbildung 2: SAML-Assertions transporieren Informationen zu Authentifizierung, Autorisierung sowie weiteren Session-Attributen.
Die Industrieorganisation Liberty Alliance, die aktuell mehr als 150 Mitglieder zählt, startete im September 2001 – ihr Ziel: Spezifikationen für die Identitätsföderation. Diese Arbeit treibt man in drei aufeinander aufbauenden Phasen voran.
In der ersten Phase beschäftigte sich die Organisation mit dem Aufbau des Liberty Identity Federation Framework (ID-FF-Modul), das als Fundament der gesamten Liberty-Architektur dient. Eine ID-FF-Basisumgebung besteht mindestens aus drei Teilen: einem Identity-Provider (beispielsweise einem Telekommunikationsunternehmen), einem Service-Provider (beispielsweise einem Händler) und einem Benutzeragenten (Thin-Client wie Standardbrowser oder einem Liberty-fähigen Client bzw. Proxy, etwa Mobiltelefon). Im Rahmen der ID-FF erstellt der Identity-Provider nach erfolgreicher Authentifizierung des so genannten Prinzipals (Person) eine SAML-Assertion einschließlich Authentifizierungs-Nachricht, die eine Beschreibung des Sicherheitskontexts des Prinzipals zusammen mit einer Namensidentifikation enthält.
Wie bereits angedeutet führt Liberty den ID-FF-Teil ihrer Spezifikation nicht länger unabhängig weiter, sondern hat ihn durch SAML 2.0 ersetzt. Ihre Arbeit konzentriert die Allianz stattdessen auf die beiden oberen Ebenen der Liberty-Architektur: Das Identity Web Service Framework (ID-WSF) und die Identity Service Interface Specification (ID-SIS). Während ID-FF beziehungsweise SAML 2.0 primär die grundsätzlichen Aufgaben zur Realisierung eines föderativen, vernetzten Identitätsmanagement behandeln, stellt ID-WSF für solche Umgebungen ein Framework für identitätsbasierte Web-Services dar. ID-SIS, das auf ID-FF und ID-WSF aufsetzt, umfasst Komponenten, die selbst als Web-Services agieren: Sie werden als XML-Schemata definiert und per Web Services Description Language (WSDL) beschrieben.
Nicht zuletzt wurden die so genannten Liberty People Services entwickelt, um es Individuen zu ermöglichen, Online-Beziehungen einfach zu speichern, zu pflegen und zu kategorisieren. Web-Service-Anwendungen für soziale Kontakte können so Informationen auf der Basis der Zustimmung eines Anwenders zur Steuerung der Privatsphäre im föderativen sozialen Netzwerk wirksam nutzen.
Die Veröffentlichungen der Liberty People Service untermauern, dass Liberty primär die föderative Behandlung der "Identitäten" von Einzelpersonen im Fokus hat. Die Spezifikation von Web Services Security (WS Sec) wurde hingegen ähnlich wie SAML von Beginn an mit Blick auf überbetriebliche Geschäftsszenarien forciert. WS-Security geht ursprünglich auf eine Initiative von IBM, Microsoft und Verisign zurück (vgl. [3]). Sie wurde aber 2002 der OASIS zur weiteren Ausarbeitung übergeben und wird fortan wie SAML vom OASIS WSS TC verwaltet.
Der Standard definiert als Erweiterung von SOAP unterschiedliche Mechanismen, um Integrität, Vertraulichkeit und Authentifizierung von XML/SOAP-Nachrichten zu ermöglichen. Dazu setzt WS-Security die W3C-Standards XML Signature und XML Encryption ein. Weiterhin stellt es Profile bereit, um festzulegen wie verschiedene Typen von binären und XML-basierenden Security-Tokens in WS-Security-Header eingefügt werden. Bei den unterstützten Token-Profilen kann es sich laut Version 1.1 (Feb. 2006) um Kerberos-Tickets, X.509-Zertifikate, SAML-Assertions sowie Right Expression Language-Token (XrML-Extensiable Rights Markup Language-Dokumente für digitale Rechte) oder das XML Common Biometric Format (XCBF) handeln.
WS-Security lässt sich am einfachsten als eine Art Behälter für sicherheitsrelevante Informationen bezeichnen, der mehrere Typen von Sicherheits-Objekten umfasst und festlegt, wo genau in einer Web-Service-Schnittstellendefinition die Sicherheitsinformationen wie Signatur- und Verschlüsselungs-Header untergebracht sind. Das WS-Security-Profil für SAML basiert beispielsweise auf einer einzigen Interaktion zwischen Sender und Empfänger: Der Sender (Nutzer des Web-Services) bekommt eine oder mehrere SAML-Assertions oder Assertion Identifiers, mit denen er seine SOAP-Nachricht ergänzt (mittels WS-Security-Header) und anschließend die Nachricht an den Empfänger (Web-Service-Provider) verschickt. Dort werden Assertions oder Assertion Identifier verarbeitet und bei erfolgreicher Entschlüsselung hat sich der Sender dadurch authentifiziert – die Nutzung des Web-Services wird freigegeben.
WS-Security bildet zusammen mit XML Signature/Encryption das grundlegende Fundament für eine Ende-zu-Ende-Sicherheit von SOAP-Kommunikation – unabhängig vom Transportkanal. Die Spezifikation beschreibt jedoch nur, wie sicherheitsrelevante Informationen eingebunden sind und wie auf diese verwiesen wird, aber nicht auf welche Weise Security Token angefordert werden. Weitere, auf WS-Security aufbauende Spezifikationen sollen diese konzeptionellen Lücken schließen: Mit WS-Trust, WS-SecureConversation und WS-SecurityPolicy befinden sich aktuell drei Entwürfe in Arbeit, deren Verabschiedung das WSS TC im Juli kommenden Jahres abschließen will.
Die Web Services Trust Language (kurz WS-Trust) soll Vertrauensbeziehungen durch Sicherheits-Tokens erzeugen: Es erweitert WS-Security um einen Service zum Anfordern, Erstellen und Austausch der Tokens. Die Ausgabe, Prüfung, Erneuerung und Entwertung von Security-Tokens verantwortet der zentrale Security Token Service (STS). Das Framework beschränkt sich auf die beiden Nachrichtentypen Request Security Token (RST) und Request Security Token Response (RSTR). Benutzerspezifische Regelwerke des STS definieren des Weiteren, welche Authentifizierungsmethode in der SAML-Assertion gesetzt werden soll. Der STS agiert damit als universeller Token-Dienst einer von allen Beteiligten als vertrauenswürdig erachteten Instanz. Damit verlagert WS-Trust die Prüf- und Transformationslogik von den kommunizierenden Einheiten in eine zentrale Komponente und macht Service-Nachfrager und -Provider weitgehend unabhängig von sicherheitstechnischen Änderungen.
![[Illustration]](06-6-038-3.jpg)
Abbildung 3: Das Zusammenspiel des WS*-"Baukasten" – bis auf WS-Federation sind alle Spezifikationen als XML-Schemata definiert
WS-SecureConversation dient der sicheren Kommunikation über mehrere Web-Services-Aufrufe, indem es einen Sicherheitskontext herstellt: Mithilfe eines eindeutigen Identifikators (Sicherheitskontext-URI), der den Dialogparteien bekannt ist, wird durch die Spezifikation die Zustandslosigkeit von WS-Security beendet. Von Vorteil ist ein solches Konzept immer dann, wenn mehrere verschlüsselte Nachrichten an den gleichen Empfänger gesendet werden müssen. Im Rahmen von WS-Security muss man dabei für jede Nachricht einen neuen temporären Schlüssel mit dem öffentlichen Schlüssel des Adressaten verschlüsseln. Bei WS-SecureConversation muss dieser aufwändige Prozess nur einmal durchgeführt werden und ein neu eingeführtes Security Context Token (SCT) stellt den Sicherheitskontext her.
WS-SecurityPolicy knüpft an das von IBM, Microsoft, BEA und SAP veröffentlichten WS-Policy-Framework an. Während dieses allgemein Anforderungen, Präferenzen und Fähigkeiten eines Web-Services beschreibt, liefert WS-SecurityPolicy das erforderliche Vokabular zur Beschreibung der Sicherheitsanforderungen. Damit lassen sich in den zugehörigen Assertions entsprechende Bedingungen verfassen (was und wie sollen Teile der SOAP-Nachrichten verschlüsselt werden, welche Token-Formate sind zulässig etc.). Ein Client kann aus der Sammlung dieser Richtlinien die für ihn passendste Zusammenstellung heraussuchen, um einen Request zu konfigurieren.
Ein großer Nutznießer von WS-Trust und WS-SecurityPolicy ist WS-Federation (vgl. Abb. 3). Im Unterschied zu den bislang beschriebenen Standards steht hinter der Web Services Federation Language (WS-Federation) jedoch eine Industrieinitiative: Die ursprüngliche Spezifikation wurde gemeinsam von IBM, Microsoft, BEA, Verisign und RSA erarbeitet und nicht von einem unabhängigen Gremium verwaltet – hier gibt es keinen freien Zugriff auf die Inhalte. Die Beteiligten streben mit WS-Federation den Zusammenschluss mehrerer Vertrauenszonen an, indem Attribute, Authentifizierung und Autorisation vereinigt werden. Wenn ein Partner Kerberos für das Identitätsmanagement nutzt und der andere X.509, so ist es möglich eine dritte vertrauenswürdige Instanz einzuschalten, die eine Cross-Zertifizierung vornimmt.
Ein solches Szenario ist zwar grundsätzlich bereits mit WS-Security und WS-Trust umsetzbar, um etwa ein SAML-Token in ein Kerberos-Ticket umzuwandeln. Der "Nicht-Standard" WS-Federation ist aber dennoch von Interesse, da Microsoft hier mit dem Produkt Active Directory Federation Service (ADFS) aktiv ist und das Passive Requester Profile (browserbasierte Föderation) implementiert hat.
Aus Gründen der Vollständigkeit sollen an dieser Stelle noch zwei weitere Spezifikationen aus dem "Baukasten" der WS*-Spezifikationen angeführt werden: WS-Authorization und WS-Privacy. Mit WS-Authorization soll die Autorisierungsüberprüfung anhand weiterer, feinerer Kritierien (Uhrzeit etc.) durch einen vergleichbaren Dienst wie dem Security Token Service durchgeführt werden. WS-Privacy, Teil des ursprünglich von Microsoft und IBM veröffentlichten Sicherheitsfahrplans, behandelt hingegen datenschutzrelevante Belange. Anders als die bisher angesprochenen Standards befinden sich beide noch in einer sehr frühen Spezifikationsphase.
Die Beschreibungen der einzelnen Standardisierungsinitiativen und -spezifikationen verdeutlichen, dass es sich bei Identitätsföderation um ein hochkomplexes Thema handelt. Aktuell existiert kein einzelner Standard, der alle eingangs aufgezählten Föderationsanforderungen erfüllt. Eine Kombination der Standards kann indes die Grundlage für eine Identity-Federation-Unterstützung unterschiedlicher Anforderungen bilden. In erster Linie unterstützen die aktuell verfügbaren Spezifikationen SAML, Liberty und WS-Security Szenarien der browserbasierten Identitätsföderation. Mit dem weiteren Ausbau der WS-Security-Spezifikation, insbesondere dem kommenden WS-Trust-Standard, deutet sich jedoch ein Durchbruch für dokumentenbasierte Föderation im Rahmen vernetzter Web-Services an.
Zu beachten ist: Industriestandards und Spezifikationen tragen zwar erheblich dazu bei, aber um eine erfolgreiche Zusammenarbeit der Sicherheitsinfrastrukturen verschiedener Organisationen zu etablieren, bedarf es deutlich mehr – Technik allein kann nicht die einer Föderation innewohnenden geschäftlichen Herausforderungen bewältigen.
Sebastian Rohr ist Business Technologist bei CA in Darmstadt.
![[externer Link]](../../../../images/link.gif)
www.oasis-open.org/committees/tc_home.php?wg_abbrev=security www.projectliberty.org/resources/specifications.php http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2006#6, Seite 38
| 