Explaining Identity and Access Management on SAP BTP

SAP Business Technology Platform (SAP BTP) distinguishes between platform users and business users:

• Platform users are usually administrators or operators (DevOps) who work with cloud management tools and deploy, administer, and troubleshoot services on SAP BTP. These are usually users who directly log on to the SAP BTP cockpit and work there. They can also be developers who work and use services in, for example, the Cloud Foundry environment.
• Business users are end users of business applications that are deployed on SAP BTP. These can also be users of subscribed services, such as SAP Business Application Studio, who work in the application directly and not via the SAP BTP cockpit. Custom extensions deployed by customers are typically also consumed by 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.

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.

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.

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.

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.

• Global Account: There's one predefined role collection for administrative tasks, and one for read-only access to the Global Account.
• Directory: When creating a new directory, you can assign administrator and viewer role collections to users. The viewer role collection grants read access to the directory, while the administrator role collection provides administrative access.
• Subaccount: If you assign the Subaccount administrator role collection to a user, you grant a user administration permission for the Subaccount. The viewer role only allows a user to view the Subaccount.

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).

• Org members: You can add new members manually by adding their e-mail address and choosing the role.
• Space members: Space Members are developers who work in a development environment. When creating a space member, you choose the required default role.

More information on predefined role collections and included roles is available here:Role Collections and Roles in Global Accounts, Directories, and Subaccounts.

To work with SAP BTP cockpit, you require a valid platform user. Users of an application deployed on SAP BTP are business users.

All users of SAP BTP are stored in identity providers, either in the default identity provider, which is the SAP ID service, the SAP Cloud Identity Services – Identity Authentication, or an integrated third-party identity provider.

SAP ID service is the default identity provider. The trust relationship with SAP ID service is configured by default, so it doesn't require any further configuration. This service is fully managed by SAP. Users then log on to the SAP BTP Cockpit with their SAP ID Service user credentials (typically SAP Universal ID). If the user doesn't have an SAP user account, it must first be created in the SAP ID service. Users from the SAP ID service are identified by their e-mail address and not their user ID. If you have multiple user accounts that share the same e-mail address, they all get the same authorizations. SAP ID Service can only provide users whereas custom identity providers can also provide user groups too.

Instead of SAP ID Service, you can use the SAP Cloud Identity Services – Identity Authentication. It can be used as an identity provider where you can manage your own user base. SAP Cloud Identity Services – Identity Authentication can be used for both platform and business users.

For more details, see Initial Setup of SAP Cloud Identity Services.

To use Identity Authentication as the identity provider, you must request an Identity Authentication tenant. This is done via a ticket. The tenant will be assigned to your Global Account. The Identity Authentication tenant can then be used directly as an identity provider with its own user store or as a central hub.

To use Identity Authentication for the platform users in the Global Account, you must establish a trust relationship between the Global Account and the IAS tenant. To use it for a Subaccount, you must establish trust between the Subaccount and IAS tenant. You can configure each of your Subaccounts to use other identity providers. This feature is configurable in the SAP BTP cockpit. This has to be done for each Subaccount because applications and services are deployed in Subaccounts. In this way, administrators can ensure that users stored in an identity provider, only have access to the Subaccounts or applications they require.

Next to the use of the SAP ID service and the SAP Cloud Identity Services, you can configure a third-party identity provider, such as Azure AD, which hosts your corporate user store. This means that you have full control over your user base. This can be any identity provider that supports SAML 2.0 or the OpenID Connect (OIDC) protocol. Using the OpenID Connect protocol is the recommended approach.

For configuring your custom identity provider, you have to configure a trust relationship. This is done manually by exchanging metadata files between the SAP BTP and the identity provider. For more information, you can have a look into the following SAP tutorial: Enable SSO Using Identity Authentication Service or just have a look into the documentation: Bringing Your Corporate Identity Provider for Platform Users