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
A trust connection to the default identity provider – SAP ID service – is established by default.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
The explanationbefore this is valid for custom applications that are accessed by business users in the Cloud Foundry and Kyma environments. For these applications, a respective instance of the XSUAA service must be created, and the applications must be bound to it.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:
- When the user access the business application, the request is sent to the App Router.
- The App Router acts as an OAuth client and forwards the access request to the XSUAA service.
- Since the XSUAA service does not store user data, it forwards the request to the identity provider to enforce the authentication of the user. If the identity exists in the user store of the identity provider, the authentication of the user is successful.
- The authentication against XSUAA is successful and the service generates an access token, called JSON Web Token (JWT), and passes it back to App Router.
- As the JWT token is needed to authenticate the user at the business application, the JWT token get forwarded to it.
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
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
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.
Role Template
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.
Predefined Role Collections
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:
- Static attributes that have a static value assigned in the SAP BTP cockpit
- Attributes from an identity provider
- Unrestricted 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.
Example
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).