orkungedik/SAP-basis-dataset huggingface dataset:
## 7.1.5.3.24  Missing Administrator Access to SAP Business Technology Platform
You have issues with managing subaccounts and editing entitlements in SAP BTP. Add a user with global account administrator permissions. This administrator is then authorized to perform these tasks.
## Symptom
You want to create or delete a subaccount in SAP BTP, but your user isn't authorized to do so.
You want to edit the entity assignments in the SAP BTP entitlements, but the Edit button is not available.
## Reason and Prerequisites
- You don't have a user who has administrator persmissions for the global account in the SAP BTP cockpit.
## Solution
Follow the steps described in the link below.
For more information, see SAP Note 3148626 .
## 7.1.5.3.25  Unexpected User in Subaccount
## Symptom
As a subaccount administrator, you find a user you didn't add to your subaccount and are concerned how it got there.
## Reason and Prerequisites
- Another subaccount administrator added the user without your knowledge.
- The user was added by a background job, which syncs the Cloud Foundry users from orgs or spaces in that subaccount.
- The user was unexpectedly added by a provisioning job.
## Solution
Check the audit log of the SAP Authorization and Trust Management service. See Auditing and Logging Information for SAP Authorization and Trust Management Service [page 3198].
There, you can see who created the user and coordinate your processes.
- If the creator was the CLOUD\_FOUNDRY\_SNYC user, the user was created by the background job for synchronizing Cloud Foundry users. If you don't want SAP BTP to create these users you can disable this job for your subaccount. See Switch Off Automatic Creation of Shadow Users [page 2341].
- If the creator was a provisioning job, check with the solution used for provisioning and check for errors in configuration. For more information, see Provision Users to SAP BTP Accounts [page 2348].
## Related Information
Working with Users [page 2342]
About User Management in the Cloud Foundry Environment [page 2509] Add Members to Your Subaccount [page 2253] Add Members to Your Global Account [page 2211]
## 7.1.5.3.26  There Was an Error When Authenticating Against the External Identity Provider
## Symptom
You have configured a custom identity provider for applications in the SAP BTP cockpit, such as the SAP Cloud Identity Services.
When you open an SAP BTP application, such as a custom developed application or a subscribed application like SAP Business Application Studio, you receive the following error:
There was an error when authenticating against the external identity provider: The user account must be pre-created. Please contact your system administrator.
## Reason and Prerequisites
The user from the custom identy provider for applications doesn't exist in the list of users of the SAP BTP cockpit.
When a user authenticates at an application in your subaccount using any identity provider, the User Account and Authentication always stores user-related data provided by the identity provider in the form of shadow users. It uses details of the shadow users to issue tokens that refer to a specific user.
By default, the User Account and Authentication allows any user of any connected identity provider to authenticate to applications in the subaccount. When there's no corresponding shadow user, it automatically creates one based on the information received from the identity provider.
However if Create Shadow Users on User Logon is turned off, shadow users aren't created, which causes the issue.
## Solution
To resolve the issue, use one of the following options:
- Enable Create Shadow Users on User Logon for the custom identity provider in the SAP BTP cockpit:
1. In the SAP BTP cockpit, go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Trust Configuration .
2. Select your custom identity provider for applications.
3. Choose Edit .
4. Activate Create Shadow Users During Logon .
5. Choose Save .
- Manually create a user for yor the respective identity provider in the SAP BTP cockpit (see Create Users [page 2347]).
1. In the SAP BTP cockpit, go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Users .
2. Create a new user for the respective identity provider by using Create .
- Use the SAP Cloud Identity Services - Identity Provisioning to import users from a source system to the respective subaccount. Follow the instructions in SAP BTP XS Advanced UAA (Cloud Foundry).
##  Note
After creating the users in the subaccount, add the relevant role collection for users. The users must have the authorization to access the application (see Assign Users to Role Collections [page 2355]).
## Related Information
Create Users [page 2347]
Switch Off Automatic Creation of Shadow Users [page 2341] SAP BTP XS Advanced UAA (Cloud Foundry)
## 7.1.5.3.27  Common Authorization Issues in SAP Integration Suite
Find help about authorization issues with SAP Integration Suite.
## I assigned the correct role collections to my user but still can't access SAP Integration Suite
After subscribing to the application and assigning roles, clear your browser cookies and cache. Then, sign out of the SAP BTP cockpit and SAP Integration Suite, and sign in again.
If the issue persists, raise a ticket under the component you're trying to access. See SAP Note 2904202 .
## I subscribed to SAP Integration Suite, but I want to know more about the role collections I need to work with the different capabilities
The following table lists the most common capabilities of SAP Integration Suite, and the role collections needed for them.
| Role Collection                                                           | Capability                                   |
|---------------------------------------------------------------------------|----------------------------------------------|
| Integration_Provisioner                                                   | Gain initial access to SAP Integration Suite |
| PI_Read_Only PI_Business_Expert PI_Integration_Developer PI_Administrator | Cloud Integration                            |
| APIManagement.SelfService.Administrator AuthGroup.SelfService.Admin       | API Management                               |
| PI_Integration_Expert PI_Business_Expert PI_Administrator PI_Read_Only    | Trading Partner Management                   |
| iadv-content-developer iadv-content-administrator iadv-content-read       | Integration Advisor                          |
You can find more information and learn about other capabilities in the documentation for SAP Integration Suite:
- Subscribing and Configuring Initial Access to Integration Suite
- Configuring User Access
For more information about role templates, such as AuthGroup\_BusinessExpert or AuthGroup\_Administrator , see Identity and Access Management.
For more information on predefined technical roles, such as ESBmessaging.send , see the SAP Integration Suite documentation.
## 7.1.6  Security Considerations for the SAP Authorization and Trust Management Service
Decisions you make when using or administrating the SAP Authorization and Trust Management service (XSUAA) can have an impact on the security of your applications. The information provided is meant to help you decide.
## Related Information
Configuration Options for the SAP Authorization and Trust Management Service [page 3239]
## 7.1.6.1 Implications of Using IFrames
By default, applications of the subaccount, including login pages of the SAP Authorization and Trust Management service can't be framed by other applications for security reasons.
As the security administrator of a subaccount, you can allow the embedding applications of the subaccount in an iFrame.
To configure the trusted domains, use one of the following methods:
- Enter trusted domains in the SAP BTP cockpit. For more information, see Configure Trusted Domains for Multi-Environment Subaccounts [page 2393].
- Access the Security Settings API.
```
"iframeDomains": "https://store.example.com"
```
For more information, see Security Settings API on SAP Business Accelerator Hub .
##  Remember
To use iFrames with SAP Authorization and Trust Management service, configure the embedding of the login page of your identity provider. Not all identity providers support framing. This function only works if the identity provider supports framing and is configured, too.
To use iFrames with other applications of the subaccount, which support this feature, configure the domains used by these applications.
To configure iFrames for SAP Cloud Identity Services, see Configure Trusted Domains in the documentation of SAP Cloud Identity Services.
When configured, the SAP Authorization and Trust Management service sends a content security policy header allowing framing of the application for the domains you specified.
For more information about content security policies, see the World Wide Web Consortium (W3C) recommendation Content Security Policy .
This configuration has several security implications like:
- Clickjacking attacks on the application as the URL of the application isn't visible.
- JavaScript-based cross-site scripting vulnerabilities of older browser versions.
- Third-party cookies are required when using different domains for authentication with the SAP Authorization and Trust Management service, the identity provider, and the application. See also Third-Party Cookies and SAP Authorization and Trust Management Service [page 3240].
Ensure that no attacker can add malicious web pages or Javascript to any of the hosts allowed to frame the applications. This recommendation also includes hosts that act as reverse proxies, where an attacker can put their content on a different host behind the reverse proxy. Ensure that everything exposed by those framing hosts is safe.
## 7.1.6.2 Listing Allowed Redirect URIs
When developing your application, provide the list of the redirect URIs that the application needs when redirecting, for example during login or logout. Enter the list in the redirect-uris property of the application security descriptor ( xs-security.json ).
At runtime, the SAP Authorization and Trust Management service checks whether the redirect URI is listed in the property and rejects any other URIs. If your redirect isn't on this list, including wildcards, the service won't redirect users there.
The following is an example of a configuration of the redirect-uris property in an xs-security.json .
```
"oauth2-configuration": { … "redirect-uris": [ "https://myapplication.cfapps.eu10-004.hana.ondemand.com", "https://myapplication.cfapps.eu10-004.hana.ondemand.com/my/content", "https://myapplication.mydomain.com", "https://myapplication.mydomain.com/my/content" ], … }
```
##  Recommendation
Set the redirect-uris property to restrict access as much as possible.
We support explicit wildcards, namely domain relaxing and arbitrary paths. For example: "https://
*.mydomain.com/callback/**"
##  Caution
If you use wildcards, we recommend that you make your URIs as specific as possible. By using wildcards, you open up the redirect for multiple websites. Wildcards increase the risk of redirecting to malicious websites.
##  Note
In cloud landscapes, only localhost is always allowed by default as a redirect URI.
## Related Information
Application Security Descriptor Configuration Syntax [page 576] Configure Redirect URLs for Browser Logout [page 566]
## 7.1.6.3 Rotating Secrets
By default, all bindings of a service instance of the SAP Authorization and Trust Management service share a single instance secret. (Exception: Service instances with the apiaccess plan use a secret per binding by default.) In the application security descriptor ( xs-security.json ), enable individual secrets for each binding of a service instance.
We recommend this configuration so that you can rotate the secret of a binding without affecting the other bindings of the service instance. We also recommend that you rotate secrets regularly.
For more information, see Managing Secrets of the SAP Authorization and Trust Management Service [page 2371].
```
"oauth2-configuration": { … "credential-types": ["binding-secret"], … }
```
For more information about the application security descriptor, see Application Security Descriptor Configuration Syntax [page 576].
## 7.1.6.4 Setting Token Policy
By default, SAP Authorization and Trust Management service sets the validity of tokens as shown in the following table.
Default Validity of Tokens
Token Type
Validity
| Access tokens   | Default: 43200 seconds (12 hours)   |
|-----------------|-------------------------------------|
| Refresh tokens  | Default: 604800 seconds (7 days)    |
On request, SAP Authorization and Trust Management service issues access and refresh tokens.
With a valid access token, you can access a protected resource. Once an access token expires, you can get new access tokens with a refresh token. Once the refresh token expires, you must reauthenticate and request new access and refresh tokens.
See also Authorization for information on how tokens affect authorizations.
##  Recommendation
Relaxing the token policy means that users reauthenticate less. However, increasing the token validity also means that if a malicious user manages to steal a token, that malicious user has access until the token expires. Keep token validity as short as possible, but not less than 30 minutes.
To change token validity, use one of the following methods:
- To target a specific instance of the service, change the values of the token-validity or refresh-token-validity parameters in the application security descriptor ( xs-security.json ).
```
"oauth2-configuration": { … "token-validity": 1800, "refresh-token-validity": 43200, … }
```
##  Note
This change applies to applications, which consume or subscribe to this instance. These values override the values set for the subaccount.
For more information about the application security descriptor, see Application Security Descriptor Configuration Syntax [page 576].
- To target the subaccount in general, access the Security Settings API.
```
"tokenPolicySettings": { … "accessTokenValidity": 1800, "refreshTokenValidity": 43200, … }
```
##  Note
This change applies to all service instances in the subaccount that haven't set a specific value in the application security descriptor ( xs-security.json ).
For more information, see Security Settings API on SAP Business Accelerator Hub .
## 7.1.6.5 Access to REST APIs
The apiaccess plan provides administrator-level access to REST APIs of the SAP Authorization and Trust Management service. Ensure that only administrators have administrator access to Cloud Foundry spaces where service instances with this plan exist.
To use this service plan, create a separate Cloud Foundry space in your subaccount. Only assign administrator users the Space Manager and Space Developer roles in this space as well as the Org Manager role in the parent Cloud Foundry org. Use this Cloud Foundry space to create the apiaccess plan service instance.
Administrators are any SAP BTP cockpit users with the User and Role Administrator role. This role is part of the Subaccount Administrator role collection, but can be included in other role collections.
## Related Information
About Roles in the Cloud Foundry Environment [page 2510] Default Role Collections of SAP BTP [page 3251]
## 7.1.6.6 Training Business Users How to Handle Session Timeouts
Administrators should make business users aware of a possible security risk after single logoff. A business user might get a message saying that this user is being logged off from the application although the identity provider session was not terminated.
The reason for this message comes from a timeout mismatch between the application and the SAP Authorization and Trust Management service. The timeout of the SAP Authorization and Trust Management service is currently 30 minutes. After the timeout, the SAP Authorization and Trust Management service does not forward the logoff request to the identity provider. This situation incurs a security risk.
##  Recommendation
To remedy this security risk, advise the business users to access the application URL again, log on to the application, and log off right away, or log off directly from the identity provider.
## 7.1.7  Configuration Options for the SAP Authorization and Trust Management Service
The following configuration options enable you to manipulate the operation of the SAP Authorization and Trust Management service (XSUAA). Set these options in the application security descriptor ( xs-security.json ) at design time for your application.
## Related Information
Security Considerations for the SAP Authorization and Trust Management Service [page 3234]
## 7.1.7 .1 Disabling System Attributes
Access tokens can become overloaded with too many SAML group or role collection attributes. By default, the SAP Authorization and Trust Management service includes all system attributes in the tokens the service issues.
If the number of attributes cause the token size to exceed 16k, you get HTTP error code 400. To avoid this problem, set the system-attributes parameter in the application security descriptor ( xs-security.json ).
```
"oauth2-configuration": { … "system-attributes ": [], … }
```
For more information about the application security descriptor, see Application Security Descriptor Configuration Syntax [page 576].
See also 400 Error: Call to /oauth/token Was Not Successful in Guided Answers .
## 7.1.7 .2 Preconfigured Role Collections
In the application security descriptor ( xs-security.json ) of your application, you define the authorizations needed to access your application. You define these authorizations as scopes within roles and role templates. From these entities, the administrator can build role collections and assign the role collections to users.
We recommend that you also define role collections for administrators to consume with your application. Delivering role collections with your application has the following advantages:
- Time savings for the administrator.
- The administrator of the subaccount can consume your application more quickly.
- Offer examples of well-defined role collections. The administrator can learn from your example, the security model of your application and design his or
her own role collections based upon that model.
For more information about authorizations, see Authorization Entities [page 3193].
```
"role-collections": [ { "name": "Employee", "description": "Employee roles", "role-template-references": [ "$XSAPPNAME.Employee" ] } ]
```
For more information about the application security descriptor, see Application Security Descriptor Configuration Syntax [page 576].
## 7.1.7 .3 Asynchronous Processing for Multi-Tenant Applications
After your application has more than 50 subscriptions, the time required to update instances of SAP Authorization and Trust Management service bound to your application increases. This delay can run into the timeouts set by the Cloud Controller of Cloud Foundry and SAP Service Manager.
To avoid timeout, enable asynchronous processing in your application security descriptor ( xssecurity.json ). T o enable asynchronous processing, set the xsenableasyncservice parameter to true .
"xsenableasyncservice":"true"
For more information about the application security descriptor, see Application Security Descriptor Configuration Syntax [page 576].
## 7.1.8  Third-Party Cookies and SAP Authorization and Trust Management Service
Browser manufacturers are phasing out support for third-party cookies. This change can prevent embedded BTP applications and their logon screens from functioning.
To prevent your logon scenarios from failing, make sure that all multi-environment subaccounts, which contain these embedded applications, are configured to use a tenant of SAP Cloud Identity Services as the trusted identity provider.
##  Caution
Migrate your trust before the browser vendors phase out support.
Trusting your SAP Cloud Identity Services tenant enables your applications to integrate with the overall solution provided by SAP.
For more information about the overall solution, see SAP BTP and Third-Party Cookies Deprecation and SAP Note 3409306 .
To migrate an existing trust configuration, see Migration from SAML Trust to OpenID Connect Trust with Identity Authentication.
If your framing and framed applications run under different domains, you must still maintain trust between the domains as before. For more information, see Configure Trusted Domains for SAP Authorization and Trust Management Service [Feature Set B].
##  Recommendation
Test your solutions before third-party cookies have been phased out. To test how your solutions function once third-party cookies have been phased out, enable the partitionedCookies property of the Security Settings API of the SAP Authorization and Trust Management service and run your tests. If your business scenarios fail, set partitionedCookies to false to help troubleshoot the source of the problem.
For more information, see the following:
- How to test: Preparing and Testing Your Solution for Third-Party Cookie Phase-Out
- How to use the API: Accessing Administration Using APIs of the SAP Authorization and Trust Management Service
In subaccounts created before May 30, 2024, the partitionedCookies property has a default value of false . In subaccounts created afterward, the property has a default value of true . When Google begins large-scale phase-out of third-party cookies, we plan to set this property to true and read-only in all subaccounts.
## Related Information
Trust and Federation with Identity Providers [page 2280]
## 7.1.12  Configuring Backup
For SAP Authorization and Trust Management Service, you can backup the service configuration, the authorizations, and the configuration of the identity provider using APIs.
You can back up your configurations with the SAP Authorization and Trust Management service API package available on the SAP Business Accelerator Hub . The following configurations are included.
- Roles: You can back up role configurations with the Authorization API.
- Role collections and role collection assignments: You can back up configurations for role collections and role collection assignments with the System for Cross-domain Identity Management (SCIM) API.
- Identity provider configurations: You can back up identity provider configurations with the Identity Provider Management API.
For more information on backup, see SAP BTP Service Configuration Backups Managed by Customers.
## 7.1.13  Accessibility Features in SAP Authorization and Trust Management Service
To optimize your experience of the SAP Authorization and Trust Management service, SAP Business Technology Platform provides features and settings that help you use the software efficiently.
##  Note
SAP Authorization and Trust Management service runs on the SAP BTP cockpit. For this reason, accessibility features for SAP BTP cockpit apply. For more information, see the accessibility documentation for SAP BTP cockpit on SAP Help Portal in Accessibility Features in SAP BTP cockpit [page 2206].
For more information on screen reader support and keyboard shortcuts, see the Accessibility for End Users.
## 7.3 Trusted Certificate Authentication
All components of SAP BTP rely on a list of trusted Certificate Authorities (CAs), which differ depending on the runtimes used.
For your scenarios with SAP BTP, be aware of this list of CAs to ensure that you can provide trusted certificates that are signed by a trusted CA.
A list of all root CAs approved by SAP Global Security is available in SAP Note 2801396 (SAP Global Trust List).
## 7.4 Principal Propagation
Exchange user ID information between systems or environments in SAP BTP.
## In This Section
- Principal Propagation from the Multi-Cloud Foundation to the Neo Environment [page 3264]
- Principal Propagation from the Neo Environment to the Multi-Cloud Foundation [page 3257]
## Other Principal Propagation Scenarios
- On-Premise User Store
- Principal Propagation to OAuth-Protected Applications
- Connectivity in the Cloud Foundry Environment: Principal Propagation
- Connectivity in the Neo Environment: Principal Propagation
## Related Information
Propagate User Information Between Applications or Services [page 539]
## 7.4.1.2 Create Trust Between the Subaccounts
## Procedure
1. In the cloud cockpit, log on with the Administrator user.
2. Save locally the service provider metadata of the subaccount in the Neo environment.
- a. In SAP BTP cockpit, navigate to the subaccount in the Neo environment. See Navigate in the Cockpit [page 2207]
- b. Navigate to Security Trust Local Service Provider .
- c. Choose Get Metadata and save the metadata file representing this subaccount.
3. In the subaccount in the Cloud Foundry environment, create trust to the subaccount in the Neo environment.
- a. Navigate to the subaccount in the Cloud Foundry environment.
- b. Navigate to Security Trust Configuration
- c. Choose New Trust Configuration .
- d. In the Metadata field, choose the Upload button.
- e. Upload the service provider metadata file representing the subaccount in the Neo environment.
- f. Save the new trust configuration.
After this procedure, you can use the security context from the application in the Neo environment to the application in the Cloud Foundry environment. The assigned groups from the Neo environment can be used as role collections in the Cloud Foundry environment.
## 7.4.2  Principal Propagation from the Multi-Cloud Foundation to the Neo Environment
Enable an application in your multi-environment subaccount (for the multi-cloud foundation) to access an OAuth-protected application in a subaccount in the Neo environment without user login (and user interaction) in the second application. For this scenario to work, the two subaccounts need to be in mutual trust, and in trust with the same identity provider. The first application will propagate its logged-in user to the second application using an OAuth2SAMLBearer destination.
The graphic below illustrates the overall setup of the scenario.
<!-- image -->
## Prerequisites
- You have a user account with Administrator role in both SAP BTP subaccounts. See Managing Member Authorizations in the Neo Environment.
- You have a custom local service provider configuration (this means in cloud cockpit Security Trust Local Service Provider you have chosen Configuration Type Custom ) in your subaccount in the Neo environment. See Configure the Local Service Provider.
- Both accounts have a trust configuration to the same identity provider. See:
- Configure Trust to the SAML Identity Provider (for the Neo environment)
- Establish Trust with Any SAML 2.0 Identity Provider in a Subaccount [page 2306] (for the multi-cloud foundation)
- The application in the Neo environment is protected using OAuth 2.0. See OAuth 2.0 Service.
- The application in the multi-environment subaccount is bound to an instance of the following services:
- Destination Service . See Create and Bind a Destination Service Instance.
- xsuaa
- You have deployed both applications, each in the corresponding subaccount.
##  Note
All configuration steps described in this tutorial are done using the cloud cockpit.
## Contents
- Create Trust Between the Subaccounts [page 3266]
- Create an OAuth Client [page 3267]
- Create a Destination [page 3268]
## 7.4.2.1 Create Trust Between the Subaccounts
Exchange keys and certificates between the subaccounts, and configure trust between them. This will enable the subaccounts to communicate using HTTP destinations.
## Procedure
1. In the cloud cockpit, log on with the Administrator user.
2. Save locally the identifying X509 certificate of the subaccount in the Cloud Foundry environment.
- a. In SAP BTP cockpit, navigate to the subaccount in the Cloud Foundry environment.
- b. Navigate to Connectivity Destinations .
- c. Choose Download Trust and save the X509 certificate identifying this subaccount.
3. In the subaccount in the Neo environment, create trust to the subaccount in the Cloud Foundry environment.
- a. Navigate to the subaccount in the Neo environment.
- b. Navigate to Security Trust Application Identity Provider .
- c. Choose Add Trusted Identity Provider and configure the new trust configuration settings:
- In the Name field, enter the following: &lt;your Cloud Foundry domain host&gt;/&lt;Cloud Foundry subaccount ID&gt;
 Tip
You can view the Cloud Foundry domain host in cockpit &lt;your global account&gt; &lt;your subaccount&gt; &lt;your space&gt; Routes .
<!-- image -->
<!-- image -->
- In the Signing Certificate field, enter the X509 certificate of the Cloud Foundry account.
##  Note
Make sure you remove the BEGIN CERTIFICATE and END CERTIFICATE parts.
- Mark the Only for IDP-initiated SSO option.
- d. Save the new trust configuration.
## 7.4.2.2 Create an OAuth Client
You need an OAuth client to get an access token for the OAuth-protected resources in the application in the Neo environment.
## Context
For more information about working with OAuth clients, see Create an OAuth Client [page 3267].
## Procedure
1. In the cockpit, navigate to the subaccount in the Neo environment.
2. Navigate to Security OAuth Clients , and choose Register New Client .
3. Create an OAuth client with the following configuration settings:
- Name - the OAuth client name. You will need to provide this name as value of the Token Service User property of the destination below.
- Authorization Grant - choose the Authorization Code option.
- Mark the Confidential option, and provide a secret (password).
4. Save the client.
##  Note
When creating the required OAuthSAMLBearer destination later, you will need the following information from the OAuth client:
- ID
- Secret
## 7.4.2.3 Create a Destination
## Context
Connect the two subaccounts by describing the connection properties in a destination. For more information, see Modeling Destinations.
## Procedure
1. Choose the subaccount in the Cloud Foundry environment, and navigate to Connectivity Destinations .
2. Choose New Destination .
3. In the new destination, provide the following information:
| Field       | Description                                                                                                                                  |
|-------------|----------------------------------------------------------------------------------------------------------------------------------------------|
| Name        | Technical name of the destination. It can be used later on to get an instance of that destination. It must be unique for the global account. |
| Description | Free-text description.                                                                                                                       |
| Type        | HTTP                                                                                                                                         |
| URL         | The URL of the protected resource in the Neo environment. Example: https://myneoapp.hana.ondemand.com/myprotectedresource/                   |
<!-- image -->
Client Key The ID of the OAuth client for the application in the Neo environment.
## Field Description
<!-- image -->
Token Service User The ID of the OAuth client for the application in the Neo environment.
Token ServThe secret from the OAuth client.
ice Pass- word
System User authnCon-
textClass-
Ref nameIdFor-
mat
Empty.
urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified if the user ID will be propagated to the Neo application or nameIdFormat = urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress if the user email will be propagated to the Neo application.
<!-- image -->
4. Save the changes.
## 7.5.2  Change Logging and Read-Access Logging
Change logging records changes to personal data, while read-access logging records access to sensitive personal data. You may be required to gather this information for auditing purposes or legal requirements.
Use the appropriate API to retrieve logs.
- For the Cloud Foundry, see Audit Log Retrieval API Usage for Subaccounts in the Cloud Foundry Environment [page 2597].
##  Note
For any applications you develop, you must ensure they include logging functions. SAP BTP does not provide audit logging functions for custom developments.
Logs are deleted regularly.
## 7.5.3  Personal Data Record
A personal data record is a collection of data relating to a data subject. A data privacy specialist may be required to provide such a record or an application may offer a self-service.
To see the personal data that is used for membership management within SAP BTP, access the cloud cockpit.
1. Navigate to the global account to which you'd like to view members. For more information, see Navigate to Orgs and Spaces [page 2512].
2. In the navigation area, choose Members .
To see the personal data that is used for application logging within SAP BTP, access the cloud cockpit.
For more information, see Using Logs in the Cockpit or Analyze Logs from the Cockpit in the Application Logging service documentation.
If you do not use your own identity provider for identity federation, you can view the profiles available in SAP Cloud Identity Services - Identity Authentication.
For more information, see Information Report in the SAP Cloud Identity Services - Identity Authentication documentation.
For SAP BTP Cloud Foundry environment, the User Account and Authentication service creates shadow users to issue tokens for their corresponding users.
For more information about viewing shadow users and their attributes, see the User Management (SCIM) API on SAP Business Accelerator Hub .
For all other services, which persist data, such as databases or document services, retrieve the data you stored with the same APIs, protocols, or languages you used to store the data.
To view the services used in a global account, choose Entitlements in the navigation area.
## 7.5.4  Deletion
The processing of personal data is subject to applicable laws related to the deletion of this data when the specified, explicit, and legitimate purpose for processing this personal data has expired. If there is no longer a legitimate purpose that requires the retention and use of personal data, it must be deleted.
When deleting data in a data set, all referenced objects related to that data set must be deleted as well. Industry-specific legislation in different countries also needs to be taken into consideration in addition to general data protection laws. After the expiration of the longest retention period, the data must be deleted.
When accounts expire, we delete your data barring legal requirements that SAP retains your data. If your organization has separate retention requirements, you are responsible for saving this data before we terminate your account.
- For trial accounts in the Cloud Foundry environment, your account expires after 365 days.
- Productive accounts expire based on the terms of your contract.
To deactivate or delete users, see Erasure in the SAP Cloud Identity Services documentation.
For SAP BTP Cloud Foundry environment, the User Account and Authentication service creates shadow users to issue tokens for their corresponding users. Data privacy regulations or policies may require you to delete this data, for example, when the user has left your organization.
For more information about deleting shadow users, see:
- Delete Shadow Users for Data Protection and Privacy Using the Cockpit [page 3279]
- Delete Shadow Users for Data Protection and Privacy Using APIs [page 3282]
##  Remember
When you delete a user at the Cloud Foundry level, SAP BTP doesn't delete the corresponding shadow user at the subaccount level.
When you delete a user at the subaccount level, ensure that you delete the user at the Cloud Foundry level too. Otherwise, if the Cloud Foundry user logs on again, the system automatically creates the corresponding user at the subaccount level.
So ensure that you delete the shadow users on all levels.
For all other services which persist data, you can retrieve the data you stored with the same APIs, protocols, or languages which you used to store the data.
To view the services used in a global account, choose Entitlements in the navigation area.
SAP BTP Data Retention Manager is a service available for the Cloud Foundry environment that helps you to identify data subjects for deletion as well as maintain rules for residence and retention.
For more information, see SAP BTP Data Retention Manager.
We maintain backups of the data for disaster recovery. When your account is deleted, we may have this data in our backup system for the length of our backup cycle.
##  Note
If your data is stored outside SAP BTP, we cannot guarantee that your data does not get reintegrated if you are pushing such data to our systems. You are responsible for terminating such integrations.
We cannot restore data you have in your local system.
## 7.5.5  Consent
SAP BTP supports you in collecting and managing the consent of data subjects in the following ways:
SAP Cloud Identity Services provides tools to manage privacy policies and terms of use agreements.
For more information, see Configuring Privacy Policies and Configuring Terms of Use in the SAP Cloud Identity Services documentation.
See also Consent in the SAP Cloud Identity Services documentation.
## 7.6 Security in the Kyma Environment
Security in SAP BTP, Kyma runtime comprises the following pillars:
- Kyma Security Concepts [page 3284]
- Secure Administration and Operations in the Kyma Environment [page 3296]
- Secure Development in the Kyma Environment [page 3290]
Go to the respective topics to learn more about the security features and configurations they propose.
## 7.6.1.1 Security Vulnerability Management in the Kyma Environment
SAP employs a vulnerability management process to ensure the security of SAP BTP, Kyma runtime. Within this process, we identify, assess, prioritize, remedy, and monitor vulnerabilities. We also provide hotfixes between regular releases for critical vulnerabilities that our security organization identifies.
SAP regularly scans SAP-owned code and the container images that are part of SAP BTP, Kyma runtime, Kyma Control Plane, and Kyma dashboard for known and potential vulnerabilities. The following security scanning technologies are used:
- Static application security testing (SAST) for the proprietary code
- Open source vulnerability management (OSVM) for open-source software that is part of Kyma runtime
##  Note
SAP runs security scans for Kyma runtime, and you, as a customer, are responsible for scanning your own workloads added to the Kyma cluster. For details, see Operating Model in the Kyma Environment. [page 3324]
The scanning results are constantly monitored and addressed. Vulnerabilities are handled with software updates. If an update is not available, the vulnerability is subject to further analysis to identify its associated risk and implement appropriate measures. For critical vulnerabilities identified by SAP's security organization, hotfixes are applied between regular releases.
##  Remember
Kyma development teams analyze each vulnerability to assess its actual severity in the Kyma environment. Therefore, the severity score may be lowered or identified as false positive.
## 7.6.1.2 Distributed Denial-of-Service Protection in Kyma
A distributed denial-of-service (DDoS) attack is a malicious attempt to disrupt the normal traffic of a targeted server, service or network by overwhelming the target or its surrounding infrastructure with a flood of traffic.
With Kyma comes the default DDoS protection offered by the IaaS provider.
Default DDoS Protection
| IaaS Provider   | Default DDoS Protection             |
|-----------------|-------------------------------------|
| Microsoft Azure | Azure DDoS Protection Basic service |
IaaS Provider
## Default DDoS Protection
| Amazon Web Services   | AWSShield Standard               |
|-----------------------|----------------------------------|
| Google Cloud          | Standard network DDoS protection |
##  Remember
Because these are cloud providers' default offerings, they are subject to change as per the cloud providers' terms and conditions.
## Web Application Firewalls
It is not possible to configure or enable web application firewalls in SAP BTP , Kyma runtime.
## 7.6.2  Secure Development in the Kyma Environment
Secure development focuses on Pod security, network traffic restriction, Istio sidecar proxy injection, and workload exposure. Learn about the security measures you can take to improve the security of your Kyma environment .
## Pod Security
To learn how to secure your Kubernetes Pods in Kyma, see Kubernetes Pod Security Recommendations [page 3291].
## Restrict and Secure Network Traffic
- Set up Kubernetes Network Policies to restrict the network traffic between Pods in your namespaces.
- Enabling Istio Sidecar Proxy Injection [page 1783] for your namespaces.
## Expose Workloads Securely
To securely expose workloads in SAP BTP, Kyma runtime, use the Istio and API Gateway modules. As a prerequisite, make sure that you have those two modules added to your Kyma cluster. Then, perform the following tasks:
- Set Up a Custom Domain for a Workload
- Disable the default gateway. See Disable or Enable Kyma Gateway .
- Set up your own API gateway with one of the following options:
- Set Up a TLS Gateway in Simple Mode
- Set Up an mTLS Gateway and Expose Workloads Behind It
- Create an APIRule Custom Resource to securely expose your workloads
- Expose and Secure a Workload with JWT
- Expose and Secure a Workload with a Certificate
## Module-Specific Security Considerations
## Serverless Module
For more information, see Security Considerations for the Serveless module.
## Related Information
Kyma Security Concepts [page 3284]
Secure Administration and Operations in the Kyma Environment [page 3296]
Kubernetes Pod Security Recommendations [page 3291]
## 7.6.2.1 Kubernetes Pod Security Recommendations
Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. This document shows how to use Pods securely and ultimately have a secure workload. The following steps guide you to use Pods securely and ultimately have a secure workload, depending on your needs.
## 1. Decide on the Basic Security Settings
## Without Special Requirements: Highest Security
If you are not aware of any special requirements, set up your workload in the most secure way:
- Specify a user for the Pod and container. If your application requires a specific user, change values for the runAsUser and runAsGroup parameters.
- Run an unprivileged workload.
- Drop all capabilities.
- Use seccomp. For more information, see the Restrict a Container's Syscalls with seccomp .
- Run with a read-only root file system.
Use the following securityContext configuration for the Pod and container.
##  Sample Code
```
# Pod spec securityContext: runAsUser: 10001 runAsGroup: 30001 runAsNonRoot: true seccompProfile: type: RuntimeDefault # Container spec securityContext: privileged: false allowPrivilegeEscalation: false runAsNonRoot: true capabilities: drop: - ALL readOnlyRootFilesystem: true
```
## If Y our Container Must Run as User Root
If your container must run as user root, use the following setup:
- Do not use the runAsUser and runAsGroup parameters in the spec or set them to 0.
- Do not use the runAsNonRoot parameter.
- Run an unprivileged workload and do not allow privilege escalation.
- Drop all capabilities.
- Use seccomp.
- Run with a read-only root file system.
Use the following securityContext configuration for the Pod and container.
## 
```
securityContext: seccompProfile: type: RuntimeDefault # Container spec securityContext: privileged: false allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop:
```
```
Sample Code # Pod spec - ALL
```
## 2. Enable Additional Capabilities
## Add Storage to Your Pod
If you need storage, follow these recommendations:
- Always use volumes instead of local storage in the container.
- Avoid using hostPath volumes. If you must use them, follow these rules:
- Whenever possible mount hostPath volumes in the read-only mode.
- Never mount the following sensitive paths:
- /proc - a pseudo-file system that provides an interface to kernel data structures
- / - file system's root
- /etc - the directory that usually contains all system-related configuration files
- /root - the home directory of the root user
- /var/run/docker.sock - the Unix socket used to communicate with the Docker daemon
- /var/run/crio/crio.sock - the Unix socket used to communicate with the CRI-O Container Engine
- /run/containerd/containerd.sock - the Unix socket used to communicate with the Containerd container runtime
- /home/admin - the home directory of the admin user
- /var/lib/kubelet - the directory for kubelet-related configuration
- /var/lib/kubelet/pki - the directory containing the certificate and private key of the kubelet
- /etc/kubernetes - the directory containing Kubernetes-related configuration
- /etc/kubernetes/manifests
- Use only the File or Directory hostPath.type . Usually use File , and Directory as a fallback.
- Some files and directories on the host can only be accessible by root. Read more in the Kubernetes documentation .
Consider the following template for mounting hostPath volumes in order to create Kubernetes manifests:
<!-- image -->
- Use emptyDir volumes for temporary file systems. If your application needs a temporary file system, for example, for caching purposes, use
emptyDir volumes instead of mounting hostPath or making the root file system writable. Also, remember to always define a size limit for the volume. Use the following template:
<!-- image -->
## Add Other Capabilities
- Before you add new cabilities to your Pod or container configuration, always drop all capabilities. Each container runs with a fixed set of default capabilities. You can find the containerd v1.7 default capabilities in this code .
- Add only the capabilities you really need.
- If possible, avoid the following capabilities that can be exploited to escalate privileges:
- CAP\_CHOWN
- CAP\_DAC\_OVERRIDE
- CAP\_DAC\_READ\_SEARCH
- CAP\_SETUID, CAP\_SETGID
- CAP\_NET\_RAW
- CAP\_SYS\_ADMIN
- CAP\_SYS\_PTRACE
- CAP\_SYS\_MODULE
- CAP\_FORMER
- CAP\_SETFCAP
If your application doesn't work as expected, you may need some additional capabilities. Find the full list of the available capabilities on the Linux manual page . Check which capabilities are missing using the Inspector Gadget tools. Y ou can install the toolset as a kubectl plugin using krew . After it's installed, use the kubectl gadget trace capabilities command.