Security and Identity Management
Page tree
Skip to end of metadata
Go to start of metadata

Table of Contents:

Why is OAuth relevant for enterprise scenarios?

OAuth is the authorization concept for OData services. OData (Open Data Protocol) services as e.g. offered by SAP NetWeaver Gateway, opens business systems by offering access to business functionality to SAP and non SAP clients such as HTML5 applications or mobile clients. OAuth offers constrained access to services without the requirement to pass or store credentials. This makes it a good fit for cloud based and mobile services, where constrained access is of special interest.

Let's take an example. Bob is manager and has strong authorizations. When accessing an ERP system using SAPGui, he has all privileges assigned to his role. Bob is also using a mobile app to approve leave requests. This mobile app accesses OData services on a SAP NetWeaver Gateway system on behalf of Bob. When using his mobile app to access the Gateway, OAuth restricts Bob's access permissions to the set of OData services needed by his mobile app. When using other clients, Bob has access to more services.
To integrate services between cloud providers, access to resources is required.

In an enterprise environment one would configure single sign-on, as the systems are operated by one organization.

The setup for the cloud is different: As systems are not run by only one organization, access to resources must be limited. Take for example a cloud application for creating leave requests. When entering the data, the application only needs access to the leave request resources, but does not require access to the users payroll data. In this case OAuth ensures that only permissions for the leave request resources are granted to user and application, but access to payroll resources is denied.

With OAuth, access permissions depend on user and application. By limiting access to resources as well, OAuth follows the security paradigm of least privileges.


In an OAuth 2.0 Authorization Code flow scenario the business user can decide which of his resource permissions he wants to delegate to an application.

OAuth 2.0 Consumption Scenarios

This WIKI contains a deep dive on what it means to secure an application with OAuth 2.0. Therefore we created a complete implementation of a leave request scenario leveraging OData services in SAP NetWeaver Gateway. You can access the scenario in our live system.

Click on the links below to get a thorough understanding on how to implement and configure OAuth 2.0.

Scenarios Overview

OAuth 2.0 Terminology

Click here to find an explanation of common OAuth 2.0 terms and how they are realized inside the AS ABAP.

OAuth 2.0 Flows Supported by SAP

The OAuth 2.0 implementation in AS ABAP supports two kinds of OAuth 2.0 flows as defined in the OAuth 2.0 specification.

Basically the flows differ in the way how an access token is obtained by the OAuth 2.0 client application.

  • In the SAML 2.0 Bearer Assertion Flow a SAML assertion containing information about the resource owner is presented to the AS ABAP.
  • In the Authorization Code Flow the access token will be issued based on an authorization code token. This token was created by the AS ABAP after the resource owner gave his consent to grant a certain OAuth 2.0 client application access to his or her resources.

The following table shows the differences between those two flows giving you a recommendation which flow fits best to your scenario.

SAML 2.0 Bearer Assertion Flow Authorization Code Flow

Administrator controlled:

Administrator preconfigures

  1. the accessible resources
    • by creating an OAuth 2.0 client via transaction SOAUTH2 and
    • assigning the respective scopes to this client
  2. which resources a resource owner is allowed to delegate to which OAuth 2.0 client applications
    • by assigning authority object S_SCOPE, e.g. contained in a role, via transaction PFCG

User controlled:

  • the resource owner can restrict or grant access to resources in the Authorization Endpoint UI based on the preconfiguration of the Administrator.
  • preconfiguration is done the same way as described on the left.

No user interaction necessary

well suited for

  • web application server-side service consumption like in Java Servlets, server side WebDynpro, BSPs, JSPs, ASP ...
  • batch-jobs (non Web-application)

User interaction

user grants or denies permission

  • based on the administrator's permission preconfiguration
  • well suited for client side service consumption in the browser like XMLHTTPRequest with AJAX

Authentication at a central user store (e.g. Active Directory) via a SAML Identity Provider (IDP) / Security Token Service (STS)

  • benefits of a central user mapping or identity federation spanned access domain boundaries
  • single point of entrance
 Authentication at the AS ABAP directly
Trust relationship is required between the authorization server and the issuer of the SAML 2.0 bearer assertion, which could be the SAML identity provider. No trust for Single Sign-On needs to be established to the AS ABAP.
Scenario works "out-of-the-box". It is just a matter of linking up the AS ABAP with the caller application.

Have a look at our consumption scenarios to get a feeling how the two flows described here can be realized

Sample Implementations

sample implements for use in customer projects are available here: Sample Implementations

Availability of OAuth 2.0 with AS ABAP and SAP NW Gateway

In order to enable OData Services for OAuth 2.0 you need to have a minimum SP Level of SAP Basis and SAP NW Gateway software components deployed on your SAP NW Gateway system.

Grant Type: SAML 2.0 Bearer Assertion

  • Minimum SAP_BASIS 7.40 SP02 & SAP_GWFND 7.40 SP02
    or
  • Minimum SAP_BASIS 7.31 SP05 & GW_CORE 200 SP06 & IW_FND 250 SP06
    with required notes listed below. OAuth2 on AS ABAP 731 requires a 7.21 kernel as described in SAP Note 1717249.
SAP_BASIS 731
Required Notes
SP08
  
SP07
1824678,1826831
SP06
1809124,1813397, 1826326, 1824678,1826831
SP05
1767985,1809124, 1813397, 1826326,1824678, 1826831
GW_CORE 200
Required Notes
SP07
  
SP06
1815659
IW_FND 250
Required Notes
SP07
  
SP06 onwards*
1797103(modification)

*Note 1797103 always needs to be applied for SAP_BASIS 731 (!) and is delivered as modification, i.e. not included in a certain support package.

Grant Type: Authorization Code

  • Minimum SAP_BASIS 7.40 SP02 & SAP_GWFND 7.40 SP02

Documentation

Below you find the links to the official documentation on help.sap.com

4 Comments

  1. Former Member

    Hi Mathias, great post.

    We are using OAuth 2.0 with SAP Gateway with Authorization Code grant type. What we don't find is a way to use a refresh token. What should we configure to make SAP Gateway return a refresh token in the token response?

    Our version is SAP_BASIS 7.40 SP05 and SAP GWFND 7.40 SP05.

     

    Thanks!!

    1. Mathias Essenpreis

      Hi Alejandro,

      we support refresh tokens. Please see the answer in the forum http://scn.sap.com/message/15778919.

      Mathias

      1. Former Member

        Thanks Mathias!

  2. Former Member

    Hi Mathias,

       I am currently looking to use the O-Data connector in BOBJ IDT to get data out of ByDesign, I noticed that there is no SSO option on the connection, is there any work around for this?

    Thanks