SAML 2.0 Bearer Assertion Flow for OAuth 2.0

• 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 NetWeaver Gateway. For more information, see SAP Note 1688545 .

For more information, see Configuring OAuth 2.0.

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.

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

For more information, see the following topics:

• Business Example for Accessing Resources with OAuth 2.0

• SAP Note 1688545

• Configuring OAuth 2.0