Skip to main content

Authorization with SAP Cloud Identity Services


Authorizations are domain specific and still the aim is that they can be assigned to an identity centrally. Traditionally authorizations are defined in the application and are not centrally managed. This leads to a huge effort to maintain the authorizations and to ensure that the least-privilege-methodology is applied across different stacks and solutions.

Architecture

image of solution diagram
Copy to clipboard

Solution Diagram Resources
You can download the Solution Diagram as a .drawio file for offline use. Alternatively, you may view and edit the Solution Diagram directly on draw.io.
Please note that any changes made online will need to be saved locally if you wish to keep them.

SAP uses for the authorization assignments in an identity lifecycle the Identity Directory. Identity Directory is a SCIM compliant user and group store. Identity Directory acts as customer fascade for the identity lifecycle and the central point for the authorization assignments. The Cloud Identity Services also act as trusted anchor for the SAP applications for several security features like the authentication and the authorization assignments, but also the federation with 3rd party solutions.

Many systems e.g. SAP NetWeaver ABAP have a long history of defining authorizations combined in template roles in the system with detailed restrictions and derivations of those template roles. In the SAP Business Technology Platform (BTP) the autorizations are also specified in the application. SAP BTP applications based on the SAP BTP Authorization and Trust Managemetn (XS UAA) e.g. via SAP Cloud Application Programming Model CAP the developer defines the app-roles within the application. In the XS UAA which is visible to you as user-management in each BTP subaccount, each customer administrator can create and maintain Role Collections. Role Collections can group multiple app-roles. Role Collections can be assigned to users, while app-roles cannot.

In the context of new applications, the SAP Cloud Identity Services - Identity Directory functions as the user and group store. This advanced service accommodates the SAP Authorization Management Service (AMS)(AMS)-defined policies, which are stored and assigned to users in the Identity Directory. The AMS allows the definition of policies by the app-developer but a central derivation and assignment to users in the Identity Directory.

Preparation

Current SAP applications with an user- & group / role store expose those via the SCIM2 protocol.

  1. The SAP Cloud Identity Services - Identity Provisioning (IPS) replicates the groups from the SAP applications into the Identity Directory.
  2. SAP BTP applications based on AMS publish automatically the policies into the Identity Directory as groups.
  3. SAP BTP applications based on XS UAA should be configured with IPS to replicate Role Collections into the Identity Directory as groups.
Examples

SAP S/4HANA Cloud exposes Roles as Groups and Users as Users via SCIM2.

SAP Cloud Identity Services themselves use AMS to allow finegrained authorizations.

Flow

  1. The authorization assignment to a user is done in the Identity Directory.
  2. This can be done by the SCIM2 API or by the SAP Cloud Identity Services user interface (UI).
    • The UI allows two different views:
      • The user view allows the assignment of groups to a user.
      • The groups view allows the assignment of users to a group.
    • The SCIM2 protocol mandates the assignment via the /Groups endpoint by maintaining the members attribute (the UI does the same).
  3. The replication of the assignments to the SAP applications is done based on the used technology:
    • Applications with an own user- & groups-store the IPS replicates the assignments to the SAP applications via periodic execution of IPS-source & target jobs.
    • AMS based applications synchronize the assignments automatically in the background.
Hint

Future applications might use different technologies integrating with the Cloud Identity Services which would allow our customers an easy adoption.

Characteristics

This setup has the following characteristics:

  • The Identity Directory is the central point for the authorization assignments.
  • The authorizations are and remain domain specific - only the assignment is done centrally.

Services and Components

Resources