Objectives
This lesson summarizing the identity and access management concepts of SAP BTP.
This lesson contains the following topics:
SAP Business Technology Platform (SAP BTP) distinguishes between platform users and business users:
This differentiation between business and platform users is just on a logical level based on the authorizations a user receives. There's no technical difference between these two types of users. In reality, platform users may also have authorizations of business users but never the other way around.
Caution
The concept of platform and business users is only applicable to users of the SAP BTP cockpit, applications and services of SAP BTP, and the Cloud Foundry environment. The ABAP environment and Kyma environment follow a different approach, which will be explained later.
In some situations, it may be necessary to become an administrator of a Subaccount that you did not create and for which you do not have administrative rights. One example could be an urgent change when the admin is not available due to sickness, or another example could be when the original administrator left the company and forgot to assign a new administrator to the Subaccount. In these special cases, Global Account administrators have the option to force themselves to become a Subaccount Administrator by using the Add Me as Admin button in the SAP BTP cockpit.
Hint
This feature isn't available if it has been disabled for your global account. To disable this feature, send an opt-out request using the software component BC-NEO-CIS-OPS. You create this request like other requests and incidents in SAP for Me.
Subaccount administrators also maintain business users that are the consumers of applications and services that are provided on SAP BTP. This can also be custom implemented extensions and applications created with the help of the tools and services provided by SAP BTP. Business users don't need to have access to the SAP BTP cockpit and the architectural levels of SAP BTP like the Global Account, Directory, or Subaccounts. Business users only work within the business applications directly. The Subaccount administrator will create the business users on the Subaccount or environment level, and assign corresponding authorizations to them.
User and authorization management on SAP BTP happens at all levels, from your Global Account to your environments. Anyone who wants to use SAP BTP must be assigned as a user with the corresponding authorizations to a certain level. Environments constitute the actual platform as a service offering of SAP BTP that allows the development, administration, and deployments of business applications on a runtime. The user and authorization management of the environments is decoupled from the SAP BTP cockpit, but they get integrated into the SAP BTP cockpit in several places of the user interface.
As Cloud Foundry is very close integrated into the SAP BTP Cockpit, further levels are in place for a better structuring and organization of work. You need to be a member of the Cloud Foundry org. The Kyma environment and the ABAP environment follow different approaches, which are explained later in this unit.
To be able to use different functions on SAP BTP, you need to be authorized for them. In the SAP BTP cockpit, you can configure authorizations using roles and role collections.
Role collections consist of individual roles that combine authorizations for resources and services on SAP BTP. A Role collection can comprise of one or multiple roles.
Note
You can only assign Role Collections to a user, never a standalone Role.
Role collections are managed on each SAP BTP level separately. Role collections that exist in the Global Account do not exist in the Subaccounts. Likewise, role collections in Subaccounts are not available in the Global Account.
SAP BTP already delivers a predefined set of Role Collections for platform users and for business users. To set up administrator access for platform users in the Global Account, Directories, and Subaccounts, an existing administrator for the relevant level can assign predefined role collections to other platform users.
For users who work with applications and services that can be subscribed on SAP BTP, there are also predefined role collections that become available with the subscription. It's also possible to create custom role collections with roles inside that give permissions for custom applications deployed on SAP BTP. Custom deployed side-by-side extension can also create roles and role collections in SAP BTP, which can get assigned with the same approach.
Note
The identity provider hosts users, who can belong to user groups. It's efficient to use federation by assigning role collections to one or more user groups. The role collection contains all the authorizations that are necessary for that user group. This method saves time when you need to add new users. Simply add the users to the respective user groups and the new users will automatically get all the authorizations that are included in the role collection.
For more information, see Mapping Role Collections in the Subaccount.
SAP BTP offers predefined role collections and some default roles for platform users that help you ensure a segregation of duties, such as auditing or administration. An administrator can use predefined role collections and assign them to other platform users. This can be done in the SAP BTP cockpit, via a command line interface (CLI) or through the SAP BTP Terraform provider.
In Cloud Foundry, you create Cloud Foundry orgs and spaces, and you need to do the user and authorization management on each level separately. The users in orgs and spaces are called members. From there you can provide read and write permissions to members via default roles. This is done in the SAP BTP cockpit or via a command line interface (CLI).
More information on predefined role collections and included roles is available here:Role Collections and Roles in Global Accounts, Directories, and Subaccounts.
SAP Cloud Identity Services provide a robust suite of functions for managing user identities and access rights, encompassing single sign-on (SSO), multifactor authentication (MFA), and user provisioning. These services facilitate secure access management across various systems on the SAP Business Technology Platform (SAP BTP).
SAP Cloud Identity Services consist of a set of services within SAP BTP designed to enable seamless identity and access management across multiple systems. These services ensure a unified single sign-on experience and robust security measures to protect system and data access. Key components of SAP Cloud Identity Services include:
Manages user authentication through SAP’s default or third-party identity providers (IdPs).
Issues OpenID tokens based on the OAuth 2.0 protocol to enable secure user identity verification.
Aligns corporate roles and profiles with SAP BTP-specific roles and role collections to ensure appropriate user authorization.
Serves as the central repository for managing user and group information within SAP Cloud Identity Services.
Manages user authorizations and establishes trusted relationships with identity providers via SAP Authorization and Trust Management.
The following sections provide further details on each key service.
The Identity Authentication service is responsible for authenticating users. It allows the direct authentication and can delegate the authentication to a corporate IDP. The allowance of third-party IdPs, facilitates flexibility in identity provider integration.
The Token Service issues OpenID tokens, which are generated using the OpenID Connect (OIDC) protocol based on OAuth 2.0. These tokens enable seamless, secure identity verification and session management across integrated applications.
Identity Provisioning synchronizes and maps roles and profiles from the Corporate User Store to SAP BTP-specific roles and role collections. This service ensures that access rights are consistent with organizational policies, allowing efficient user authorization management across SAP applications.
Acting as a core component, the Identity Directory persists user and group data within the SAP Cloud Identity Services. It serves as the central source of truth for user and group information, supporting secure access and efficient identity management.
SAP Authorization and Trust Management service enables you to manage user authorizations across SAP applications. It also establishes and maintains trust with various identity providers, enabling secure SSO and access delegation.
Here is a high-level reference architecture that brings various components into focus.
You can read more about the SAP Cloud Identity Services here: SAP Cloud Identity Services
Authentication ensures that users accessing the platform are actually who they claim to be. This is done using a user name and password, biometric data, or MFA.
After creating a subaccount, the default identity provider is used for authentication by default. However, this does not offer the option of using user stores already used in the company, such as LDAP. For this reason, the following focus is on the use of an IAS tenant. This supports the use of SAP Cloud Identity Services.
The following SAP Cloud Identity Services can be used to authenticate a user:
The Identity Authentication service (IAS) is responsible for authenticating users to an identity provider. It supports both SAP’s native IdP as well as third-party IdPs, facilitating flexibility in identity provider integration. The IAS can be used for all SAP SaaS apps, such as SAP S/4HANA Cloud, SAP Ariba, and for the SAP BTP PaaS.
The IAS tenant is assigned on SAP BTP at subaccount level through the Trust Configuration. By default, after creating a subaccount, the default identity provider is configured, as shown in the following screenshot.
Default identity provider of the subaccount:
This checks against SAP's default identity provider when logging in to the global or subaccount.
As shown in the figure below, a Custom IAS tenant has been defined in the Trust Configuration and set to Default.
This allows users to be defined in the Custom IAS tenant against which authentication then takes place at the subaccount level.
The following figure shows the User Management Console in the Custom IAS tenant. A custom identity provider can also be configured there.
In the Discovery Center under Reference Architecture, there are two patterns that describe authentication in even more detail.
This reference architecture describes the authentication processes for SAP applications through SAP Cloud Identity Services – Identity Authentication. It's discussed there in great detail.
Authorization defines the resources an authenticated user can access on the SAP BTP platform, managed through role-based access controls (RBAC).
Authorization in SAP BTP is the process of assigning permissions to access platform resources, which include:
Authorizations are specific to each subaccount.
Authorization is managed through roles assigned locally to authenticated users within a subaccount, allowing access to specific applications.
A role is created from a role template and defines permitted access for an application, specifying the extent of the authorizations. Roles are grouped into role collections, which are then assigned to user groups or individual users. Many subscribed applications come with predefined role collections. This structure ensures that each user has the appropriate access for their tasks within SAP BTP.
The following is a screenshot of the role area on an SAP BTP subaccount:
The following figure shows the assignment of roles to role collections, which are then assigned to authenticated users. In this case, authentication takes place against the default SAP ID provider:
If the Default SAP ID Service is used, the users must be assigned individually.
User groups can only be created in the IAS tenant, such as the ADMIN group shown in the following figure. Users are then added to this group. These users must now authenticate themselves against the IAS tenant. This authentication can be carried out either against the users created in the IAS tenant or against a user store configured in the IAS tenant.
In the Subaccount, under Security → Trust Configuration the IAS tenant is assigned instead of the default SAP ID service.
The user group, for example, ADMIN, can then be added to a role collection under Security → Role Collections, as shown in the following figure.
With SAP BTP, software developers can build and deploy custom business applications and extensions. Software developers, together with architects and security experts, must ensure that a security concept for these custom applications is in place.
Caution
The concepts of this lesson are just applicable to applications deployed in Cloud Foundry or Kyma environment.
Customer-owned applications on SAP BTP should not be exposed to the internet because of security reasons. To prevent direct calls to the application, developers should use two additional components: the App Router and the SAP Authorization and Trust Management service (XSUAA).
Note
Developers can manually implement the entire authentication and authorization in the application coding itself. However, this approach is not recommended.
An App Router works as a central entry point to the application. It gets the requests from the web and acts as a client that forwards the request to the application. In parallel, it enables secure authentication. Technically, the App Router is a Node.js application where developers need to define the routes to which business application the user requests must be forwarded to. The information is stored in a JSON file (xs-app.json). The App Router is used in combination with the SAP Authorization and Trust Management service – XSUAA service – to authenticate a user and route the user to the business application with corresponding authorizations.
XSUAA is a service that helps to implement authentication and authorization. If you want to use the XSUAA service, you have to create an instance and bind it to your application. For each application, a single XSUAA instance can be used, or one XSUAA instance can be shared by multiple applications.
XSUAA service is not able to authenticate users because it does not store user data. So, a trust connection must be established with an identity provider.
Note
The XSUAA service is represented by an application security-descriptor JSON file (xs-security.json). The file defines properties of the XSUAA service instance to enable the authentication of the user when accessing an application. If user authorizations should be implemented, roles must be specified. The information in the file is used at application-deployment time to perform authentication and authorization checks.
Note
Find more information on the application-security descriptor JSON file here: Application Security Descriptor Configuration Syntax.
For secure access to the application using the App Router in combination with the XSUAA service, the authentication sequence is then the following:
To implement an authorization concept, developers need to maintain the application security-descriptor JSON file (xs-security.json), where they define different security options for an application by specifying the roles. The application security-descriptor file contains details of the authorization scopes, which are used for application access, and references any attributes that need to be applied. The developer can also provide application-based role templates there. The developers must have registered the role templates as OAuth 2.0 client in the User Account and Authentication (UUA) service, during application deployment.
Scopes are used for functional authorization checks. They provide a list of limitations regarding privileges and permissions and the areas to which they apply. They describe the authorizations required by the application to execute functions, such as editing, viewing, and deleting. Applications can perform scope checks, which are functional authorization checks with Boolean results.
An example of a scope could be display, which will only allow the HTTP GET method call in the application, or create, which will only allow the HTTP POST method call in the application.
Attributes are used to define instance-based authorizations, which change according to the context, for example, location, timezone, departments, or cost center. Attributes store information that is specific to the user, retrieved from the user's identity. They refine the authorizations of business users, according to the attributes that come with the user roles.
A role template references the scopes and the attributes if there are any defined. It describes a role and any attributes that apply to the role. For example, there's a Viewer role template that only references the display scope. In this case, the user should only be allowed to view the data in the application. There's also a Manager role that references the scopes display and update. In this case, the user should be allowed to view and change the data in the application.
Roles are created based on the role templates at the configuration time. This is done by the administrator in the SAP BTP cockpit.
Note
If a role template does not reference any attributes, then a role is generated automatically with the same name as the role template.
If attributes are referenced by a role template, a role cannot be generated automatically. The reason is that specific attribute values must be set, which are subject to customization and, as a result, can't be provided automatically. This customization (meaning setting the attribute values) is done by the administrator when creating a role from a role template.
In the application security-descriptor JSON file, developers can also define role collections with predefined Roles. Administrators can use these predefined role collections. They can assign them to users during the initial setup of SAP BTP. The creation of predefined Role Collections is optional.
Role templates appear in SAP BTP cockpit under Security → Roles. Administrators create application-based Roles derived from role templates. For each attribute that the developer referenced in a role template, administrators can specify the value that restricts data access.
There are multiple sources of attributes:
In this case, there's no need to set a specific value for this attribute. The behavior is the same as if the attribute would not exist for this role.
A developer created a Fiori application, where business users can manage sales orders. There's a senior sales order manager, Nancy, who should be able to view and create sales orders for customers in all regions (for example, USA, Europe, and Asia). There's also an associate sales order manager, Marc, who should be allowed to see sales orders only for customers in a specific region (for example, Europe).
To differentiate between the two access options, the developer creates a role template and defines a manager and viewer scope. With the attributes, the authorizations for accessing regions data can be refined. This would mean that Nancy should get a manager role with unrestricted data access, and Marc should get a viewer role with a defined attribute value for the regions that equal Europe.
If a role template contains attributes, the administrator must create different versions of the roles and fill in the attributes that are subject to customization; for example, one where region equals Europe and another where region equals USA. This instantiates a role, otherwise the roles would have empty attributes (with no concrete values).
Log in to track your progress & complete quizzes