Analyzing User and Authorization Management on SAP BTP

Business Introduction to User and Authorization Management

As IT landscapes become more and more complex, the topic of security becomes more important.
Your company must manage application users (business users) and platform users (admins,
operators, and so on). You want to assign roles and authorizations and build a central identity
provisioning with the SAP Cloud Identity Services. All APIs and interfaces that are used or integrated
need to get secured as well.

User and Authorization Management on SAP BTP

Platform Users on SAP BTP

The SAP BTP is organized in global accounts on the highest level. A global account is a reflection of a
contract with SAP. It can consist of several directories and/or several subaccounts that provide
different applications and services to users. Further levels are in place for a better structuring and
organization of work. For example, if you have too many subaccounts in a global account, you can
create directories to structure them.

Subaccounts can have up to three environments: Cloud Foundry, Kyma or ABAP environment. The
environments allows the development and administration of business applications with different
approaches and tools based on your selection. Of course, inside of the environments and their
content, such as the runtime, service instances and so on - there are also users required for
providing access and authorizations.

Anyone who wants to use capabilities of the SAP BTP must be assigned as a user to the specific
authorizations through roles. User management happens at all levels from global account over
subaccount and directories to the environments. On each level, you require an administrator, who
administers resources and the users on those levels. The way to administer has some differences
depending on the level you are on.

User Management on SAP BTP

When a customer signs a contract with SAP, one user is created at the global account level. On this
level, entitlements are defined, assigning entities and services, including billing information. The
global account administrator can initially log on to SAP BTP to manage these entitlements, and
create directories and subaccounts. To ensure that more than one employee can administer the
global account, the administrator needs to create other users at the global account level and assign
them administrator permissions.

Typically, a global account consists of various subaccounts. When a global account administrator
creates a subaccount, they automatically become the administrator of the subaccount. The
subaccount administrator can manage entitlements, service subscription, create other users on the
subaccount level, and assign roles to the users. Subaccount administrators get administration
authorizations for the subaccount only, not for the global account.

Subaccount administrators also create business users. Business users are consumers of applications
and services that are provided on SAP BTP (for example: SAP Business Application Studio) or
business applications (SaaS) that were created with the help of the tools and services provided by
SAP BTP. These users can have access to SAP BTP, but they are not able to do any administrative
tasks. If a business user only uses a single application on SAP BTP, they do not necessarily require
access to the SAP BTP cockpit (meaning the subaccount), but to the application only. In this case, the
subaccount administrator creates the user on a subaccount level and only assigns application
authorizations to the user.

Roles and Authorizations

To use different functions of SAP BTP, you need to be authorized for it. You can configure
authorizations using roles and role collections.

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. You only assign role collections to
users, but not individual roles. Roles and their authorizations are provided automatically to users via
role collection assignment. 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 also for
application users. To set up administrator access for platform users in the global account,
directories, subaccounts, and so on, an existing administrator of a certain level on SAP BTP assigns
predefined role collections to other platform users.

For users of applications that can be subscribed on SAP BTP, there are also predefined role
collections that become available after application subscription. It is also possible to create custom
role collections with roles inside that give permissions for custom applications deployed on SAP BTP.

Roles

The roles are provided from the SAP BTP services you use and the developers delivering the role
templates for the services. When enabled from the service, it is possible to customize these role
templates. For a lot of scenarios, this is not possible and you need to go with the roles provided by
the service, and can start composing them into role collections and assigning these role collections
to users. It is also possible that the developers from a service provide role collection templates, but
besides that, you can always create own role collections.

Analyzing SAP Cloud Identity Services

Identity Providers

Applications and services in SAP BTP and even the SAP BTP cockpit do not store user information.
Instead, a redirect for authentication to an Identity Provider (IdP) is required. This concept makes it
possible to decouple and centralize authentication functionality from application capabilities and
authorization management. The SAP BTP offers the possibility to use the SAP ID Service or custom
Identity Providers from your IT landscape.

SAP ID Service is the default identity provider in SAP BTP. It is a pre-configured, standard SAP public
IdP (account.sap.com) that is shared by all customers. It has a pre-configured trust connection to all
SAP BTP subaccounts. The SAP ID Service is fully managed and provided by SAP and you are only able
to create a free user inside of this SAP ID Service. The SAP ID Service is also used for official SAP sites,
including the SAP developer and partner community. It is the place where the S-Users, P-Users and
D-Users are managed.

For many customers, users might be stored in corporate identity provider. SAP recommends using
SAP Cloud Identity Services – Identity Authentication Service (IAS) as a hub.

You can connect IAS as a single custom identity provider to SAP BTP. Further, you can use IAS to
integrate with corporate identity providers existing in your companies IT landscapes.

SAP Cloud Identity Services

The SAP Cloud Identity Services consists of two services: Identity Authentication and Identity
Provisioning. The Identity Authentication service is mainly responsible for the authentication &
single sign-on, while Identity Provisioning service takes care of the identity lifecycle management,
which includes both users and groups (things like create, change, delete, etc.).

SAP Cloud Identity Services - Identity Provisioning

Identity Provisioning service helps you provision identities and their authorizations to various cloud
and on-premise business applications. Identity Provisioning service offers you:

manage user accounts and authorizations

user stores in the cloud and on-premise

centralized end-to-end lifecycle management of corporate identities

fast and efficient administration of user on-boarding

and more.
SAP Cloud Identity Services - Identity Authentication

Identity Authentication provides simple and secure access to web based applications with a variety
of authentication methods at anytime and from anywhere. The service was previously know as SAP
Cloud ID service. The service has the task of validating the authentication between IdPs and the
applications itself that is based on supporting open standards like SAML, SSO, and more.

Identity Authentication offers you:

Secure and simple access through:

Identity federation based on SAML 2.0.

Web Single Sign-On SSO and desktop SSO.

Social login and two-factor authentication.

and more.

User and access management:

User administration and integration with on-premise user stores.

User self-service, for example, password reset, registration, and user profile maintenance.

Password and privacy policies.

and more.
IdP proxy features:

Reuse of existing SSO infrastructure.

Federation based on the SAML 2.0 standard.

and more.

Illustrating SAP Authorization and Trust Management Service (XSUAA)

SAP Authorization and Trust Management Service (XSUAA)

The XSUAA service, inside of the SAP BTP, handles the authorization flow between users, identity
providers, and the applications or services. The XSUAA service is an internal development from SAP
dedicated for the SAP BTP. In the Cloud Foundry project, there is an open-source component called
UAA. UAA is an OAuth provider which takes care of authentication and authorization. SAP used the
base of UAA and extended it with SAP specific features to be used in SAP BTP.

The XSUAA service takes care of authentication and authorization in SAP BTP, Cloud Foundry to give
business users permission through business roles. The XSUAA service does not store users data or
user records. The XSUAA service needs a trusted connection to an identity provider. This can be the
SAP ID Service or another corporate identity provider which was integrated to the SAP BTP. This can
be made via SAP Cloud Identity Services - Identity Authentication Service (IAS).

The XSUAA service acts as the central infrastructure component of the Cloud Foundry environment
at SAP BTP for business user authentication and authorization. SAP has enhanced the Cloud Foundry
UAA by adding a service broker, multi-tenancy, management API functions, and some minor
enhancements. XSUAA uses OAuth to authenticate between several services and connecting to the
identity provider.

OAuth is an open standard for applications and websites to handle authorization. OAuth doesn’t
share password data, but instead uses authorization tokens to prove an identity between consumers
and service providers. It is an authentication protocol that allows you to approve one application
interacting with another on your behalf without giving away your password. The tokens used from
OAuth are called JWT tokens. JWT (pronounced "jot") is an open standard that defines a compact
and self-contained way for securely transmitting information between parties. JWT is widely used in
OAuth for securely transmit user information and access rights.

App Router
When a business application consists of several different apps (micro-services), the application
router is used to provide a single-entry-point to the business application. Technically, an Application
Router is a Node.js based app, available in the public NPM registry. An App Router got started based
on a configuration file called xs-app.json. Inside of this file, it is defined which routes are served by
this App Router and which XSUAA service instance is bounded to the App Router to handle the
authentication requests.

An App Router is used to:

Serve static content or files

Authenticate users

Dispatch request to backend applications (micro-services)

In conclusion: The App Router is forwarding authentication requests to the XSUAA service, routing
between the apps or micro-services, and if existing in the project, the App Router is also serving
static resources like documents or images in a file system structure.