Show TOC

SAML 2.0 Bearer Assertion Flow for OAuth 2.0Locate this document in the navigation structure

Prerequisites

  • There is a trust relationship between the authorization server and the issuer of the SAML 2.0 bearer assertion, which is the identity provider.

  • The resource owner must be known by the SAML 2.0 identity provider.

  • The resource owner is a user who has the roles that grant him or her the authorizations to access the resources that are to be accessed by the cloud or web-based application.

  • In the configuration of the OAuth 2.0 client, you have assigned OAuth 2.0 scopes in Scope Assignment.

  • You have assigned a cloud or Web-based service application to an OAuth 2.0 client.

  • The resource owner must also be authorized to delegate access to an OAuth 2.0 client.

  • The OAuth 2.0 client (user with user type System) must have the right to access the resources.

  • The OAuth 2.0 client must have an entry with the trusted identity provider for OAuth 2.0.

  • You have activated the grant type SAML 2.0 Bearer Active in the OAuth 2.0 client.

  • You have installed an application that supports OData on AS ABAP, such as SAP Gateway. For more information, see SAP Note 1688545 Information published on SAP site.

For more information, see Configuring OAuth 2.0.

Procedure

You want to access selected resources of an AS ABAP using a browser-based cloud application without being forced to supply your user's login credentials (for example your password) to the OAuth 2.0 client application. OAuth 2.0 allows users to delegate a subset of their permissions to another application, such as a cloud application which can then access the resources on behalf of the users.

A user is working in a cloud application and wants to access selected resources in an AS ABAP. To get access to the resources, this user needs to authenticate at the cloud or Web-based application and get the authorization to access the respective resources. The OAuth 2.0 client handles the entire authentication and authorization procedure with the SAML 2.0 bearer assertion flow:

  1. The OAuth 2.0 client gets a SAML 2.0 bearer assertion from the SAML 2.0 identity provider. The assertion contains the user information of the resource owner and has a digital signature from the identity provider.

  2. The cloud or Web-based application requests an access token from the authorization server. The access token request contains the following:

    • OAuth 2.0 client ID (corresponds to the AS ABAP user name for the application that requests access to the resources)

    • SAML 2.0 bearer assertion received from the identity provider

    • List of OAuth 2.0 scopes for the requested resources

    The following is an example of an access token:

    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. In exchange for the SAML 2.0 bearer assertion, the authorization server issues an OAuth 2.0 access token after having checked the client credentials, the trust relationship with the SAML 2.0 identity provider, and the authorization of the client and the resource owner for the requested scopes. The server response contains the following elements:

    • Access token

    • List of granted OAuth 2.0 scopes for the requested resources. This list may contain less entries if the OAuth 2.0 client or the resource owner is not allowed to access the full list of requested scopes.

    • Lifetime of the access token

      The following is an example of a SAML 2.0 bearer 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. The authorization server stores the client ID, the resource owner, and the granted scopes in the internal OAuth 2.0 server context store.

  5. To access a requested resource, the client embeds the access token (such as authorization: bearer 4711 ...) into an authorization header and forwards it with the resource request to the resource server.

  6. The resource server checks the following:

    • OAuth 2.0 client ID

    • Scope assigned to the OAuth 2.0 client

    • Validity of the access token

    • Lifetime of the access token

    • Scope covered by the access token

    • Validity of the SAML 2.0 bearer assertion in the OAuth 2.0 server context store

    • Authorization for the scopes make available by the resource owner

  7. The resource server grants access to the requested resource if it is covered by one of the scopes assigned to the access token.

Result

Using the OAuth 2.0 client you need not share credentials and you can access permitted resources with restricted authorizations.

More Information

For more information, see the following topics: