SECURITY WEB APPLICATION. mit Scala. Plus CD! Stellenmarkt 61 Performance-Killern auf der Spur 64. Funktionale Programmierung.

Transkript

1 6.09 Plus CD! Stellenmarkt 61 Performance-Killern auf der Spur 64 Deutschland 7,50 Österreich 8,60 Schweiz sfr 15,80 Java Magazin Java Architekturen SOA Agile CD-Inhalt WebCastellum Spring Integration JSFUnit GA Enterprise D Marc Gille: SOA, SaaS und ich? Spring Integration Werkzeugkiste für EAI 56 Web Grails 1.1 Neues vom Groovy-Framework 32 Architektur Lose gekoppelte Systeme Die typischen Fehler vermeiden 99 SOA Center Sicher ist sicher JGAP ScalaTest Selenium HtmlUnit 2.4 Alle CD-Infos 3 SOA Security unter der Lupe 83 WEB APPLICATION SECURITY Was JEE-Architekten beachten müssen 46 Funktionale Programmierung mit Scala Das Tutorial 38 Bauen und Testen mit Grails 23 Die voll funktionsfähige Blog-Applikation mit Grails ist fertig, jetzt kommt die Kür. Das Tutorial zeigt Testmöglichkeiten sowie die unterstützten Build-Systeme. Dann klappt s auch mit der Qualitätssicherung.

2 SOA aus dem wahren Leben Teil 8 SOA Center SOA Security In klassischen Systemen sind Sicherheitsanforderungen durch ihre lokale Beschränkung meist relativ einfach beherrschbar. Deren Komplexität erhöht sich in der verteilten Systemlandschaft einer SOA: Sicherheit beschränkt sich hier nicht nur auf eine Applikation oder eine Anwendungsdomäne, sie muss anwendungsund geschäftsprozessübergreifend wirken. von Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig und Torsten Winterberg ur Realisierung dieser übergreifenden Sicherheitsanforderungen wurden zahlreiche Sicherheitsstandards geschaffen. Dazu zählen WS-Federation, WS-Secure- Conversation, WS-SecurityPolicy, WS- Trust, XML-Encryption, XKMS, XML- Signature, SAML1, SAML2 und viele mehr. Heute unterstützt kein Produkt oder Open-Source-Framework alle diese Standards vollständig. Zudem kommt es nach unserer Erfahrung oft zu Inkompatibilitäten, wenn ein SOA-Produkt oder Web Service Stack außerhalb seines kleinen Ökosystems kommunizieren muss. Kein Wunder, wenn nach ersten Absicherungsversuchen und guten Vorsätzen viele Projektverantwortliche durch explodierende Aufwände genervt nach beherrschbaren Alternativen fragen. Nicht selten wird dann auf unflexible, eigenentwickelte Lösungen zurückgegriffen, in denen schnell gefährliche Antipatterns implementiert werden, wie beispielsweise die Übertragung von Benutzername und Passwort im fachlichen Payload. Wir wollen in diesem Teil der Artikelserie nicht die zahllosen Standards beschreiben, sondern vielmehr an typischen Problemstellungen diskutieren, welche Art von Sicherheit für welchen Zweck relevant ist, wie diese implementiert wird und welche Standards dazu sinnvoll eingesetzt werden können. Damit wollen wir dem SOA- Architekten einige Hinweise geben, wie er verantwortungsvoll und auf der Basis erprobter Best Practices dem Thema Security gerecht werden kann. Wie viel Sicherheit soll es denn sein? Sicherheit nimmt aufgrund der weitreichenden Vernetzung durch SOA zwar eine enorm wichtige Rolle ein, sie ist jedoch nicht für alle Anwendungsgebiete und Architekturebenen in gleichem Maße notwendig. Es gilt deshalb zunächst für das Unternehmen und die betroffenen Abteilungen die internen und externen Sicherheitsanforderungen zu definieren. Dabei ist konzeptionell zu erarbeiten, wie diese mit den vorhandenen Mitteln und Standards möglichst einfach umgesetzt werden können. Mittels einer Risikoanalyse wird zu Beginn eines SOA-Projekts untersucht, wie wahrscheinlich das Eintreten eines bestimmten Schadens ist und welche negativen Folgen der Schaden mit sich bringt. So können der Aufwand und die Performancebelastungen, die mit bestimmten Security-Lösungen einhergehen, gegen die erreichte Absicherung abgewogen werden letztendlich ist dies auch eine monetäre Entscheidung. Neben der unternehmensweiten Risikoanalyse beeinflusst oft die Gesetzeslage die Sicherheitsarchitektur. Bedenkt man, dass seit geraumer Zeit auch Vorstände und Geschäftsführer persönlich für Versäumnisse und mangelnde Risikovorsorge verantwortlich gemacht werden können, so wird Sicherheit mehr und mehr zur Chefsache. Eine angemessene, flexible und vor allem durchgängige Sicherheitsarchitektur, die den Anforderungen der Sicherheitsrichtlinien, beispielsweise ISO [1] oder der BSI-Standard 100 [2] des öffentlichen Bereiches, genügt, ist also ein wichtiger Aspekt einer SOA. Security spielt auch in sicheren Umgebungen eine Rolle: In vielen Organisationen wird das Thema Security als nicht relevant betrachtet, da man sich im Kontext einer trusted Zone, etwa innerhalb eines Intranets, befindet und die Anwendungen hinter den Services bereits eine Art der Sicherheit implementieren. Hier sollte man jedoch bereits in der SOA- Referenzarchitektur beachten, dass auch orchestrierte Dienste (in BPEL, auf dem ESB, allgemein in Composite Services) gegebenenfalls erst zusammengesetzt geschäftskritisch wirken und auf höherer Ebene abgesichert werden müssen. Weiter sind wichtige Dienste z. B. davor zu schützen, massenhaft aufgerufen zu werden, damit sie ihre Zusicherungen zur Antwortzeit deterministisch erfüllen können. Andere Dienste können javamagazin

3 SOA Center SOA aus dem wahren Leben Teil 8 vertrauliche Daten enthalten, die auch innerhalb einer trusted Zone an keiner Stelle im SOA-Verbund in falsche Hände geraten dürfen, was ein nahtloses Ineinandergreifen der implementierten Sicherheit erfordert. Welche Arten von Sicherheit gibt es? In der IT-Sicherheit gliedert man das Bedrohungspotenzial in folgende Kategorien: Den Verlust der Verfügbarkeit, der Vertraulichkeit und/oder der Integrität. Beim Übertragen von Daten und Dokumentstrukturen kommt noch der Verlust der Authentizität (Echtheit) hinzu, was innerhalb einer SOA besondere Bedeutung gewinnt [2]: Verfügbarkeit: Dem Service Consumer stehen die Dienste (Services, Anwendungen, Systeme) zu den geforderten Zeitpunkten wie vereinbart ohne Beeinträchtigung des Geschäfts zur Verfügung. Vertraulichkeit: Schutz vor unbefugtem Zugriff auf vertrauliche Informationen, was bei deren Austausch eine neue Dimension der Schutzbedürftigkeit gewinnt. Integrität: Auch als Verlässlichkeit bezeichnet. Sicherstellung, dass Nachrichteninhalte vollständig und unverändert von Provider zum Consumer und umgekehrt gelangen. Authentizität: Der Nutzer ist der, für den er sich ausgibt und stellt keine anonyme Entität dar. Wie erwähnt sind die IT-Sicherheitsmerkmale mit Einzug der neuen serviceorientierten Architektur in die Referenzarchitektur aufzunehmen und in deren Kontext neu zu bewerten. Unsere virtuelle Autovermietung RYLC [5] hat beispielsweise folgende Sicherheitsrichtlinien für SOA aufgesetzt: Verfügbarkeit Zertifikate verhindern Attacken: In einer serviceorientierten Architektur werden die Services gewöhnlich in einer mehr oder minder geschützten Netzdomäne veröffentlicht. Business Services, die gewöhnlich einem breiten Publikum innerhalb oder sogar außerhalb einer Organisation zugänglich gemacht werden, sind den typischen Internetattacken wie Denial of Service ausgesetzt. Diese Art der Bedrohung wird gewöhnlich durch Netzmaßnahmen abgesichert. Als typische Sicherungsvariante kommt dabei oft das SSL-Protokoll in Verbindung mit X.509-Clientzertifikaten zum Einsatz. Hiermit wird der Nutzerkreis auf die Besitzer des Zertifikats reduziert und das Bedrohungspotenzial reduziert. Weitere typische Maßnahmen sind die IP-Prüfung, Messung der Aufrufhäufigkeit und Sperrung bei Überschreiten eines Schwellenwertes. Sicherstellen der Verfügbarkeit: Die öffentlichen Schnittstellen müssen oft 24/7 verfügbar sein. Um dies sicherzustellen, muss die SOA-Infrastruktur skalierbar und clusterfähig ausgelegt sein. Sie muss ebenso in der Lage sein, sich selbst zu beobachten und das drohende Verletzen der Verfügbarkeitsanforderungen erkennen zu können, sich selbst zu heilen oder einen Administrator zu benachrichtigen. Hilfreich ist hier der Einsatz eines geeigneten, hochverfügbaren ESB-Produkts als Entry Point aller Serviceaufrufe. Zu bedenken ist, dass die geforderte Clusterfähigkeit in Verbindung mit Reliability durch die komplexe Materie nur von wenigen SOA/ESB-Infrastrukturen ausreichend unterstützt wird. Die sorgfältige Auswahl geeigneter Produkte und vor allem deren Zusammenspiel ist entscheidend, um die geforderte Verfügbarkeit sicherzustellen. Besonders bei Open-Source-Projekten stellt das Zusammenspiel zwischen unterschiedlichen Werkzeugen oft eine Herausforderung dar, da deren Integration nicht bei dem Hersteller einer zusammenhängenden Suite liegt, sondern bei den Entwicklerteams, die damit arbeiten. Aus diesem Grund sollte bei der Auswahl darauf geachtet werden, dass es ggf. Support und Weiterentwicklungsgarantien von Dritten für die gesamte eingesetzte Suite gibt was gerade auch bei Open Source ein beliebtes Geschäftsmodell darstellt. Schnelle Reaktion auf Auffälligkeiten und Fehler sind in einer SOA-Landschaft zentrale Aufgaben. Hier haben sich so genannte Softwareagenten als Abnehmer etabliert, die an den Entry Points zum ESB als Querschnittsaspekte platziert werden und Informationen an zentrale Überwachungssysteme mit den typischen Protokollen wie z. B. SMTP liefern. Hierfür gibt es ausgereifte Produkte wie Nagios, Hyperic, Open- View, IBM Tivoli, Patroll, Oracle Enterprise Manager etc., die alle Komponenten wie Applikationsserver, Webserver, Loadbalancer usw. im SOA-Verbund überwachen können. Vertraulichkeit Unterschiedliche Anforderung je nach Servicekategorie: Vertraulichkeit ist bei externen Serviceaufrufen (Business Services) fast immer eine unabdingbare Anforderung. Für Serviceaufrufe aus dem Intranet auf unterer Kategorieebene (z. B. Business Entity Services (BES) oder Business Rule Service (BRS)) genügen bei nicht geschäftskritischen Services oft auch vertragliche und nicht technische Vertrauensbeziehungen. Die Vertrauensprüfung erfolgt deshalb meist auf oberster und externer Serviceebene also auf der Ebene von Business Activity Services (BAS) und Business Process Services (BPS). Verschlüsselung ermöglicht Vertraulichkeit: Erreicht wird Vertraulichkeit, also der Schutz vor unerlaubtem Zugriff auf sensible Daten, durch Verschlüsselung. Bei Verschlüsselung (Chiffrieren) handelt es sich um das Verfahren der Abbildung einer im Klartext vorliegenden Nachricht unter Zuhilfenahme eines Schlüssels in eine Geheimnachricht, die nur durch diejenigen entzifferbar sein soll, die den Schlüssel kennen [7]. Aufgrund der Problematik der Schlüsselübertragung und dessen Geheimhaltung, hat sich das asynchrone RSA-Verfahren [8] mit privatem und öffentlichem Schlüssel (Private- und Public-Key) durchgesetzt. Herausforderung Schlüsselmanagement: Da in einer SOA zur Verschlüsselung (Vertraulichkeit) und zum Signieren (Authentizität) die Nachrichtenschlüssel vorgehalten werden müssen, ist in einer SOA-Infrastruktur eine effiziente Schlüsselverwaltung notwendig. Leider werden allzu oft Schlüssel wild abgelegt und in der Infrastruktur 84 javamagazin

4 verteilt. Dies führt immer wieder zu Ausfällen, da bekanntlich die ausgestellten Schlüsselzertifikate ein Ablaufdatum besitzen und die Administratoren den Überblick verlieren, wann und wo welche Schlüssel abgelegt und zu erneuern sind. In einer gut strukturierten SOA wird idealerweise eine zentrale Schlüsselverwaltung implementiert und diese aus den Services oder Security-Agenten per XKMS [4] angesprochen, was wir weiter unten noch im Detail behandeln. Antipattern SSL in Web Services : Der Reflex, SSL zur Protokollabsicherung zu verwenden, ist bei einer End- 2End-Absicherung nicht zielführend. Mit SSL wird bekanntlich nur der Weg zwischen zwei Knotenpunkten abgesichert. Auf den Zwischenknoten kann innerhalb des ESB oder BPEL sein bis zum eigentlichen Backend-Service sind die Nachrichten nicht verschlüsselt und somit von Unbefugten einsehbar bzw. veränderbar. Bedingt durch den einfachen Betrieb der SSL-Technologie ist diese jedoch eine gängige Absicherungsart zwischen externem Konsumenten und Business Service der oberen Ebene; intern wird jedoch aufgrund der geltenden Richtlinien oft auf eine Nachrichtenverschlüsselung verzichtet. Wird aufgrund hochsensibler Daten dennoch eine End2End-Sicherheit gefordert, ist die Nachricht selbst, also die SOAP- oder REST-Nachricht, zu verschlüsseln, und nicht nur das Verbindungsprotokoll. Wird nun die gesamte Nachricht (Payload) verschlüsselt, kann dies im ESB oder BPEL zu Problemen führen, da die Inhalte nicht zur Logiksteuerung (z. B. Content-based Routing) verwendet werden können. In der Praxis hat sich deshalb die Teilverschlüsselung der kritischen und schützenswerten Inhalte (z. B. nur das eine Element mit den Provisionsdaten) als Best Practice bewährt. Integrität Versiegeln der Nachricht: Vollständigkeit und Unveränderbarkeit einer Nachricht kann am einfachsten sichergestellt werden, wenn ein Siegel darauf gesetzt wird. Das aufgebrochene Siegel deutet auf eine Veränderung der Nachricht hin, was den Empfänger zur Protokollierung und Abweisung der Nachricht bewegen sollte. Ein solches Siegel wird technisch in zwei Schritten hergestellt: Mithilfe eines sicheren Hash-Algorithmus wird aus der Nachricht als Eingabeparameter ein eindeutiger Wert berechnet, der auch Message Digest genannt wird. Zur Berechnung hat sich der Secure Hash Algorithm 1 (SHA1 normiert in RFC3174) durchgesetzt. Im zweiten Schritt wird der Digest zusätzlich verschlüsselt und mit dem Zertifikat und der Nachricht des Senders verknüpft. Verwendet wird dazu die in der W3C-XML-Encryption- Spezifikation [3] definierte Vorgehensweise. Die Programmierung mit dem doch komplexen API entfällt glücklicherweise beim Einsatz eines Web Service Stacks wie z. B. Metro, CXF oder idealerweise beim Einsatz einer Policybasierten Security-Lösung, deren Funktionsweise wir im Detail noch erläutern. Authentizität Mit dem Begriff Authentizität wird die Eigenschaft bezeichnet, die gewährleistet, dass ein Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein. Mit Authentizität wird im SOA-Umfeld oft naiv umgegangen, wir werden daher genauer beleuchten, was schief gehen kann und stellen dann stabilere Lösungen vor. Anti-Pattern Benutzername/Passwortauthentifizierung : SOA-Entwickler sind keine Security-Experten. Mit einer entsprechenden Anforderung konfrontiert und unter Zeitdruck geschieht es schnell, dass Security-Aspekte in Dienste hineinprogrammiert werden, ohne die technischen Implikationen zu berücksichtigen. Eine der am häufigsten beobachteten Programmierfallen in diesem Sinne ist der Authentifizierungsmechanismus mit Username und Passwortabsicherung: Hier wird, wie in der Web-Service-Security-(WSS-)Spezifikation vorgegeben, sowohl der Username als auch das Password explizit im SOAP Header an den aufgerufenen Service übertragen. Handelt es sich um den initialen Serviceaufruf, stellt dies meist kein großes Problem dar. Denken wir jedoch daran, dass wir aus Flexibilitätsgründen Services zu Prozessen (z. B. per BPEL) orchestrieren wollen, die dann Anzeige

5 SOA Center SOA aus dem wahren Leben Teil 8 in einer komplexen Aufrufkette stehen. Eine Username- und Passwortabsicherung würde dann bedeuten, dass Nachrichten vom Prozessinitiator zu jedem potenziellen Service des Geschäftsprozesses neben dem Usernamen auch das Passwort im Klartext enthalten müssten. Alternativ müssten die Services/ Agenten das Passwort jeweils ermitteln. Beide Umstände sind administrativ und sicherheitstechnisch inakzeptabel. Es stellt sich daher die Frage, wie ein Sicherheitskontext durchgängig, ohne erneute Passworteingabe, durch die Prozesslandschaft getragen werden kann. Zusicherung einer ID mittels Token und Zertifikaten: Als Voraussetzung für eine stabile Authentifizierung sollten alle Nutzer von zu sichernden Services Menschen und Softwarebausteine eine eindeutige Identitätskennung erhalten. Für die Weiterleitung der Aufruferidentität hat sich vor allem in der SOA-Welt das so genannte Token-basierte Sicherheitsverfahren etabliert. Dazu meldet man sich an einem zentralen Authentifizierungsdienst, typischerweise über ein Portal SSO Login an, das die Credentials des Nutzers prüft etwa durch Passworteingabe, Zertifikat, Chipkarte oder sonstige biometrische Identifizierungsmechanismen. Der Authentifizierungsdienst erzeugt ein Token, das ein X.509-Zertifikat, ein Kerberos-Ticket oder auch eine SAML- Zusicherung (Assertion) sein kann, und verpackt dieses in das standardisierte SAML- (Security-Assertion-Markup- Language-)Sicherheitsaustauschformat [7]. Dieses enthält u. a. die Nutzeridentität man spricht auch vom Subject, die dann zur Sicherheitsabfrage und zur Protokollierung vom Eintrittspunkt bis in das Endsystem durchgereicht wird. SAML standardisiert also die XML-Sicherheitsstruktur, die zum Austausch von Sicherheitsinformationen innerhalb und auch außerhalb der Web-Service-Security- Spezifikation (im WSS SOAP Header) benutzt werden kann. Die mit SAML gegebene Interoperabilität auf Security-Ebene erlaubt erst den Aufbau einer unternehmensübergreifenden Sicherheitskommunikation, weshalb Security mit SAML von Beginn an in die Architekturfestlegung verankert werden sollte. Authentifizierung und Security-Kontext-Übermittlung: Zur Übermittlung einer Identität in einer SOAP-Nachricht hat sich der Standard WS-Security in Verbindung mit SAML durchgesetzt. Dieser beschreibt u. a., wie in einem SOAP Header eine standardisierte XML- Struktur mit Identifikationsinformationen verpackt und übertragen wird. Nutzung des Usernamen im Fachcode: Verwendet der Service zur Umsetzung der Sicherheitsrichtlinien einen Querschnittsaspekt, der für den fachlichen Serviceimplementierer neutral eingewoben wird und alle Security- Aufgaben vorgeschaltet abhandelt, stellt sich die nächste Frage: Wie bekommt die fachliche Serviceimplementierung oder die funktionsimplementierende Komponente die Informationen, um welchen User es sich tatsächlich handelt? Verlangt wird dies beispielsweise, wenn die implementierende Komponente aus fachlichen Gründen nur dem Anwender zugeordnete Daten zurückliefern bzw. ändern darf. Beispiel: der Zugriff eines Services auf eine Datenbank setzt letztlich den korrekten User voraus. Die Übergabe des Benutzernamens im Payload parallel zum Security Header ist auch hier die denkbar schlechteste, jedoch am häufigsten vorgefundene Methode. In dem Fall können die Standardmechanismen der Infrastruktur kaum genutzt und der Serviceaufrufer oder auch die Servicemediatoren können die Anwenderdaten sehr einfach manipulieren und damit Zugriff auf unberechtigte Inhalte erlangen. Es muss also der Security Context in die Komponente getragen werden. Ideal ist, wenn der Service selbst als JAVA-EE-Komponente [6], Spring-Komponente oder als Agent implementiert wird. Hier erfolgt das Propagieren des Sicherheitskontexts nach Konfiguration automatisch. Obwohl dieses Vorgehen logisch erscheinen mag, sehen wir täglich, dass dieses Designprinzip verletzt wird und der Username oft parallel, beispielsweise als Service- oder Methodenargument, mit in die Anwendung übermittelt wird. SOA-Sicherheitsinfrastruktur Wir haben bereits gesehen, dass es problematisch ist, Serviceimplementierungen und Security-Aspekte zu vermischen. Im Sinne des Separation-of-Concern- Prinzips sollte Fachlogik und technische Logik (hier Security-bezogen) strikt getrennt werden: Die Skills, die für diese Aspekte nötig sind, unterscheiden sich sehr von der Serviceprogrammierung, weshalb eine Mischung zu schwer wartbaren Services führen würde. Daher sollte beim Etablieren einer SOA-Sicherheitsarchitektur eine klare Trennung zwischen Anwendungs- und Sicherheitslogik auf allen Ebenen erzwungen werden. Realisiert wird dieser Querschnittsaspekt dann meist durch Umsetzungen der Designpattern-Fassade, Proxy, Wrapper oder aber mithilfe von Policies, sodass bei Implementierung eines Services die Fachlogik isoliert dasteht und je nach Anforderung konfigurierbar mit unterschiedlichen Security-Implementierungen umschlossen werden kann. Da wir dieses Prinzip der Sicherheitsrealisierung als wichtig empfinden, wollen wir im folgenden Abschnitt näher darauf eingehen, wie Security-Aspekte durch eine Policy-basierte Sicherheitsarchitektur isoliert umgesetzt werden können. Aspektorientierte Security mit Policy-based Management Policy-based Management (PBM) zum entkoppelten und aspektorientierten Sicherheitsmanagement setzt sich neben der vorhanden Security in den Anwendungskomponenten (z. B. Security im WS-Stack) aufgrund der schwer wartbaren Verteilung von Sicherheitsrichtlinien und der immer komplexer werden Verwaltung auch im SOA-Umfeld immer mehr durch. Generell wird mit PBM das gesamte querschnittliche IT-Systemmanagement sowie dessen Konfiguration unter Verwendung von Policies und Agenten bezeichnet. Policies definieren Verhaltensregeln und werden meist in einem zentralen Repository erstellt und abgelegt. Die in den Policies enthaltenen Regeln werden dann an den sicherheitsrelevanten Punkten im System von Agenten umgesetzt. Bei Vorhandensein einer Verschlüsselungs-Policy, die dynamisch vom Policy Decision Point (PDP) geliefert wird, würde beispielsweise ein im Web Service platzierter Agent die 86 javamagazin

6 SOAP-Nachricht mit den gegebenen Informationen verschlüsseln. Der Web Service selbst hat in diesem Fall weder Sicherheit zu implementieren noch die komplexen Security-Artefakte in den Java-EE-Deployment-Deskriptoren zu konfigurieren. Damit muss der Web Service bei einer Änderung der Sicherheitsrichtlinien weder angepasst noch neu deployt oder durchgestartet werden. Typische Produkte sind der IBM Tivoli Security Operations Manager, der WebService Manager (OWSM) der Firma Oracle oder die integrierte Policy-Verwaltung in der Open-Source-SOA-Suite SOPERA. Funktionsweise der Agenten: Innerhalb eines PBM kommt meist das Agentenkonzept zur Realisierung der querschnittlichten Aspekte zum Einsatz. Agenten fungieren als Policy Enforcement Points, auch kurz PEP genannt, und werden innerhalb der Laufzeitkomponenten im Proxy-Code zwischen Aufrufer und Ausführer platziert. Sie ermitteln über den Policy Decision Point (PDP) vom zentralen Policy Repository die konfigurierten und notwendigen Sicherheitsmerkmale und führen sie vor dem eigentlichen Serviceaufruf aus. Neben Authentifizierung, Autorisierung und Verschlüsselung können die Agenten natürlich auch SOAP-Nachrichten signieren und Protokollierungsaktionen ausführen. Die dabei genutzten Policies werden heute meist durch den XML- Standard WS-Policy [9],[10] beschrieben und in einem zentralen Governance Repository durch den Policy Administration Point (PAP) gepflegt. Innerhalb des PBM ist der PEP für die Interpretation und Durchsetzung der Autorisierungsentscheidungen der vom PDP gelieferten Policies im System oder Service verantwortlich. Als Standardsprache zur Abfrage der Zugriffskontrolle hat sich die extensible Access Control Markup Language (XACML) durchgesetzt. Auf diese wird auch innerhalb von SAML zum Austausch der Autorisierungsinformationen zurückgegriffen, da XACML ein SAML-Profil definiert. Als Policy Decision Point (PDP) wird die Komponente bezeichnet, die die Autorisierungsentscheidungen anhand der ihr bereitgestellten Sicherheits-Policies trifft. Gewöhnlich nimmt ein PDP Meldungen von PEPs entgegen und ermittelt aus einem Repository die anzuwendende Policy. Der PDP erkennt und behebt dabei zur Laufzeit Konflikte bei mehreren vorhanden überschneidenden Policies. Der Policy Decision Point kann somit auch als Legislative (Gesetzgeber) innerhalb des Access Managements bezeichnet werden. Die Verteilung der Policies nach Änderungen oder Erweiterungen erfolgt je nach Anforderung durch einen Pushoder Pull-Mechanismus. Die Verwendung der Push-Methode, bei der vom Administrationsserver die Änderungen in den PDP getragen werden, findet bevorzugt Verwendung. Da durch PBM das physische Service-Deployment bei Änderungen einer Policy entfällt, wird eine Governance-unterstützende Administrationskomponente, in dem Umfeld PAP Policy Administration Point genannt, mit Workflow-Mechanismen, inklusive zeitabhängig geregelter Verteilung und Approval-Routinen für den geplanten Rollout und Aktivierung der Policies notwendig. Die Verwendung des Agentenkonzepts hat den unerwünschten Nebeneffekt, dass die Aufrufpipelines der Services verändert werden und somit ein unerwünschter Systemeingriff (Implementierung oder Konfiguration des WS wird durch den Agenten verändert) vorgenommen werden muss. Es wird deshalb neben dem Agentenkonzept oft auch das Konzept der Sicherheitsgateways angewandt. Die Sicherheit wird hierbei durch ein vorgeschaltetes und zentral platziertes Sicherheitsgateway als Proxy-Komponente implementiert, die alle Aufrufe abfängt, die Policies ausführt und dann an den Originalservice weiterleitet. Dieses Konzept ist jedoch in Bezug auf Sicherheit nicht ganz so robust wie das der Agenten: Zwischen Sicherheitsgateway und Service liegt eine Netzstrecke, auf der potenziell eine Manipulation stattfinden könnte. Das Agentenkonzept integriert sich dagegen in den Service und ist somit sicherer. Sicherheitsgateways können den Sicherheitskontext nicht in den Service und die implementierenden Komponenten tragen. Ein Agent kann dagegen einen Sicherheitskontext Anzeige

7 SOA Center SOA aus dem wahren Leben Teil 8 der eingegebenen Kreditkartennummer über einen weiteren extern abgesicherten Service vom Kartenprovider die Bonität geprüft. Im positiven Fall wird im Rental- System die Buchung getätigt und dem Kunden wird per Mail eine Referenz-ID als Schlüssel für weitere Anfragen und zur Abholung übermittelt. Abb. 1: Security im Rent-Your-Legacy-Car-(RYLC-)Beispiel JAVA-EE-konform oder anwendungsspezifisch aufbauen. Sicherheitsgateways generieren durch die zentral platzierte Schleuse generell eine höhere Systemlast, die mit berücksichtigt werden muss. Public Key Infrastruktur (PKI) via XKMS: Zur Sicherstellung und Prüfung der Authentizität kommt gewöhnlich das asymmetrische Kryptosystem RSA zum Einsatz. Die Verwaltung der öffentlichen Schlüssel wird dabei in einer Public Key Infrastructure (PKI) bewerkstelligt. Innerhalb einer SOA liegt es nun nahe, die Schlüssel über entsprechende Services zu verwalten und nicht lokal verteilt an unterschiedlichen Stellen im Dateisystem oder in all den parallel betriebenen Applikationsservern abzulegen. Genau dafür wurde die XML Key Management Specification [4] vom World-Wide-Web- Konsortium definiert. XKMS definiert ein Protokoll, das die Funktionen einer PKI für Services zur Verfügung stellt. XKMS besteht aus zwei Teilen: X- KISS (XML Key Information Service Specification) definiert, wie die Schlüssel gesucht, bezogen und validiert werden, und X-KRSS (XML Key Registration Service Specification) spezifiziert, wie die Schlüssel per Service registriert werden. Wie gesagt, werden ohne XMKS die Schlüssel gerne im Dateisystem verstreut abgelegt und sind somit kaum administrierbar. Zur Verdeutlichung der Sicherheitsmechanismen soll auch hier als Beispiel unsere virtuelle Autovermietung RYLC dienen [5]. Der zu sichernde Bestellprozess Das RYLC-Management hat zusammen mit den Chefarchitekten beschlossen, zukünftig den Bestellprozess SOA-fiziert wie folgt umzusetzen: Der Sachbearbeiter oder Kunde meldet sich am Webportal an und lässt sich die Leistungen und Preise jeder Autokategorie auflisten. Bei einer Reservierung wird der abgesicherte Service Angebot erstellen aufgerufen, der intern wiederum die abgesicherten Services Firmenrabatt ermitteln und Kundenstatus ermitteln, zur Berechnung der Konditionen, aufruft. Zudem wird die Verfügbarkeit des Autos am Standort durch den Aufruf des Service Verfügbarkeit prüfen der entfernten RentalApplication im Hintergrund ermittelt. Als Antwort erhält der Kunde ein Angebot mit Auflistung der Leistungen, des Preises und die möglichen Optionen der Versicherungsleistungen. Das Angebot der Versicherung wird jedoch nicht firmenintern, sondern durch Aufruf des extern abgesicherten Services Prämienberechnung für Mietauto aller Versicherungspartner ermittelt. Als Regel gilt derzeit, dass die günstigste Variante mit in das Angebot übernommen wird. Nimmt der Kunde das Angebot wahr Aufruf des Service Auftrag erteilen wird anhand Sicherheitsherausforderungen Der Chefarchitekt ist mit einer ganzen Menge von Sicherheitsanforderungen konfrontiert. Der Prozess muss abgesicherte Services der verschiedensten Applikationen integrieren. Externe Aufrufe gehen über das Internet und müssen somit auf Protokollebene abgesichert werden. Bei der Bonitätsanfrage wird neben der Verschlüsselung eine Signatur der Nachricht vom Anbieter verlangt. Abhängig von der Anwenderrolle (Großkunde, Endkunde) sind dem Anwender unterschiedliche Daten zu liefern. Und zuletzt sind aus Compliance-Anforderungen heraus alle verändernden Zugriffe zu protokollieren. Bedenkt man, dass Sicherheitsanforderungen in herkömmlichen Systemen durch ihre lokale Beschränkung meist relativ einfach beherrschbar sind, ändert sich dies bei übergreifender Prozessorientierung. Es werden nun nicht mehr nur lokale und ineinandergreifende Authentifizierungsmechanismen gefordert, sondern abhängig vom Aufrufkontext werden pro Service unterschiedliche Authentifizierungsmechanismen, die im Hintergrund zusammenarbeiten müssen, gefordert. Services, die von einem Host-System oder einer PL/SQL- Datenbank angeboten werden, verwalten ihre Benutzer mit unterschiedlichen Anmeldenamen meist intern. Diese Services müssen bei End2End-Sicherheitsanforderungen nun zusammenarbeiten. SOA macht im Bezug auf Security die IT-Landschaften von RYLC also nicht einfacher, sondern durch die Verzahnung eher komplexer: Was nützt jedoch die beste Sicherheit, wenn die Systeme und Produkte die IT-Sicherheitsstandards nur rudimentär implementieren und durch die Vielzahl der Standards selbst Experten Mühe haben, eine tragfähige und vor allem übergreifend wir- 88 javamagazin

8 SOA aus dem wahren Leben Teil 8 SOA Center Abb. 2: RYLC-Sicherheitsarchitektur kende Sicherheitsarchitektur aufzubauen. Wir gehen deshalb im Folgenden auf die Implementierung der Sicherheit in unserer Autovermietung näher ein. Authentifizierung über SSO-WebGate Der Sachbearbeiter meldet sich über das Webportal an. Dafür wurde die bestehende anwendungslokale Login- Maske entfernt und auf ein SSO-Login- Verfahren umgestellt, um im Weiteren eine identitätsübergreifende Sicherheit mit SAML implementieren zu können. Technologisch mussten dazu die lokal in einer DB-Tabelle vorgehaltenen Identitäten harmonisiert werden, mit dem Ziel, nur noch eine Identität pro Anwender vorzuhalten und nicht mehr eine pro Anwendung. Diese Identität wird in einem LDAP-Verzeichnis abgelegt. Vor das Webportal stellt der Chefarchitekt ein SSO-WebGate als eigenständige Komponente außerhalb des Applikationsservers. Dieses soll alle Requests abfangen, die enthaltenen Credentials validieren und wenn nötig ein SSO-Token über einen zentralen Authentifizierungsdienst erstellen. Der Authentifizierungsdienst, der heute meist als Access Manager bezeichnet wird, greift zur Validierung auf die hinterlegte Identität im LDAP-Verzeichnis zurück. Moderne Authentifizierungsdienste verwenden ein SAML-Token, um damit einen Java- EE-Sicherheitskontext aufzubauen. Dazu ist das JAAS-Login-Modul im Applikationsserver zu konfigurieren, das das SSO-Token erkennt, revalidiert und den Java-EE-Sicherheitskontext mit allen Rollen und Principals aufbaut. Warum entscheidet sich der Chefarchitekt für den Umweg über das Web Gateway und den Access Manager und verwendet nicht die im Applikationsserver integrierte Java-EE-Authentifizierung allein? SSO ist derzeit nicht standardisiert und SAML2 für Web-SSO noch kaum verbreitet. Würden alle Systemkomponenten direkt auf ein LDAP zugreifen, wäre meist nur eine User/ Passwort- und kaum eine andere Form der Authentifizierung möglich, was ein Übertragen des Sicherheitskontextes unmöglich machen würde. Zudem wären der Administrationsaufwand und die Verwaltung aller Zugriffs-Policies um ein Vielfaches aufwändiger als über eine Policy-Management-Komponente. Auch beliebige Clients können problem- los an die separate Authentifizierungskomponente angebunden werden. Weitergeben der ID in Serviceketten Nach erfolgreichem SSO-Login wird ein BPEL-Prozess gestartet, der wiederum die intern abgesicherten Web Services wie z. B. Angebot erstellen aufruft. Da die initiierende Anwendung, die Java-EE- Portalanwendung, die den Geschäftsprozess startet, aus dem Java-EE-Container kein Password ermitteln kann, muss das im Applikationsserver abgelegte SSO- Token (idealerweise SAML2-Token) in den SOAP Header des BPEL-Aufrufs gelegt und von den Folgeservices verstanden werden. Natürlich soll diese Querschnittsaufgabe nicht vom Programmierer selbst übernommen werden; vielmehr verwendet der Chefarchitekt dazu ein Policy-Framework, das alle Querschnittsaufgaben über den im Web Service verankerten Agenten (PEP Policy Enforcement Point) automatisiert erledigt. In unserem Fall ermittelt der Agent das Token aus dem Java EE Subject und erzeugt vor dem Versenden einen WS-Security-Eintrag im SOAP Header. Die einzige Aufgabe des Entwicklers/Deployers ist javamagazin

9 SOA Center SOA aus dem wahren Leben Teil 8 dann das Konfigurieren des Applikationsservers mit dem JAAS-Login-Modul, das aus dem SSO-Ticket den Java EE Security Context erstellt, und das Einbinden des Agenten beim Deployment des Web Services. Weitergabe an externe Services Neben den lokalen werden noch externe Web Services wie Verfügbarkeit prüfen oder Bonität prüfen angesprochen. Wie kann der Sicherheitskontext zu diesen externen Services übertragen werden, wenn man davon ausgehen kann, dass der externe Kreditkartendienstleister nicht alle potenziellen Aufrufidentitäten anlegen und verwalten will? Ein hier üblicher Weg ist, dass der Web-Service-Provider dem bereits validierten Sicherheits-Token (SAML) eines zuvor konfigurierten Ausstellers vertraut und nur noch die Integrität des Tokens prüft. Dazu muss das Zertifikat mit im übertragenen Sicherheitskontext enthalten sein. Beim Aufruf externer Services werden auch sensible Daten wie z. B. die Kreditkartennummer übermittelt, weshalb der Chefarchitekt die verlangte Vertraulichkeit mit in die Absicherung integrieren muss. Die Überlegung, Verschlüsselung der Daten allein auf Protokollebene per SSL zu realisieren, scheidet aus, da damit die geforderte End2End-Vertraulichkeit nicht realisierbar wäre. Also wird nicht nur der Weg, sondern auch die Nachricht verschlüsselt und ein Siegel mit dem privaten Schlüssel darauf gesetzt. Verwendet wird dazu das im WS-Security-Standard verankerte RSA-Verfahren, bei dem mit dem öffentlichen Schlüssel des Providers die Nachricht verschlüsselt wird. Entschlüsseln kann nun nur der Besitzer mit dem vorhanden privaten Schlüssel. Da in unserem Fall die Web Services bereits mit einem Agenten (PEP) bestückt sind, wird über das Policy-Management-Frontend die Policy zum Verschlüsseln der Nachricht zusätzlich angelegt. Beim Aufruf des Services durchläuft der Web Service alle für den PEP konfigurierten Policies (Insert Security Token, Encrypt, Sign) und führt diese sequenziell aus, wie in der Pipeline hinterlegt. Es ist fatal, Sicherheit auf die leichte Schulter zu nehmen und naiv zu implementieren. Nun ist die gesamte Nachricht verschlüsselt. Dies führt jedoch dazu, dass der ESB und die BPEL-Prozesse keine Routing-Logik mehr nutzen können, um die Nachricht an den korrekten Kreditkartenprovider zu senden. Also entschließt sich der Chefarchitekt zu einer Teilverschlüsselung, etwa nur noch der Kreditkartennummer und des Betrags. Die für das Routing nötigen Informationen werden nicht mehr verschlüsselt. Dies ist mit dem Policy-Framework, im Gegensatz zu JAX-WS, einfach zu lösen. Als weiterer Schutz wird nun die schon verschlüsselte Nachricht noch über einen VPN-Tunnel oder alternativ per SSL zum Kunden übertragen. Fazit Wir haben beschrieben, welche Sicherheitslösungen es für Verfügbarkeit, Vertraulichkeit, Integrität und Authentizität gibt. Die Lösungen sollten auf das Risiko, das sie adressieren, abgebildet sein: Mit Sicherheitslösungen gehen erhöhte Komplexität und tendenzielle Verschlechterung der Performance einher auf diesen Aspekt weisen wir hier hin und beleuchten ihn nicht näher im Artikel. Wohl wissend, dass ohne Security-Federation, Identity-Management (IdM) und Trust-Server eine übergreifende Sicherheit schwer realisierbar ist, haben wir uns im Artikel nur auf die häufig gegebenen Problemstellungen konzentriert. Es ist wichtig, die Security-Aspekte im Team und im Quellcode strikt zu isolieren. Es ist fatal, Sicherheit auf die leichte Schulter zu nehmen und naiv zu implementieren, etwa mit Benutzername/ Passwort-Paaren, die in allen Services weitergereicht werden. Wir haben gesehen, wie sich die Komplexität einer Security-Architektur als Sicherheitsaspekt außerhalb der Serviceimplementierung mithilfe von Policies isolieren und gut bewältigen lässt. Die Autoren: 2007 gründeten die Autoren die Masons-of-SOA mit der Vision, SOA über internationale Unternehmensgrenzen hinweg zu propagieren, kritische Projekte gemeinsam zu unterstützen und Erfahrung aus zusammen 20 SOA-Projektjahren weiterzugeben. Die Publikation dreier Entwurfsmuster (Compensating Service Transaction, UI Mediator sowie Canonical Schema Bus) in Thomas Erls SOA-Design-Patterns-Buch und die vorliegende Artikelserie sind Beispiele für diese Arbeit. Links & Literatur [1] IT-Grundschutz-Zertifikat: [2] verfuegbarkeit-integritaet-vertraulichkeit-authentizitaet [3] [4] [5] Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg: Rent your Car Service-oriented, Java Magazin [6] building.htm#bcghjhed [7] SAML OASIS: oasis-wss-saml-token-profile-1.0.pdf [8] [9] [10] 90 javamagazin