Show TOC

SAML-2.0-Inhaber-Assertion-Flow für OAuth 2.0Locate this document in the navigation structure

Voraussetzungen

  • Die Vertrauensbeziehung zwischen dem Autorisierungsserver und dem Aussteller der SAML-2.0-Inhaber-Assertion wird vom Identity-Provider repräsentiert.

  • Der Ressourcenverantwortliche muss dem SAML-2.0-Identity-Provider bekannt sein.

  • Der Ressourcenverantwortliche ist ein Benutzer, der über die Rollen verfügt, die ihm oder ihr die Berechtigungen für den Zugriff auf die Ressourcen gewährt, auf die von Cloud-Anwendungen oder Web-basierten Anwendungen zugegriffen werden soll.

  • In der Konfiguration des OAuth-2.0-Clients haben Sie OAuth-2.0-Scopes in Scope-Zuordnung zugewiesen.

  • Sie haben einem OAuth-2.0-Client eine Cloud-Anwendung oder Web-basierte Service-Anwendung zugewiesen.

  • Der Ressourcenverantwortliche muss auch berechtigt sein, den Zugriff auf einen OAuth-2.0-Client zu delegieren.

  • Der OAuth-2.0-Client (Benutzer mit dem Benutzertyp System) muss berechtigt sein, auf die Ressourcen zuzugreifen.

  • Der OAuth-2.0-Client muss einen Eintrag mit dem vertrauenswürdigen Identity-Provider für OAuth 2.0 haben.

  • Sie haben die Erteilungsart SAML-2.0-Inhaber im OAuth-2.0-Client aktiviert.

  • Sie haben eine Anwendung wie SAP NetWeaver Gateway installiert, die OData auf AS ABAP unterstützt. Weitere Informationen finden Sie im SAP-Hinweis 1688545 Auf SAP-Site veröffentlichte Informationen.

Weitere Informationen finden Sie unter OAuth 2.0 konfigurieren.

Vorgehensweise

Sie wollen auf bestimmte Ressourcen eines AS ABAP zugreifen und dafür eine Browser-basierte Cloud-Anwendung verwenden, ohne dazu gezwungen zu sein, der OAuth-2.0-Client-Anwendung die Anmelde-Credentials Ihres Benutzers (beispielsweise Ihr Kennwort) preiszugeben. OAuth 2.0 ermöglicht es den Benutzern, eine Teilmenge ihrer Berechtigungen an eine andere Anwendung zu delegieren. Dies kann eine Cloud-Anwendung sein, die dann auf die Ressourcen im Auftrag der Benutzer zugreifen kann.

Ein Benutzer verwendet eine Cloud-Anwendung und will auf bestimmte Ressourcen in einem AS ABAP zugreifen. Für den Zugriff auf die Ressourcen muss sich dieser Benutzer an der Cloud-Anwendung oder Web-basierten Anwendung authentifizieren und die Berechtigung erhalten, auf die entsprechenden Ressourcen zuzugreifen. Der OAuth-2.0-Client verwaltet den gesamten Authentifizierungs- und Autorisierungsprozess mit dem SAML-2.0-Inhaber-Assertion-Flow:

  1. Der OAuth-2.0-Client erhält eine SAML-2.0-Inhaber-Assertion vom SAML-2.0-Identity-Provider. Die Assertion enthält die Benutzerinformation des Ressourcenverantwortlichen und hat eine digitale Signatur vom Identity-Provider.

  2. Die Cloud-Anwendung oder Web-basierte Anwendung fordert einen Zugriffstoken vom Autorisierungsserver an. Die Zugriffstokenanforderung enthält Folgendes:

    • OAuth-2.0-Client-ID (entspricht dem AS-ABAP-Benutzernamen für die Anwendung, die den Zugriff auf die Ressourcen anfordert)

    • SAML-2.0-Inhaber-Assertion, die vom Identity-Provider empfangen wurde

    • Liste der OAuth-2.0-Scopes für die angeforderten Ressourcen

    Ein Beispiel eines Zugriffstoken: 

    POST /sap/bc/sec/oauth2/token HTTP/1.1
Authorization: Basic ...=
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Host: host.example.com:443
Content-Length: 3947
Connection: Keep-Alive

client_id=OA2_TEST&scope=OAUTH2_TEST_SCOPE1&grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=PEFzc2VydGlvbiBJ....

  3. Im Tausch gegen die SAML-2.0-Inhaber-Assertion stellt der Autorisierungsserver einen OAuth-2.0-Zugriffstoken aus, nachdem die Client-Credentials, die Vertrauensbeziehung mit dem SAML-2.0-Identity-Provider und die Berechtigung des Client und des Ressourcenverantwortlichen für die angeforderten Scopes vom Autorisierungsserver geprüft wurden. Die Serverantwort enthält folgende Elemente:

    • Zugriffstoken

    • Liste der gewährten OAuth-2.0-Scopes für die angeforderten Ressourcen. Diese Liste kann weniger Einträge enthalten, wenn der OAuth-2.0-Client oder der Ressourcenverantwortliche nicht berechtigt ist, auf die vollständige Liste der angeforderten Scopes zuzugreifen.

    • Lebensdauer des Zugriffstoken

      Ein Beispiel einer SAML-2.0-Inhaber-Assertion: 

      <Assertion ID="_ba59ce78-478a-4e81-ba59-4e8cb6ec4644" IssueInstant="2012-01-04T12:03:21.852Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>TEST_CLIENT</Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:SignedInfo>
                        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                        <ds:Reference URI="#_ba59ce78-478a-4e81-ba59-4e8cb6ec4644">
                                <ds:Transforms>
                                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                                </ds:Transforms>
                                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                                <ds:DigestValue>a+W4gwTA3TsjFu/4Ay3q2T9tcuQ=</ds:DigestValue>
                        </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>sfg0LT2Pb2kFD9lW5WKCC8bbhTf1j3YHWvF5HcM5jFT0ZW7aI0KKfjT9QQqytd7UkCKNwU1LX++eeCeWTyhTJjDzmPNiygpLrHZ024CnTw9Qtrn8skjdOYeL6HLLI5fRAmBerDclaao/qTck0On1X5MRzeI1qYty/htIX/wLegA=</ds:SignatureValue>
                <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                        <X509Data>
                                <X509Certificate>...=</X509Certificate>
                        </X509Data>
                </KeyInfo>
        </ds:Signature>
        <Subject>
                <NameID>SOKOLOVA</NameID>
                <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                        <SubjectConfirmationData NotOnOrAfter="2012-01-04T20:03:21.868Z" Recipient="https://host.example.com:44345/sap/bc/sec/oauth2/token"/>
                </SubjectConfirmation>
        </Subject>
        <Conditions>
                <AudienceRestriction>
                        <Audience>OAT_000</Audience>
                </AudienceRestriction>
        </Conditions>
        <AuthnStatement AuthnInstant="2012-01-04T12:03:21.870Z">
                <AuthnContext>
                        <AuthnContextClassRef>urn:none</AuthnContextClassRef>
                </AuthnContext>
        </AuthnStatement>
</Assertion>

  4. Der Autorisierungsserver speichert die Client-ID, den Ressourcenverantwortlichen und die gewährten Scopes in dem internen OAuth-2.0-Server-Kontextspeicher.

  5. Für den Zugriff auf eine angeforderte Ressource bettet der Client den Zugriffstoken (zum Beispielauthorization: bearer 4711 ...) in einen Berechtigungs-Header und leitet es mit der Ressourcenanforderung an den Ressourcenserver weiter.

  6. Der Ressourcenserver prüft Folgendes:

    • OAuth-2.0-Client-ID

    • Scope, der dem OAuth-2.0-Client zugewiesen ist

    • Gültigkeit des Zugriffstoken

    • Lebensdauer des Zugriffstoken

    • Scope, der durch den Zugriffstoken abgedeckt ist

    • Gültigkeit der SAML-2.0-Inhaber-Assertion im OAuth-2.0-Server-Kontextspeicher

    • Berechtigung für die Scopes, die vom Ressourcenverantwortlichen verfügbar gemacht wurden

  7. Der Ressourcenserver gewährt den Zugriff auf die angeforderte Ressource, wenn er von einem der Scopes abgedeckt wird, die dem Zugriffstoken zugewiesen sind.

Ergebnis

Bei Verwendung des OAuth-2.0-Client brauchen Sie keine Credentials mitzuteilen und können auf zulässige Ressourcen mit eingeschränkten Berechtigungen zugreifen.

Weitere Informationen

Weitere Informationen finden Sie in folgenden Abschnitten: