Dreiklang

Nicht erst seit der Verabschiedung von Web Services Security 1.0 (WS-Security) im März 2004 durch die Organization for the Advancement of Structured Information Standards (OASIS) war klar, dass sich diese Spezifikation als allgemein akzeptiertes Verfahren für die Verschlüsselung und Sicherstellung der Integrität von SOAP-Nachrichten durchsetzen wird (siehe Kasten „Infos im Web“). Erst kürzlich hat OASIS die Version 1.1 vorgestellt.

Wie in einem früheren iX-Artikel am Beispiel von Microsofts Web Service Enhancements (WSE) dargestellt, verwendet der Client zum Beispiel ein UsernameToken, um sich beim Dienstanbieter als rechtmäßiger Benutzer auszuweisen [1]. Darüber hinaus werden bestimmte Teile der Nachricht, etwa der SOAP Body oder das UsernameToken, im Web Service Security Header mit einem symmetrischen Schlüssel gegen unerlaubte Blicke von Dritten geschützt. Der symmetrische Schlüssel selbst ist mit dem öffentlichen Schlüssel des Empfängers chiffriert und damit eindeutig für ihn bestimmt. Der Adressat weiß um die getroffenen Sicherheitsvereinbarungen und behandelt die Nachricht entsprechend.

Doch wie sieht es mit der viel beschworenen Flexibilität bei fachlichen Änderungen in einer solchen service-orientierten Architektur aus? Mit welchem Aufwand ist zu rechnen, wenn der Empfänger auf eine Single-Sign-on-Technik umstellt? Benötigt der Client dann ein anderes Token und wie soll er sich zukünftig authentifizieren? Und wie teilt der Dienstanbieter diese neue Konfiguration allen potenziellen Clients mit?

Auf diese und weitere Fragen soll das im Dezember vergangenen Jahres gegründete Web Services Secure Exchange Technical Committee (WS-SX TC) bei OASIS Antworten in Form neuer Spezifikationen geben, die auf WS-Security aufbauen. Die Arbeit an den ursprünglich von einem Herstellerkonsortium eingereichten Entwürfen zu den neuen Standards WS-Trust, WS-SecureConversation und WS-SecurityPolicy will das Kommitee bis Mitte 2007 abgeschlossen haben.

WS-Trust: Vertrauen ist gut

Eine wesentliche Rolle spielt WS-Trust, dem ein zentraler Dienst, der Security Token Service (STS), zugrunde liegt. Ein STS ist für die Ausgabe, Prüfung, Erneuerung und Entwertung von Sicherheits-Token aller Art verantwortlich und definiert dafür Bindings, mit denen er die entsprechenden Protokollnachrichten beschreibt. Alle Bindings verwenden ein Token Request Framework, das sich auf zwei Nachrichtentypen beschränkt: <wst:RequestSecurityToken> (RST) für die Anfrage an den STS und <wst:RequestSecurityTokenesponse> (RSTR) für dessen Antwort. Spezifische URIs (Uniform Resource Identifyer) im WS-Addressing-Element <wsa:action> ermöglichen es dem STS zwischen den Bindings zu unterscheiden. So weist etwa docs.oasis-open.org/ws-sx/ws-Trust/200512/RST/Issue die Herausgabe eines neuen Tokens an.

Was sich zunächst als überschaubare Rollenbeschreibung liest, entpuppt sich bei genauerem Hinsehen als Anforderungsliste an eine komplexe Middleware. Das STS zeigt in einer typischen Rolle als Ausgabestelle für vertrauenswürdige Identitätsinformationen, dass zum einen die Integration mit im Unternehmen vorhandenen Sicherheitsdiensten notwendig ist (siehe Kasten „Universeller Token-Dienst“). Zum anderen muss der STS über ein Regelwerk verfügen, um eingehende RST benutzerspezifisch behandeln zu können, etwa zum Setzen der Authentifizierungsmethode (Passwort, Kerberos et cetera) in einer SAML Assertion (Security Assertion Markup Language). Die Verlagerung der Prüf- und Transformationslogik in eine zentrale Komponente soll Client und Provider nach dem Prinzip der Minimalinvasivität möglichst unabhängig von sicherheitstechnischen Änderungen machen und Eingriffe in den Programmcode auf ein Mindestmaß reduzieren.

Andere Spezifikationen können die generischen WS-Trust Bindings dazu verwenden, den Umgang mit neuen Token-Formaten genauer festzulegen. Diese beim WS-SX TC als Profil bezeichnete Konkretisierung erfolgt beispielsweise durch die Vorgabe zulässiger WS-Addressing URIs für ein bestimmtes Binding. WS-SecureConversation beschreibt ein solches Profil, indem es im Wesentlichen das Issuance Binding dafür nutzt, ein Handshake-Protokoll zum Aushandeln eines gemeinsamen Schlüssels zu definieren. Im Unterschied zu vergleichbaren Sicherheitsprotokollen auf der Transportschicht etabliert WS-Secure Conversation einen Sicherheitskontext auf der Nachrichtenebene, der einen gemeinsamen symmetrischen Schlüssel zwischen Client und Provider referenziert.

Sicher:Geheime Schlüssel

Das zustandslose WS-Security kennt keine Zusammenhänge zwischen lokalen Ressourcen (geheimer Schlüssel) und einem gemeinsam verwendeten Identifikator (Sicherheitskontext). Das führt dazu, dass beispielsweise bei mehreren verschlüsselten Nachrichten in Folge an den gleichen Adressaten jedes Mal ein neuer temporärer symmetrischer Schlüssel mit dem öffentlichen Schlüssel des Empfängers verschlüsselt wird.

WS-SecureConversation startet diesen rechenintensiven Prozess nur einmal zu Beginn einer Konversation. Im Zusammenspiel mit einem STS erzeugt er den geheimen Schlüssel und verteilt ihn an beide Kommunikationspartner. Der Client sendet dazu eine RST-Nachricht (Listing 1) mit der in WS-SecureConversation definierten <wsa:Action> URI und dem erforderlichen Request- und TokenType im SOAP Body an den ihm zugeordneten STS, der nach erfolgreicher Authentifizierung (etwa über ein mitgeliefertes UsernameToken) eine RSTR (Listing 2) mit einem neuen Security Context Token (SCT, <wsc:SecurityContextToken>) im SOAP Body verschickt.

<soap:Envelope xmlns:SOAP="..." xmlns:wsse="..." xmlns:wsu="..."
        xmlns:wst="..." xmlns:xenc="...">
    <soap:Header>
        ...
        <wsa:Action xmlns:wsa="...">
            http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT
        </wsa:Action>
        ...
        <wsse:Security>
            <xenc:EncryptedKey>
                ...
            </xenc:EncryptedKey>
            <xenc:EncryptedData Id="UsernameToken">
                verschlüsseltes UsernameToken
            </xenc:EncryptedData>
        </wsse:Security>
        ...
    </soap:Header>
    <soap:Body>
        <wst:RequestSecurityToken>
            <wst:TokenType>
                http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct
            </wst:TokenType>
            <wst:RequestType>
                http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
            </wst:RequestType>
            <wsp:AppliesTo>
                <wsa:EndpointReference>
                    <wsa:Address>http://provider.org/service</wsa:Address>
                </wsa:EndpointReference>
            </wsp:AppliesTo>
        </wst:RequestSecurityToken>
    </soap:Body>
</soap:Envelope>

<soap:Envelope xmlns:soap="..."
        xmlns:wst="..." xmlns:wsc="..." xmlns:xenc="...">
    <soap:Header>
        ...
        <wsa:Action xmlns:wsa="...">
        http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/SCT
        </wsa:Action>
        <wsse:Security>
            ...
        </wsse:Security>
    </soap:Header>
    <soap:Body>
        <wst:RequestSecurityTokenResponse>
            <wst:RequestedSecurityToken>
                <wsc:SecurityContextToken>
                    <wsc:Identifier>uuid:...</wsc:Identifier>
                </wsc:SecurityContextToken>
            </wst:RequestedSecurityToken>
            <wst:RequestedProofToken>
                <xenc:EncryptedKey Id="sharedSecretKey">
                    ...
                </xenc:EncryptedKey>
            </wst:RequestedProofToken>
            <wst:Lifetime>
                <wsu:Created>2006-02-02T22:04:17</wsu:Created>
                <wsu:Expires>2006-02-03T12:04:17</wsu:Expires>
            </wst:Lifetime>
        </wst:RequestSecurityTokenResponse>
    </soap:Body>
</soap:Envelope>

Das SCT beinhaltet lediglich den systemweit eindeutigen Identifikator für den neuen Sicherheitskontext, auf den sich beide Dialogpartner beziehen und der mit dem lokal gespeicherten symmetrischen Schlüssel assoziiert wird. Letzteren finden Client und Provider ebenfalls in der RSTR im <wst:RequestedProofToken>-Element, jeweils verschlüsselt mit ihren öffentlichen Schlüsseln. Ohne selbst die RST gestellt zu haben, bekommt der Provider die RSTR ebenfalls zugestellt (Token Propagation). Befinden sich STS und Provider nicht am selben Ort oder sollen sich mehrere Parteien den neuen Sicherheitskontext teilen, kann der Client dem STS die Endpunkte über das Element <wsp:AppliesTo> in der RST bekanntgeben. Im Anschluss verwenden die Kommunikationspartner wie gewohnt die in WS-Security definierten Mechanismen, referenzieren aber bei Signaturen beziehungsweise verschlüsselten Daten den Sicherheitskontext.

Obwohl es der Name nahe legen würde, trifft WS-SecureConversation derzeit keine Aussage dazu, welchen Bezug der SCT zu einer Anwendungssitzung (Session) hat und welchen Einfluss deren Lebenszyklus auf den des Sicherheitskontextes hat. Denkbar ist, dass zum Beispiel innerhalb einer Sitzung mehrere Kontexte für die Signaturen erzeugt werden, diese jedoch nicht zwingend an die Lebensdauer der Session gebunden sind und sie somit überdauern können.

Das Verfallsdatum eines SCT legt der STS via <wst:Lifetime>-Element in der RSTR fest (Listing 2). Eine Verlängerung lässt sich mit dem vom WS-Trust übernommenen Renewal Binding beim STS und einer profilspezifischen Action URI einleiten. Auch das Entwerten von SCTs (Cancel Binding) hat man weitgehend unverändert von WS-Trust übernommen.

Viele Schlüssel zum Erfolg

Als Prophylaxe gegen Kryptoanalyse und mögliche Rückschlüsse auf die geheimen Schlüsseldaten empfiehlt WS-SecureConversation, regelmäßig neue Schlüssel aus dem initialen Schlüssel (Basisschlüssel) abzuleiten. Mit dem von TLS (Transport Layer Security) übernommenen P_SHA-1-Algorithmus lässt sich aus den Binärdaten des alten Schlüssels, einer festen Bezeichnung des Kommunikationspartners und einem sicheren, unvorhersehbaren Einmalwert ein neuer geheimer Schlüssel ableiten. Signaturen oder verschlüsselte Daten im WS-Security Header verweisen dann nicht mehr auf das <wsc:SecurityContextToken>, sondern referenzieren ein neues <wsc:DerivedKeyToken>, das dem Empfänger die notwendigen Angaben zur Berechnung des abgeleiteten Schlüssels liefert.

Unbeantwortet blieb bislang die Frage, wie der Client in dem skizzierten Single-Sign-on-Szenario die erforderliche Sicherheitskonfiguration für die Kommunikation mit dem STS und dem Provider erfährt. Dazu zählt beispielsweise, welche Art von Sicherheits-Token der Provider erwartet und welchem STS er vertraut. Üblicherweise würde man diese nichtfunktionalen Eigenschaften in Abhängigkeit der gewählten Plattform durch API-Aufrufe oder spezielle Deployment-Konfigurationen umsetzen. Wünschenswert wäre allerdings eine bessere Kapselung dieses architektonischen Aspekts von der eigentlichen Implementierung, verbunden mit einer deklarativen, maschinenlesbaren Repräsentation der Sicherheitsanforderungen. Damit ließen sich Client und Provider entkoppeln und die Konfiguration der Kommunikationseinstellungen automatisieren.

Die grundlegenden Sprachkonstrukte zur Beschreibung nichtfunktionaler Anforderungen von Web Services liefert WS-SecurityPolicy. Eine Servicerichtlinie (Policy) besteht aus einer Sammlung von Alternativen, aus der sich ein Client die mit seinen Fähigkeiten am besten übereinstimmende heraussuchen und seinem Request entsprechend konfigurieren kann. Jede dieser Alternativen bietet eine vollständige und gültige Anforderungsliste. Während sich WS-Policy auf das allgemeine Framework mit einem überschaubaren Wortschatz zum Beschreiben von Servicerichtlinien und -alternativen an sich beschränkt, erfolgt die domänenspezifische Definition der eigentlichen Anforderungsausdrücke (Policy Assertion) in separaten Spezifikationen. WS-SecurityPolicy legt daher die zulässigen Assertions für WS-Security, WS-SecureConversation und WS-Trust fest. Zu den wichtigsten zählen:

• Protection Assertions identifizieren die Elemente einer Nachricht, die signiert, verschlüsselt oder grundsätzlich in einer SOAP-Nachricht vorhanden sein müssen.
• Token Assertions geben Auskunft über die erwarteten Token-Formate, die zum Schutz der Nachricht verwendet werden sollen.
• Security Binding Assertions beschreiben übergreifende Szenarien wie Sicherung auf Transportebene über HTTPS (Transport Binding) oder Nachrichtenebene (Symmetric/Asymmetric Binding) als Sammlung elementarer Sicherheitseinstellungen (unterstützte Algorithmen, Notwendigkeit eines Zeitstempels et cetera)
• Supporting Token Assertions nehmen zusätzlich zu den Signatur- und Verschlüsselungs-Token in den Security Bindings Aufgaben wie die Benutzeranmeldung über ein UsernameToken wahr.

Mit der in Listing 3 auszugsweise dargestellten <sp:IssuedToken> Assertion kann der Service Provider einem Client mitteilen, dass er ein von seinem als vertrauenswürdig eingestuften STS herausgegebenes Token erwartet. Der Client muss dazu lediglich einen RST Request an den in <sp:Issuer> angegebenen STS mit einer Kopie des Inhalts in <sp:RequestSecurityTokenTemplate> schicken, der den STS in diesem Fall anweist, ein SAML Token auszustellen (<wst:TokenType>). Damit löst sich der Client aus der engen Bindung an die Sicherheitsanforderungen des Provider und kann mit Hilfe einer Policy-fähigen Laufzeitumgebung unverändert auf fachliche Änderungen reagieren. Wie im Single-Sign-on-Szenario besitzt der STS normalerweise noch eine eigene Policy, die unter anderem ein UsernameToken vom Client im RST mit der Supporting Token Assertion <sp:SignedSupportingToken> fordert (Listing 4). Zugleich schränkt der Provider die Anzahl der Alternativen über die entsprechenden WS-Policy-Sprachkonstrukte auf genau diesen Token-Typ (<wsp:ExactlyOne>) ein und stellt klar, dass es zusätzlich zum RST im SOAP Body (<sp:SingedParts>) signiert sein muss.

<sp:IssuedToken>
    <sp:Issuer>
        <wsa:EndpointReference>
            <wsa:Address>http://client.org/sts</wsa:Address>
        </wsa:EndpointReference>
    </sp:Issuer>
    <sp:RequestSecurityTokenTemplate>
        <wst:TokenType>
            http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID
        </wst:TokenType>
        ...
    </sp:RequestSecurityTokenTemplate>
  ...
</sp:IssuedToken>

<wsp:Policy>
    <sp:AsymmetricBinding>
    ...
    </sp:AsymmetricBinding>
    <sp:SignedSupportingTokens>
        <wsp:Policy> 
            <wsp:ExactlyOne>
                <wsp:All>
                    <sp:UsernameToken/>
                </wsp:All>
            </wsp:ExactlyOne>
        </wsp:Policy>
    </sp:SignedSupportingTokens>
    <sp:SignedParts>
        <sp:Body/>        
    </sp:SignedParts>
    ...
</wsp:Policy>

Policies sind meist in der WSDL-Beschreibung (Web Services Definition Language) des jeweiligen Services an entsprechender Stelle (Binding, Operation et cetera) referenziert. Die Details regelt das WS-PolicyAttachment.

Ehrgeiziges Ziel ist realistisch

Voraussichtlich kann das OASIS-Gremium seinen ambitionierten Zeitplan von 18 Monaten bis zur Verabschiedung der neuen Standards einhalten. Hauptsächlich spricht dafür der schon relativ ausgereifte Stand der Spezifikationen. Einige Implementierungen sind bereits verfügbar, entweder als Toolkits wie WSE (siehe Kasten „WS-SecureConversation mit .Net“) oder als eigenständige Server wie PingTrust von PingIdentity. Erste Prototypen in Open-Source-Projekten wie Apaches WSS4J liegen ebenfalls vor.

Im Gegensatz zur erst kürzlich verabschiedeten Nachfolgeversion 1.1 von WS-Security erweitern die hier beschriebenen Standards auf derzeit über 200 Seiten die Sicherheitskonzepte für Web Services erheblich. Insbesondere neue Web-Service-Protokolle werden davon profitieren, da Entwickler etwa die garantierte Übermittlung zusammenhängender Nachrichtensequenzen (WS-ReliableMessaging) über den neuen Sicherheitskontext gegen Angriffe wie die Übernahme einer Nachrichtensequenz (Sequence Hijacking) absichern können. Aber auch Anwendungsfelder wie Grid Computing ziehen daraus einen praktischen Nutzen, da sich erstmals ein gemeinsamer Kontext gruppenweit zwischen mehr als nur zwei Partnern teilen lässt.

Was Industriestandards für die Automatisierung von Geschäftsprozessen und den Austausch von Dokumenten auf der Anwendungsseite schon seit Jahren anstreben, scheint mit WS-SecurityPolicy nun auf der technischen Ebene Einzug zu halten. Es bleibt zu hoffen, dass durch die Reduzierung manueller Tätigkeiten bei der Konfiguration komplizierter Sicherheitseinstellungen die Fehleranfälligkeit und damit auch die Betriebskosten sinken, was insbesondere bei Herstellern von Geschäftsanwendungen und deren Kunden auf großes Interesse stoßen dürfte.

Martin Raepple
vertritt die SAP AG bei OASIS und anderen Standardisierungsgremien im Bereich Web Services und Security.

Literatur

[1] Ludger Springmann; Security; Schutzschilde; Web Services absichern im .Net- und Java-Umfeld; iX 02/2005, S. 106