Beispiel einer Autorisierung mit WS-Trust und SAML

Dieser Artikel beschreibt, wie Web Services über einen zentralen Token Server gesichert werden können. Verwendet werden die Standards WS-Trust, WS-Policy, WS-SecurityPolicy und Web Services Security, welcher früher unter dem Namen WS-Security bekannt war. Als Beispiel dient ein einfaches Szenario aus einem Consumer, einem Service und einem Security Token Service, kurz STS.

Grob läuft das hier vorgestellte Szenario wie in Abbildung 1 dargestellt ab:

1. Der Consumer wendet sich an den Service und erfährt, dass er für einen Auftrag ein Token benötigt.
2. Um das Token zu bekommen wendet sich der Consumer an den STS und weist sich aus. Der STS stellt ein Token aus und gibt dies an den Consumer zurück.
3. Der Consumer ruft jetzt die gewünschte Operation des Service auf und übergibt dabei das gewünschte Token.
4. Der Service akzeptiert das Token und führt die Operation für den Consumer aus.

Abbildung 1: WS-Trust Szenario

Nachdem wir den groben Ablauf kennen, betrachten wir jetzt die einzelnen Schritte etwas detailierter.

Zunächst ruft der Consumer die WSDL Beschreibung des aufzurufenden Service ab. Wie in Abbildung 2 dargestellt, antwortet der Service mit einer WSDL, in der Metainformationen über die Anforderungen enthalten sind, die für einen Aufruf vorausgesetzt werden. Metainformationen, die die Anforderungen eines Service an seinen Consumer beschreiben, werden Policy genannt. Für eine interoperable Beschreibung der Policies gibt es die Standards WS-PolicyFramework und WS-PolicyAttachment.

Abbildung 2: Abruf der WSDL mit eingebetteter Policy

Die in die WSDL des Services eingebetteten Policies beschreiben, welche Teile eines Service Aufrufs verschlüsselt und signiert werden müssen und was für ein Token der Service erwartet. Ein Token enthült ein oder mehrere Claims. Claims sind Behauptungen, wie z. B.:

• Ich bin der Thomas
• Ich bin ein authentifizierter Benutzer
• Ich darf auf dem Farblaser drucken

Damit nicht jeder eine solche Behauptung aufstellen kann und damit auch noch Zugriff auf Ressourcen wie Services bekommt, werden Tokens oft von einer Autorität signiert. Im Beispiel ist der STS die Autorität, die uns einen signierten Token ausstellt.

Listing 1 ist der WDSDL des Service entnommen. Der Service erwartet bei jedem Aufruf ein SAML Token, welches über WS-Trust bezogen werden kann.

<wssp:ProtectionToken>
  <wsp:Policy>
    <wsp:ExactlyOne>
      <wsp:All>
        <wssp:IssuedToken wssp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
          <wssp:RequestSecurityTokenTemplate>
            <wst:TokenType>...#SAMLV1.1</wst:TokenType>
          </wssp:RequestSecurityTokenTemplate>
        </wssp:IssuedToken>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>
</wssp:ProtectionToken>

Der Consumer kann sich jetzt an den STS wenden, um den Token zu beziehen. Der Consumer muss die Adresse des STS kennen, bevor er sich an ihn wenden kann. Die Adresse kann z. B. im Metro Stack von Sun in einer Konfigurationsdatei hinterlegt werden. Zuerst fordert der Consumer, wie in Abbildung 3 gezeigt, die WSDL Beschreibung des STS an.

Abbildung 3: Abfrage der WSDL des STS

Im WSDL Dokument des STS sind wieder Policies eingebettet, die beschreiben, wie ein Aufruf an den STS auszusehen hat. Also wieder welche Teile der Nachricht signiert und verschlüsselt sein müssen, und wie der Consumer sich gegen den STS authentifizieren soll.

In unserem Beispiel erwartet der STS einen signierten Benutzernamen sowie eine Signatur für den gesamten Aufruf. Mit diesen Informationen kann der Consumer eine Anfrage an den STS mit der Bitte um die Ausstellung eines Tokens senden.

Abbildung 4:

Der Aufruf enthält ein Request Security Token oder kurz RST Element, welches beschreibt, was für ein Token der Consumer benötigt. Listing 2 zeigt das RST Element des Consumers.

<RequestSecurityToken>
  <RequestType>
    http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
  </RequestType>
  <AppliesTo>
    <EndpointReference>
      <Address>http://localhost:2000/payment/PaymentServiceService</Address>
    </EndpointReference>
  </AppliesTo>
  <TokenType>
    http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
  </TokenType>
</RequestSecurityToken>

Der STS validiert die Signatur des Aufrufs mit dem öffentlichen Schlüssel des Consumers. Das signierte Username Token wird ebenfalls validiert. Ist die Validierung erfolgreich, weiss der STS, dass der Request vom Consumer stammt und nicht verändert wurde. Jetzt kann der STS mit einer Request Security Token Response, kurz RSTR, antworten, die er mit seinem privaten Schlüssel signiert. Der RSTR enthält das gewünschte SAML Token, wie in Listing 3 dargestellt. Das Token ist für einen Benutzer thomas, welcher sich über den Besitz eines privaten Schlüssels authentifiziert hat. Ferner bestätigt das Token, dass der Besitzer des Token´s authentifiziert ist.

<saml:Assertion AssertionID="uuid-7bf" IssueInstant="2008-06-13T16:07:44.812Z" 
                 Issuer="SunSTS" MajorVersion="1" MinorVersion="1">
  <saml:Conditions NotBefore="2008-06-13T16:07:44.812Z" 
                    NotOnOrAfter="2008-06-13T16:08:20.812Z"/>
  <saml:AttributeStatement>
    <saml:Subject>
      <saml:NameIdentifier NameQualifier="http://sun.com">
        thomas
      </saml:NameIdentifier>
      <saml:SubjectConfirmation>
        <saml:ConfirmationMethod>…:holder-of-key</saml:ConfirmationMethod>
        <ds:KeyInfo>…</ds:KeyInfo>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Attribute AttributeName="token-requestor„
                    AttributeNamespace="http://sun.com">
      <saml:AttributeValue xsd:type="xsd:string">authenticated</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>     
</saml:Assertion>

Der Consumer besitzt jetzt das für den Aufruf des Zielservice notwendige Token und kann dieses zusammen mit einem Aufruf an den Service schicken.

Abbildung 5: Zeigt den Aufruf des Zielservices.

Der Aufruf enthält im SOAP Header das vom STS signierte Token sowie Signaturen des Aufrufs. Die Security Informationen sind, in Elemente eingebettet, die vom OASIS Standard Web Services Security beschrieben werden. Der Service kann das Token mit der öffentlichen Signatur des STS validieren und die Anfrage dann entsprechend verarbeiten und dem Client antworten.

Damit die Kommunikation zwischen Consumer und STS bzw. Service nicht von Fremden belauscht werden kann, wird oft eine zusätzliche Verschlüsselung eingesetzt. Das Ausspähen des Token´s wird damit verhindert. Im Beispiel habe ich auf die Verschlüsselung verzichtet um das Szenario einfach zu halten.

Ich hoffe, dieser Artikel konnte das Zusammenspiel der WS-* Spezifikationen WS-Trust, WS-Policy und Web Services Security verdeutlichen.

Thomas Bayer, Juli 2008