Portalverbund. Whitepaper. PVWhitepaper Whitepaper. Ergebnis der AG

Transkript

1 Portalverbund Whitepaper Whitepaper PVWhitepaper Ergebnis der AG Kurzbeschreibung: Der Portalverbund ist eine Zusammenschaltung von Sicherheitsportalen, um eine dezentrale Benutzer- und Rechteverwaltung zu ermöglichen. Dabei übertragt ein Anwendungsverantwortlicher die Authentifizierung, Autorisierung und die Verwaltung der Verrechnungsdaten für Benutzer einer Teilnehmerorganisation an diese. Ein Benutzer aus der Teilnehmerorganisation braucht dadurch nur mehr an einem Portal, seinem Stammportal, registriert und verwaltet werden und kann mit einem Sign-On dennoch auf Anwendungen anderer Portale im Verbund zugreifen. Autoren: Rainer Hörbe Michael Werzowa (BMI-SUZMR) Projektteam / Arbeitsgruppe: Vorgelegt am TT.MM.JJJJ Abgelehnt von: Zur Kenntnis genommen von: Anregungen von: Angenommen von:

2 Grundlagen des Portalverbundes Funktionsprinzip Das Portalverbundsystem ermöglicht es den teilnehmenden Organisationen, wechselseitig auf gesicherte Anwendungen zuzugreifen und dabei ihre lokale Benutzerverwaltung auch für externe Anwendungen zu verwenden. Abbildung 1: Portalverbund gesicherter wechselseitiger Zugriff Betreiber von Anwendungen, die externe Benutzer zulassen, brauchen nur mehr Organisationen zu administrieren und reduzieren damit gegenüber einer Benutzerverwaltung den Aufwand um eine Größenordnung. Voraussetzung für die Delegation der Benutzerverwaltung durch den Anwendungsbetreiber ist, dass eine geeignete Vertrauensstellung hergestellt wird. Das wird durch den Beitritt zur Portalverbundvereinbarung erreicht. Die am Portalverbund teilnehmenden Organisationen betreiben 1 für ihre lokalen Netzwerk-Domänen Portale, die über das Internet 1 möglicherweise im Wege eines externen Dienstleisters PVWhitepaper.doc 2/21 Stand: :29

3 Vertrauensverhältnisse vernetzt sind. Die Anwendungen sind Web-Anwendungen, die Request-Response-Protokolle wie HTTP oder SOAP verwenden. Benutzer aus der Teilnehmer-Domain abc.gv.at verwenden die Anwendung X der Teilnehmer-Domain xyz.gv.at. (Siehe Abbildung 2) Abbildung 2: Portalverbund Verantwortung Der Anwendungsverantwortliche der Anwendung X (eine Datenanwendung im Sinne des 7(4) DSG 2000) delegiert die Funktionen Authentifizierung und Autorisierung an den Betreiber des Portals der Domäne xyz.gv.at. In diesem Zusammenhang wird die Summe der für die Anwendung X möglichen Rechte und Einschränkungen definiert. Die Portalbetreiber haben einen Verbund eingerichtet, in dem sich die Portale untereinander authentisieren können. Dafür haben Sie jeweils bilateral die "Portalverbundvereinbarung" abgeschlossen. Der Anwendungsverantwortliche hat mit der Organisation abc.gv.at eine Anwendungsvereinbarung 2 für die Anwendung X geschlossen. In der Folge beauftragt Anwendungsverantwortliche den Betreiber des Portals xyz.gv.at, dem Portal abc.gv.at die in der Nutzungsvereinbarung definierten Rechte einzuräumen. Der Portalbetreiber von abc.gv.at definiert, welchen Benutzern der Organisation abc.gv.at der Zugriff auf die Anwendung eingeräumt wird. 2 Die Anwendungsvereinbarung kann auch durch Nutzungsantrag und Zustimmung des Anwendungsbetreibers, oder eine Veröffentlichung der Nutzerklassen durch den Betreiber ersetzt werden. PVWhitepaper.doc 3/21 Stand: :29

4 Vereinbarungen Die Basis der Vertrauensverhältnisse sind Vereinbarungen, die zwischen den einzelnen Akteuren des Portalverbundes geschlossen werden. Die Akteure sind die Benutzerorganisation mit den einzelnen Benutzern, der Betreiber des Stammportals, der Betreiber des Anwendungsportals und der Verantwortliche der einzelnen Anwendung. Der Gültigkeitsbereich der einzelnen Vereinbarungen ist in Abbildung 3 zu ersehen. Abbildung 3: Portalverbund Vereinbarungen PVWhitepaper.doc 4/21 Stand: :29

5 Vorteile durch einen Portalverbund Der Einsatz von Anwendungsportalen ist eine der Komponenten des Konzepts für E-Government von Bund, Ländern und Gemeinden, da sich daraus eine Reihe von Vorteilen ergibt. Startmenü, Single Sign On, Policy Enforcement Grundsätzlich haben Portale den Nutzen, dass mehrere Anwendungen über einen Punkt adressiert werden, und der Benutzer sich nur einmal authentisieren muss. Die Richtlinien für die Zugriffe werden außerhalb der Anwendungen an einer Stelle administriert und erzwungen. Verwaltungsvereinfachung durch Single Point of Administration Wenn die redundante Verwaltung von Benutzern, ihren Rechten und Verrechnungsattributen eliminiert werden kann, ergeben sich weitere Vorteile: o Die Arbeitsabläufe für Beginn, Änderung und Beendigung von Dienstverhältnissen so wie organisatorischen Veränderungen können erheblich vereinfacht werden. o o Durch den Wegfall redundanter Benutzerdatenbanken erzielt man eine bessere Datenkonsistenz und in der Folge einen besseren Datenschutz. Benutzern erhalten rascher den Zugriff zu Anwendungen. Aus verschiedenen Gründen, wie der heterogenen IT-Struktur der Verwaltung, unterschiedlichen Anforderungen, und schließlich der geplanten Integration von Verzeichnisdiensten wurde der Ansatz eines zentralen Portals für die österreichische Verwaltung mehrheitlich verworfen. Stattdessen wurde der Portalverbund entwickelt, der die Aufteilung der Verwaltungsbenutzer auf mehrere Portale ermöglicht. Die wichtigsten Vorteile sind: o o Die Verwaltung der Benutzer wird technisch und organisatorisch bei der jeweiligen personalführenden Stelle belassen, um eine Verwaltungsvereinfachung zu erzielen. Organisationen können sich eines Portalproviders (z.b. Bundeslandes oder BRZG) bedienen, der den technischen Betrieb übernehmen kann. Die Verwendung von Anwendungsportalen für interne Anwendungen bietet weitere Synergieeffekte, weil die Benutzer und ihre Rechte an einer Stelle für interne und externe Anwendungen administriert werden. PVWhitepaper.doc 5/21 Stand: :29

6 Implementierung Portalverbund PVP 1.8 Die Basis des PVP 1.8 ist HTTP oder SOAP. Das Portalverbund-Protokoll verwendet zur Authentifizierung einen Agent-Ablauf 3 : Dabei wird das Stammportal als Proxy für Zugriffe auf Anwendungen (Anwendungsportale) verwendet. Die Protokollbindung für SOAP verwendet und erweitert die Spezifikation Web Services Security [WS-Security]. Details der Implementierung sind in [PVP 1.8] beschrieben. Das Portalverbundprotokoll unterstützt die Implementierung von Webs-Services nach den Anforderungen des Portalverbundes, der in der aktuellen Version Topologien unterstützt, wie sie an einem Beispiel in Abbildung 4 dargestellt sind. Abbildung 4: Beispiel eines Portals nach PVP Details der Ablaufformen werden im Abschnitt Technische Lösungsansätze beschrieben PVWhitepaper.doc 6/21 Stand: :29

7 Dokumentation des Portalverbundes Die Arbeitsgruppe Autorisierung hat für den Portalverbund Dokumente für folgende Bereiche erarbeitet, die allesamt in aktuellen Versionen verfügbar sind unter : Portalverbund Protokoll SecClass Portalverbund Vereinbarung PortalV-PKI PVP-Revision Technical Notes Definition der Parameter für Autorisierung, Authentifizierung und Verrechnung und Protokollbindungen an HTTP und SOAP. Spezifikation von Sicherheitsklassen, um automatisiert die erforderliche Beziehung zwischen dem Schutzbedarf der Anwendung und den Sicherheitsanforderungen des Benutzers herzustellen. Vertrag, der die Rechte und Pflichten der Teilnehmer des Portalverbunds festlegt Eine PKI für Serverzertifikate von Verwaltungsorganisationen, die vom BMI betrieben wird. Spezifikation von Anfrage und Resultat eine Anfrage für eine datenschutzrechtliche Revision. Erläuternde Dokumente zu technischen Details des Portalverbundes. PVWhitepaper.doc 7/21 Stand: :29

8 Technische Lösungsansätze Web Service Securtiy Service oriented Architecture Für die Implementierung eines Portalverbundes, wie er beispielsweise durch das PVP ermöglicht wird, sind verschiedene Technologien erforderlich, die sich derzeit erst in Standardisierungsprozessen befinden. Die beschriebenen Technologien, Standards und Standardentwürfe kommen nicht notwendigerweise alle in der Implementierung eines Portalverbundes zum Einsatz. Geeignete Literatur ist unter [SOA-Field Guide] oder [Securing Web Services] zu finden. Einer der Gründe, warum das neue Schlagwort von service oriented archtecture auf Basis von Web-Services derzeit so populär wird ist, dass SOAP das erste Mal erlaubt, das Web als universelle Middleware einzusetzen, ohne auf teure und proprietäre Lösungen angewiesen zu sein. Dies ist nicht neu und wurde beispielsweise durch das Konzept des Client/Server Computing bereits in den späten 80ern definiert, damals auf der Basis von RPC und proprietärer Middleware. Multi-Tier Programming (z.b. 3-Tier Architecture) verwendet das gleiche Prinzip. Von Verbindungssicherung zur Dokumentsicherung Mit der Verwendung von XML als Middleware ging auch eine Entwicklung eines neuen Sicherheits-Paradigmas einher, nämlich der Übergang von einem verbindungsorientierten Sicherungskonzept zu einem dokumentorientierten Ansatz, der das XML Objekt als semantische Einheit sichert und von der Übertragung und dem Wirkungsort unabhängig macht. Bedeutungsvoll sind dabei folgende Eigenschaften: Identitätsmanagement ist über Domain Grenzen hinweg möglich, was mit Identity Federation und Identity Association beschrieben wird. Die Sicherungseigenschaften (security context) bleiben an die authentifizierte Person gebunden und es wird eine rollenbasierte Zugriffskontrolle ermöglicht (RBAC, role based access control) Die Sicherungseigenschaften (security context) bleiben an die Dokumente oder Daten gebunden, auch wenn sie mehrfach Grenzen von Sicherheits- und Verwaltungsbereichen (Domains) überschreiten. In Szenarien mit hohen Transaktionszahlen ist der Ansatz z.t. aber noch zu langsam. PVP implementiert daher momentan nur Punkt zu Punkt-Sicherungen, nicht Ende-zu-Ende.. PVWhitepaper.doc 8/21 Stand: :29

9 Spezielle Anforderungen von SOAP an Vertraulichkeit und Integrität WSDL und Security SOAP muss besonders geschützt werden, da es Daten in einer allgemein verständlichen Form (als tagged text) transportiert, der leicht abgehört werden kann und von einem ungewollten Empfänger missbraucht werden kann. Durch die textliche Repräsentation mit vielen möglichen Varianten (mehr Leerzeichen, andere Zeilenumbrüche, verschiedene Kodierungen, verschiedene Tag-Schreibungen) ist außerdem die Sicherstellung einer unveränderten Übertragung relativ schwierig, jedenfalls wesentlich schwieriger, als bei binären Übertragungsformaten. Damit SOAP sicher ist, muss es auf Ebene der Anwendung Mechanismen anbieten, die etwa vergleichbar sind mit den Mechanismen, die auf IP-Ebene durch IPSec mit ESP Protokoll angeboten werden. WSDL liefert die Beschreibungen von Web-Services, vergleichbar einem Vertrag. Für die Entwickler von Services sind WSDLs wie eine Klasse zu sehen. Obwohl innerhalb von WSDL Sicherheitsdefinitionen möglich sind, sind diese relativ eingeschränkt und bleiben weit hinter dem zurück, was WS-Policy bietet. WS-Policy ist ein (zukünftiger) Standard für die Sicherheit von Webservices und wird etwa in WebSphere 6 bereits untersützt. Daher wird zukünftig sinnvollerweise WS-Policy für die Beschreibung von Web Service Security verwendet und diese im WSDL referenziert. Anforderungen an eine Authentifizierung in einer SOA In Zusammenhang mit der sogenannten Service Orientierten Architektur (Service oriented architecture, SOA), die als Prinzip hinter der Verwendung von Webservices steht, tauchten neue Anforderungen an die Verwaltung von Benutzern und Berechtigungen auf: Nicht mehr einzelne Systeme (oder Systemverbünde), an denen ich persönlich angemeldet bin und auf denen ich ein spezifisches Profil habe, sondern Services, die von unterschiedlichen unabhängigen Systemen angeboten werden, sind meine Dienstanbieter. Um nicht mit jedem dieser Services einzeln verhandeln zu müssen, (Anmeldung, Rechteüberprüfung, Anwendung, Abmeldung), ist eine Vermittlungsschicht für die Benutzerverwaltung und Rechteerteilung notwendig geworden. Dabei ergeben sich Besonderheiten für die Verwaltungsaufgaben um Benützer und Rechte in einem Netzwerk von Services: PVWhitepaper.doc 9/21 Stand: :29

10 Es muss eine Vertrauensbasis zwischen den Systemen bestehen, an denen die Benutzer angemeldet sind und den Systemen, auf denen die Services angeboten werden. Die Anwendungen müssen eine Übereinkunft über die Vermittlung von Identitätsinformationen und Berechtigungen haben, um die Benutzerinformationen von einem System auf einem anderen gültig werden zu lassen. Die Vermittlung dieser Berechtigungen muss auf eine sichere Weise geschehen: zuverlässig und geschützt, und zwar nicht nur auf Netzwerkebene (von Endsystem zu Endsystem), sondern auf der Ebene der Anwendung. Klassische Strategien zur Authentifizierung und Autorisierung sind dabei ungenügend. Strategien der Authentifizierung Der ursprüngliche Ansatz der Benutzerverwaltung ist auf Einzelsysteme zugeschnitten: Ein System (oder eine Betriebssystem-Instanz) ist in sich geschlossen und hat lokale Kontrolle über Benutzer und Rechte. Einzelne Anwendungen haben darüber hinaus eine eigene Benutzerverwaltung, etwa Datenbankanwendungen. Um zwischen verschiedenen Systemen zu navigieren, sind auf allen dieser Systeme passende Berechtigungen nötig; ein bestimmter User hat auf seinem eigenen Rechner andere Rechte als auf einem System, das ihm nur Speicherplatz zuteilt oder eine Anwendung zur Verfügung stellt. In Netzwerk-Umgebungen ist dieser Ansatz durch Lösungen wie NIS unter Unix und Domains mit Active Directory unter Windows ergänzt worden. Anstelle einzelner Berechtigungen pro System ist eine Zentralisierung und Verteilung der Rechte getreten. Diese Lösungen erlauben ein Single Sign On mit der Möglichkeit, differenzierte Rechte in Anwendungen und auf einzelnen Systemen zu haben. (Diese Form der Rechteverwaltung ist dennoch bereits sehr komplex und erfordert sehr fein granuläre Rechte, die über Dateizugriffsrechte hinausgehen. Diese Rechte werden in Verzeichnissen verwaltet und mittels Token an einzelne aktive Prozesse vergeben.) Die Grenzen von NIS und Active Directory ergeben sich dadurch, dass das Vertrauen innerhalb der Domains uneingeschränkt sein muss und die Abgrenzung nach außen naturgemäß strikt sein muss. Kerberos ist ein Ansatz, die Beschränkungen des NIS/Domain Prinzips zu überwinden, indem eine zentrale Instanz über die Berechtigungen auf den beteiligten Systemen Kontrolle ausübt, ohne, dass zwischen allen Beteiligten Systemen ein gegenseitiges Vertrauen bestehen muss, wie es in Domains Voraussetzung ist. Kerberos erlaubt auch Single Sign On, selbst in heterogenen Architekturen. Kerberos verwendet kryptographische Methoden, um abgesicherten Austausch zwischen Anwendungen zu ermöglichen, wie es auch in PVWhitepaper.doc 10/21 Stand: :29

11 Ablauf der Authentifizierung einer Service Orientierten Architektur erforderlich ist. Zugleich erfordert die Zentralisierung einen hohen Koordinationsaufwand, der zwischen unterschiedlichen Unternehmen oder Behörden nicht leistbar ist. Web-Services, die über verschiedene Domains verteilt sind, schaffen neue Anforderungen: Portale müssen die Authentifizierung übernehmen und Rechteinformationen vertrauenswürdig und zuverlässig weitergeben. Der relativ junge Ansatz von federated identity erlaubt es einem Benutzer, der einmal zuverlässig authentifiziert wurde, ohne weitere Authentifizierung auf anderen Systemen zu agieren und dabei definierte und abgegrenzte Rechte zu haben. Dies ist möglich durch ein genau abgegrenztes Vertrauensverhältnis zwischen Systemen unter Zuhilfenahme von Methoden der Kryptographie. Für federated identity gibt es verschiedene, großteils offene Standards, die in Aufbau sind und erfreulicherweise ein ausreichendes Maß an Konvergenz aufweisen. Die in Entwicklung befindlichen Standards verwenden XML als Middleware. SOAP ist dabei das kritische Element, dass es ermöglicht, über WSDL Services klar zu definieren und abzugrenzen. Es gibt grundsätzlich verschiedene Ansätze, wie in einer verteilten Anwendungsumgebung Authentifizierung ablaufen kann, wie in RFC 2904 definiert und detailliert. An jeder Authentifizierung, gleich ob lokal oder verteilt, sind drei Parteien beteiligt: Benutzer, Authentifizierungsservice (AAA Server) und Dienst (Service, Service Equipment). Abbildung 5: Rollen In [RFC 2904] werden drei Abläufe unterschieden: Agent Sequence, Pull Sequence und Push Sequence. Agent Sequence Bei der Agent Sequence übernimmt der Authentifizierungs-Server die Rolle eines Mittlers. (Abbildung 6) PVWhitepaper.doc 11/21 Stand: :29

12 Abbildung 6: Agent Sequence Die Benutzerin sendet die Anfrage direkt an den Agent, der die Anfrage authentifiziert und autorisiert. Der Agent erhält die Antwort des Services und gibt diese an die Benutzerin weiter. Beispiele dafür sind: Bandbreitenanforderung eine Benutzerin fordert eine Bandbreite von 1Mbit an, der Authentifizierungsserver (Bandwidth Broker) gibt die Anforderung an den Router weiter, dieser ordnet die Bandbreite zu. Internet Proxy Benutzerin fordert Webseite von HTTP Proxy an, Proxy authentifiziert Benutzerin, gibt Anfrage weiter und stellt Antwort an die Benutzerin durch. PVWhitepaper.doc 12/21 Stand: :29

13 Pull Sequence Bei der Pull Sequenz spricht die Benutzerin das Service direkt an, dieses führt eine Authentifizierung und Autorisierung der Benutzerin durch und führt anschließend das Service aus. (Abbildung 7) Abbildung 7: Pull Sequence Beispiele dafür sind: Dial In Service eine Benutzerin wählt sich bei einem Terminalserver an, dieser überprüft die Authentifizierungsdaten und führt eine Autorisierung durch, anschließend stellt er eine gültige Verbindung her. Web Server mit LDAP-Authentifizierung eine Benutzerin fordert von einem Webserver eine Seite an, die besondere Zugriffsrechte hat, der Webserver überprüft die Benutzerdaten gegen einen LDAP-Server und gibt schließlich die Seite an die Benutzerin aus. Push Sequence Bei der Push Sequence erhält die Benutzerin vom Authentifizierungsserver ein Ticket, das sie dem Service übergibt. Bei der Push Sequence gibt es normalerweise zeitliche Beschränkungen für die Tickets, Tickets können für ein Service oder mehrere Services ausgestellt sein und für eine oder mehrere Anfragen gelten. Die Kommunikation zwischen AAA-Server und Service wird durch die Benutzerin bewirkt. (Abbildung 8) PVWhitepaper.doc 13/21 Stand: :29

14 Abbildung 8: Push Sequence Beispiele dafür sind: Zugriffe auf ein Service unter Verwendung von Kerberos Der Kerberos-Server stellt im Rahmen einer sicheren, verschlüsselten Verbindung der Benutzerin ein Ticket aus, das diese verwendet, um sich in einer sicheren Verbindung mit dem Service zu autorisieren. PVWhitepaper.doc 14/21 Stand: :29

15 Authentifizierung bei verteilten Systemen In einer serviceorientierten Architektur können mehrere Komponenten für eine Anwendung notwendig sein. Daher können mehrere Anwendungssysteme, die zusammenwirken, vorkommen. Diese Systeme können unterschiedliche Authentifizierungssequenzen verwenden. Ein Beispiel dafür wäre die Abfolge von zwei Agent Sequenzen. (Abbildung 9). Es sind beispielsweise auch Pull- Agent (Abbildung 10) oder Agent-Pull Abfolgen möglich. Abbildung 9: Distributed Architecture, Agent und Agent PVWhitepaper.doc 15/21 Stand: :29

16 Abbildung 10: Distributed Architecture, Pull und Agent PVWhitepaper.doc 16/21 Stand: :29

17 Kombinierte Authentifizierungsmodelle Es können kombinierte Authentifizierungsmodelle auf Basis von verteilten Systemen in bestehen. Dabei ist es möglich, dass zu der Stamm-Organisation der Benützerin eine Super-Organisation hinzukommt, die übergeordnete Rechte auf Basis von Organisationen und Gruppen verschiedener Stamm-Organisationen verwaltet. Die Beziehungen und Abläufe können vielfältig sein. Das grundlegende Schema dieser Architektur ist in Abbildung 11 dargestellt. Abbildung 11: Kombinierte Architektur Schichten der Web-Service Architektur Aufbauend auf HTTP/HTTPS besteht die Web-Service Architektur als Service Orientierte Architektur (SOA) aus geschichteten Frameworks, die auf XML basieren. Einen Überblick gibt Abbildung 12, wobei die Definitionen von ID-WSF (Liberty) ausgelassen wurden, da sie als eine Überlagerung in der Abbildung dargestellt werden müssten. PVWhitepaper.doc 17/21 Stand: :29

18 XML Signature XML Encryption Abbildung 12: Ebenen der Web-Service Architektur Basiert auf PKCS#7, vergleichbar mit S/MIME. Erlaubt, XML Dateien komplett oder teilweise zu signieren. Ist Grundlagentechnologie für Web Service Security. Eine W3C Recommendation. Basiert auf shared key (symmetrische Schlüssel) und erlaubt, persistente Vertraulichkeit auf Basis von Dokumenten; SSL, das zur Transportsicherung verwendet wird, ermöglicht keine Ende-zu- Ende Sicherung. Ist Grundlagentechnologie für Web Service Security. Eine W3C Recommendation. SAML SAML dient dem Konzept des portablen Vertrauens. Es dient dazu, Daten der Authentifizierung, Autorisierung und verschiedene andere Attribute an XML anzuhängen. PVWhitepaper.doc 18/21 Stand: :29

19 Die Vertrauenswürdigkeit der SAML-Informationen ist dabei abhängig von der Vertrauenswürdigkeit des direkten Übermittlers, also etwa, eines Portals. Der derzeit aktuelle (offene) Standard ist SAML 1.1, SAML 2.0 liegt in einem Draft (rev. 7) vor. SAML 2.0 hat das Potential ein Industriestandard zu werden. In Abhängigkeit von der Verfügbarkeit, Interoperabilität und den Kosten entsprechender Produkte, ist geplant SAML 2.0 als Basis einer neuen Version des PV-Protokolls zu etablieren. Sollte sich ein Anwendungsfall ergeben, wo bereits jetzt ein SAML-Portal in den PV zu integrieren ist, kann SAML an einem Stammportal als Authentifizierungsmethode implementiert werden. WS-Security WS-Security ist ein die einzelnen Teilbereiche der Web Service Security überspannendes Konzept. Es definiert und beschreibt SOAP Security. Dieses Konzept beschreibt die Road Map für definierte Teilbereiche, die in ihrer Gesamtheit WS-Security ausmachen. Standardisierungsbestrebungen Derzeit entwickeln sich die Bestrebungen der einzelnen Interessensgruppen in Richtung einer Sammlung von Standards, die auf gemeinsamen grundlegenden Architekturelementen basieren. Liberty, das in der Abbildung 12 nicht dargestellt ist, versteht sich als ein übergeordnetes Framework, das beispielsweise Single-Sign- On bietet. Abbildung 13 stellt die Entwicklungslinien in vereinfachter Form dar. PVWhitepaper.doc 19/21 Stand: :29

20 Abbildung 13: Entwicklungen von SAML, WSS und Liberty. PVWhitepaper.doc 20/21 Stand: :29

21 Referenzen [WS-Security] Specification: Web Services Security, Version April [PVP 1.8] PVP-V.1.8.9e.doc, Rainer Hörbe, [SOA-Field Guide] Service-Oriented Architecture, A Field Guide to integrationg XML and Web Services, Thomas Erl, 2004, Prentice Hall, ISBN [SecWS] Securing Web Services with WS-Security, J. Rosenberg, D. Remy, 2004, SAMS, ISBN [RFC 2904] Network Working Group Request for Comments 2904, J. Vollbrecht et al., Aug PVWhitepaper.doc 21/21 Stand: :29