Web Services haben zu Recht den Ruf einer Zukunftstechnologie erworben. Die möglichen Auswirkungen der Implementierung Service-orientierter Architekturen auf die IT-Sicherheitsinfrastruktur in Unternehmen werden in der Branche allerdings heftig debattiert. Neben der Absicherung der Anwendungsumgebung bilden die sichere Übertragung von Web Services sowie Schutzmaßnahmen für die Web Service-Applikation selbst hier die Kernaspekte. Protokolle wie SSL, die bei der Übertragung von Web Services nur Schutz auf der Transport-Ebene bieten können, reichen alleine also nicht aus. Neu entwickelte Standards, von denen hier die wichtigsten erläutert werden sollen, garantieren das notwendige Maß an informationsgebundener Sicherheit.
Eine Frage der Sicherheit
Bei Web Services handelt es sich um modulare Softwarekomponenten, die über das Internet lokalisiert und aufgerufen werden. Sie kapseln die Funktionalität einer Anwendung und stellen diese standardisiert über das Internet zur Verfügung. Die gekapselten Module können dynamisch integriert und zu komplexen Prozess- und Geschäftsabläufen zusammengefügt werden. Ein Web Service selbst ist aber keine eigenständige Applikation, sondern bildet die Schnittstelle zwischen dem Web und der tatsächlichen Anwendungslogik des zur Verfügung gestellten Dienstes. Da es sich bei Web Services im Prinzip um dynamische Web-Ressourcen handelt, nutzen sie die vorhandene Internet- und Web-Infrastruktur und stellen keine weiteren technischen Anforderungen.
Diese Dienste kommunizieren über Plattform- und Programmiersprachen-unabhängige Protokolle und basieren auf den Standards Extensible Markup Language (XML, aktuelle Version 2.0) [1], Simple Object Access Protocol (SOAP, aktuelle Version 1.1) [2], Web Services Description Language (WSDL, aktuelle Version 1.1) [3] und Universal Description, Discovery, and Integration (UDDI, aktuelle Version 2.0) [4]. XML und SOAP als Standards sind nicht abgesichert, sodass man über einen nicht geschützten Web Service zum Beispiel unerlaubterweise auf sich hinter der Firewall befindende Ressourcen zugreifen könnte.
Sicherheit ist ein Kernaspekt beim Einsatz von Web Services, insbesondere da die zugrunde liegenden Protokolle wie TCP/IP oder HTTP für sich allein unsichere Transportmechanismen sind und weder XML noch SOAP inhärente Sicherheitsmechanismen aufweisen. Gerade in Anbetracht der Tatsache, dass Web Services zunehmend nicht nur zur Integration von Applikationen und Daten innerhalb eines Unternehmens genutzt werden, sondern in immer stärkerem Maße auch für die Abwicklung komplexer, asynchroner Geschäftstransaktionen über das Internet, wird klar, welcher Stellenwert hier ausgereiften Sicherheitsmechanismen zukommt.
Im Wesentlichen wird zwischen Sicherheitsmaßnahmen auf Applikations- und Transport-Ebene unterschieden.
Sicherheit auf Transport-Ebene
SSL (Secure Socket Layer) ist das am weitesten verbreitete Protokoll zur Verschlüsselung von Daten im Internet. Zur Absicherung von Web Services ist SSL allerdings nur bedingt tauglich, da sich so zwar der Transportweg zwischen Absender und Empfänger absichern lässt, nicht aber das dabei übermittelte Dokument selbst. So können weder der SOAP-Message-Header noch der im SOAP-Body enthaltene Payload mittels SSL digital signiert oder selektiv verschlüsselt werden, da sonst wichtige Routing-Informationen verloren gingen. Dazu kommt, dass SSL wichtige Session-Informationen, die beispielsweise Auskunft über die Identität eines Aufrufers eines Web Service oder die Gültigkeitsdauer einer Anwendersitzung geben, nur ungenügend ausdrückt. Nicht zuletzt deshalb ist SSL alleine ausschließlich für Punkt-zu-Punkt-Verbindungen geeignet und gewährleistet keine durchgehende Ende-zu-Ende-Sicherheit einer SOAP-Nachricht.
Weil Daten, die nicht über den SSL-Tunnel laufen, nicht verschlüsselt werden und daher ungeschützt sind, besteht bei mehrstufigen, so genannten multiplen Web Services akute Manipulationsgefahr. Wenn beispielsweise eine Anwendung Web Service
A für die Kauf-Order und Web Service
B für den Versand aufruft, müssen zwei SSL-Verbindungen aufgebaut werden. Solange sich die zwei in die Transaktion involvierten Dokumente noch in der Übertragung zwischen zwei SSL-Sessions befinden, sind diese sehr leicht angreifbar. Aus diesem Grunde reichen nur auf die Transport-Ebene bezogene Sicherheitsmaßnahmen insbesondere bei mehrstufigen Web Services nicht aus.
Sicherheit auf Applikations-Ebene
Im folgenden werden mehrere Standards vorgestellt, die die Integrität, Authentizität sowie die Vertraulichkeit und die Verbindlichkeit von Web Services-Transaktionen gewährleisten sollen.
Nachrichten-Struktur
- WS-Security [5]: erweitert SOAP um Funktionen wie Verschlüsselung und digitale Signaturen. In WS-Security wird festgeschrieben, wo genau in einer Web-Service-Schnittstellendefinition die Sicherheitsinformationen untergebracht sind [6].
Vertraulichkeit, Datenintegrität und Authentizität bei XML-Inhalten
- XML Encryption [7]: liefert eine Syntax für die selektive Verschlüsselung und Dekodierung von XML-Dokumenten oder -Dokumentenblöcken. Der Empfänger der Daten erkennt mit Hilfe der Technologie, welche Teile des Codes verschlüsselt sind und kann das Quelldokument wieder herstellen.
- XML Signature [8]: Norm zur digitalen Signatur von XML-Dokumenten. Mit diesem Verfahren wird sichergestellt, dass ein XML-Dokument genau so beim Empfänger eintrifft, wie es der Absender losgeschickt hat. Außerdem lässt sich die Urheberschaft einer Information auf diese Weise verbindlich validieren, sodass sich diese im Nachhinein nicht abstreiten lässt (non-repudation).
Zugangskontrolle bei XML-Content
- Security Assertion Markup Language (SAML) [9]: XML-basierte Spezifikation, mit der sich sicherheitsrelevante Informationen zu Authentifizierung, Autorisierung und den Anwender-Attributen ausdrücken sowie Berechtigungs-Schemata definieren lassen. Ganze Dokumente oder Dokumententeile mit den entsprechenden Sicherheitsinformationen (z.B. bezüglich Identität oder Berechtigungen) können an Partnersysteme weitergeleitet werden. Bei SAML wird also die Struktur des Austauschs von Sicherheitsinformationen festgelegt, nicht aber die konkreten Mechanismen.
- Extensible Access Control Markup Language (XACML) [10]: Definiert Richtlinien für die Beschreibung und Anforderung von Zugriffsrechten. XACML übersetzt native oder proprietäre Autorisierungs-Strategien in ein Konzept, das sich für den Austausch zwischen oder die gemeinsame Nutzung von unterschiedlichen Systemen eignet.
- Extensible Rights Markup Language (XrML) [11]: XML-basierte Sprache für die Spezifikation von Rechten bei der Nutzung digitaler Ressourcen.
Abb. 1: XML- und Web Services-Sicherheit
Abbildung 1 klassifiziert die verschiedenen Standards und Protokolle, die bei der Absicherung eine wichtige Rolle spielen: SSL bildet einen sicheren Tunnel für die geschützte Übertragung eines XML-Dokuments an einen Web Service-Provider. Sollen jedoch nur bestimmte Teile eines Dokuments gesichert werden, kommen XML Encryption und XML Signature zum Einsatz, um die Vertraulichkeit und Authentizität von SOAP-Nachrichten zu gewährleisten. Innerhalb eines XML-Dokuments werden mit WS-Security die sicherheitsrelevanten Informationen festgelegt und diese beispielsweise als SAML- oder XrML-Ticket ausgedrückt.
Security Assertion Markup Language (SAML)
SAML ist eine auf XML basierende Beschreibungssprache, mit der Web Services auf einfache Art und Weise authentifizierungs- und autorisierungsbezogene Informationen austauschen können.
SAML liefert einen standardisierten Weg für die Beschreibung von existierenden Sicherheits-Modellen, ermöglicht den Austausch sicherheitsrelevanter Informationen zu Authentifizierung und Autorisierung und basiert darüber hinaus auf Standards und ist plattform- und herstellerunabhängig.
Die drei Hauptbestandteile der SAML-Spezifikation sind:
- Assertions: Hier werden Informationen zu Authentifizierung, Autorisierung sowie weitere Session-Attribute hinterlegt.
- Protokoll: Hier wird definiert, wie SAML-Assertions angefordert und übermittelt werden.
- Bindings und Profile: Hier wird festgelegt, wie SAML-Dokumente (Assertions) in Standard-Transport- und Messaging-Frameworks eingebunden werden.
SAML Assertions
Kern von SAML sind die so genannten Assertions, also vertrauenswürdige Aussagen von Endanwendern oder Web Services, die sich jeweils über eine bestimmte digitale Identität definieren. Es gibt drei verschiedene Arten von SAML-Assertions:
- 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 (z.B. Kontostand-Informationen) zugeordnet sind. Attributinformationen spielen bei der Zuweisung von Zugangsberechtigungen eine wichtige Rolle.
- Authorisation Decision Assertions: stellen fest, ob und wie auf eine spezifische Ressource zugegriffen werden darf.
SAML Assertions können digital signiert werden. Assertions werden von so genannten Autoritäten ausgegeben, die zur Veröffentlichung von Bestätigungen bevollmächtigt sind (Assertion Issuing Authorities). In der Praxis können alle drei Arten von Assertions von einer Autorität erzeugt werden.
Sämtliche SAML Assertions beinhalten die folgenden allgemeinen Informationen:
- Die ID des Ausstellers und das Ausgabedatum
- Die Assertion-ID
- Ein Subjekt (beispielsweise ein öffentlicher Schlüssel)
- Bedingungen, unter denen eine Assertion gültig ist
- Angaben, wie die Assertion erstellt wurde
Listing 1 zeigt eine einfache SAML Authentication Assertion.
Listing 1 <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">
Marc Chanliau
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>http://www/>
<saml:SubjectConfirmationData>
R1VD8fkkvlrhp
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
Die SAML Attribute Statements und die SAML Authorisation Decision Statements sind für verteilte Transaktionen und Autorisierungs-Dienste definiert.
- Ein SAML Attribute Statement bescheinigt, dass einem Subjekt S verschiedene Attribute (A, B etc.) mit bestimmten Werten a, b etc. zugeordnet sind.
- Ein SAML Authorisation Decision Statement wird von einer so genannten Autorisierungs-Instanz ausgegeben, die Zugriffsentscheidungen (Permit, Deny, Indeterminate) anhand der logischen Kombination von Principal-Attributen trifft.
SAML-Protokoll
Das SAML-Protokoll definiert die Interaktion zwischen einem SAML-Requester und einem SAML-Responder (Requester und Responder müssen sich gegenseitig als vertrauenswürdig anerkennen). Der Request wird von einem SAML-aware Client gestartet, die Response erfolgt von einem Sicherheitsdienst. Ein SAML-Request kann Queries für Authentifizierung, Attribute und Zugriffsentscheidungen beinhalten. All diese SAML-Requests werden von einem SAML-Response erwidert, der ein oder mehrere Assertions umfasst.
SAML-Bindings
Die SAML-Bindings legen fest, wie SAML-Request-Response-Nachrichten über Standard-Übertragungsprotokolle abgebildet werden. SAML definiert ein SOAP-over-HTTP-Binding, wobei SOAP hier eingesetzt wird, um eine Anfrage an eine SAML Authority zu stellen und eine enstprechende Antwort zu erhalten.
SAML-Profile
Die SAML-Profile spezifizieren, wie SAML Assertions in ein Message Framework oder ein Protokoll eingebunden und wieder extrahiert werden. SAML definiert ein Web Browser-Profil und ein WS-Security-Profil (als Teil der WS-Security-Spezifikation).
Web Services Security (WS-Security)
WS-Security ist eine Erweiterung des Simple Object Access Protocol (SOAP) und soll für die Vertraulichkeit und Integrität von Web Service-Dokumenten sorgen. Dieser Mechanismus unterstützt eine große Bandbreite von Sicherheitsmodellen und Verschlüsselungstechnologien wie etwa XML Encryption und XML Signature. WS-Security definiert so genannte Security Credentials, die an eine SOAP-Nachricht angehängt werden. Bei den hierbei verwendeten Security Tokens kann es sich um Kerberos-Tickets, X.509-Zertifikate, SAML-Assertions sowie XrML-Dokumente handeln.
WS-Security kann als Behälter für sicherheitsrelevante Informationen angesehen werden, der mehrere Typen von Security-Objekten umfasst. In diesem Zusammenhang macht WS-Security auch Gebrauch von SAML.
Das WS-Security-Profil für SAML basiert auf einer einzigen Interaktion zwischen Sender und Empfänger:
- Der Sender (Konsument eines Web Services) bekommt eine oder mehrere SAML Assertions und/oder Assertion Identifier.
- Der Sender ergänzt die SOAP-Nachricht um Assertions und/oder Assertion Identifier mittels eines WS-Security-Headers.
- Der Sender schickt die SOAP-Nachricht an den Empfänger (Web Service-Provider).
- Der Empfänger verarbeitet die Assertions und/oder Assertion Identifier, die in einer SOAP-Nachricht enthalten sind.
SAML Assertions und die Assertion Identifiers, die auf die Assertions verweisen, sind im <wsse:Security>-Element enthalten, welches wiederum im <SOAP-ENV:Header>-Element ausgedrückt wird:
<SOAP-ENV:Envelope>
<SOAP-ENV:Header>
<wsse:Security>
<saml:Assertion></saml:Assertion>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body></SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Die Verweise auf Assertions und Informationen über Assertion Retrieval Services sind im folgenden Element integriert <wsse:SecurityTokenReference>. Ein oder mehrere <saml:AssertionIDReference>-Elemente referenzieren die Assertions und können im <wsse:SecurityTokenReference>-Element enthalten sein. Das URI-Attribut (Uniform Resource Identifier) des <wsse:Reference>-Elements spezifiziert die Lage eines SAML-Responders, der das SAML SOAP Binding implementiert:
<wsse:SecurityTokenReference>
<saml:AssertionIDReference>
XVB12#$21abc
</AssertionIDReference>
<wsse:Reference URI=http://www.example.com/SAMLservice/>
</wsse:SecurityTokenReference>
Web Service-Technologien im Einsatz
Abschließend sollen die weiter oben erläuterten Sicherheits-Technologien im Rahmen eines Anwendungs-Szenarios beschrieben werden. Abbildung 2 zeigt eine schematische Sicht der Anwendung.
Abb. 2: Beispiel für mehrstufige Web Services
1. Der Aufrufer eines Web Services benutzt eine lokale Procurement-Anwendung und erteilt einen Kaufauftrag via HTML-Formular. Sobald das Formular gesendet ist, wandelt die Procurement-Anwendung das Formular in ein XML-Dokument um und integriert dieses in den Body einer SOAP-Nachricht. Die Procurement-Anwendung fügt die Benutzerinformationen in den WS-Security-Teil des SOAP-Envelope-Headers ein " entweder unter Zuhilfenahme klassischer Authentifizierungsmechanismen oder einer (signierten) SAML Assertion. Sobald die SOAP-Nachricht erstellt ist, wird diese von der Procurement-Anwendung via HTTPS übertragen.
2. Der den Kauf verbuchende Web Service erhält die SOAP-Nachricht von dem Aufrufer des Web Services, entschlüsselt diese und verarbeitet die in dem WS-Security-Element enthaltenen Sicherheitsinformationen des SOAP-Envelope-Headers. Ist die Entschlüsselung erfolgreich, hat sich der Benutzer dadurch authentifiziert. Anschließend wird die im Body des SOAP-Dokuments befindliche Information analysiert, um die Gesamthöhe des Kaufauftrags über XPath [12] zu ermitteln. Über XPath werden die Preisinformationen enthaltenden Elemente lokalisiert und zusammengerechnet, um so das Gesamtvolumen der Kauf-Order zu ermitteln. Der den Kauf verbuchende Web Service vergleicht das Gesamtvolumen des Auftrags mit den Berechtigungen des Käufers, um sicherzugehen, dass dieser zu einer Transaktion in dieser Höhe befugt ist. Bei erfolgter Autorisierung wird eine Anfrage an den für die Auslieferung zuständigen Web Service gestartet, womit der Web Service für die Kauf-Order jetzt als Requester eines weiteren Web Services agiert. Diese Anfrage wird wiederum in eine SOAP-Nachricht eingebunden, die Sicherheitsinformationen im SOAP-Envelope-Header sowie eventuell weitere Daten im SOAP-Envelope-Body enthält.
3. Sobald der für den Versand der Ware zuständige Web Service diesen Versandvorgang erfolgreich ausgelöst hat, schickt er eine SOAP-Nachricht an den Web Service für die Kauf-Order.
4. Der für die Kauf-Order zuständige Web Service (oder alternativ der Versand-Web Service) informiert den Käufer, dass der Kaufvorgang erfolgreich abgewickelt wurde und die Ware ausgeliefert wird.
Marc Chanliau ist Senior Product Manager bei Netegrity in Waltham (Massachusetts, USA). Er war Mitbegründer und erster Vorsitzender des Security Services Technical Committee (SSTC) innerhalb des Industriekonsortiums OASIS (Organization for the Advancement of Structured Information Standards), das für die Entwicklung der Security Assertion Markup Language (SAML) verantwortlich zeichnet. Nicht zuletzt deswegen gilt er als ausgesprochener Experte im Bereich Web Services-Sicherheit und XML-basierter Sicherheitsstandards. Er ist seit mehr als 20 Jahren in verschiedenen Positionen in der IT-Branche tätig.Links und Literatur
Hat Ihnen dieser Artikel gefallen? Dann abonnieren Sie das Entwickler Magazin direkt über unser
