orkungedik/SAP-basis-dataset huggingface dataset:
## 6.4.6  Setting Your Module to the Unmanaged and Managed State
In some cases, for example, for testing, you may need to modify your module beyond what is supported by its configuration. By default, when a module is in the managed state, Kyma Control Plane governs its Kubernetes resources, reverting any manual changes during the next reconciliation loop. To modify Kubernetes objects directly without them being reverted, you must set the module to the unmanaged state. In this state, reconciliation is disabled, ensuring your manual changes are preserved.
##  Caution
Unmanaged modules aren't subject to the Service Level Agreement (SLA). Additionally, setting a module back to the managed state does not guarantee its version is correctly updated.
## Setting Your Module to the Unmanaged State
## Procedure
- Use Kyma dashboard
- a. Go to Kyma dashboard. The URL is in the Overview section of your subaccount.
- b. Choose Modify Modules , and go to the Edit tab.
- c. In the Form view, uncheck the Managed checkbox under your module.
- d. Save the changes.
In the View tab, you see your module in the Unmanaged state.
- Use Kyma CLI
- To set a module to the unmanaged state, use the following command:
kyma module unmanage {MODULE-NAME}
You should see the following message:
```
Module {MODULE-NAME} set to unmanaged
```
## Related Information
Kyma Dashboard [page 88] Kyma CLI [page 90]
## Setting Your Module to the Managed State
## Procedure
- Use Kyma dashboard
- a. Go to Kyma dashboard. The URL is in the Overview section of your subaccount.
- b. Choose Modify Modules , and go to the Edit tab.
- c. In the Form view, check the Managed checkbox under your module.
- d. Save the changes.
In the View tab, you see your module in the Ready state.
- Use Kyma CLI
- To set a module to the managed state, use the following command:
```
kyma module manage {MODULE-NAME}
```
You should see the following message:
Module {MODULE-NAME} set to managed
## Related Information
Kyma Dashboard [page 88] Kyma CLI [page 90]
## 6.4.7  Access Kyma Application Logs
Get insights into your applications, microservices, and Functions by viewing the respective logs. To check out real-time logs immediately, use the Kubernetes functionalities - either in Kyma dashboard, or with kubectl.
## Context
- If you prefer to see the logs in your terminal, replace the placeholders in the following command and run it:
- To see real-time logs in Kyma dashboard, follow these steps:
```
kubectl logs <{POD_NAME}> --namespace <{NAMESPACE_NAME}> --container <{CONTAINER_NAME}>
```
## Procedure
1. Open Kyma dashboard and select the namespace.
2. Access the Pod.
3. Find the container and select View Logs .
## Results
You have access to short-term logs of every container in your Kyma runtime.
## Next Steps
##  Recommendation
If you want long-term storage of logs with advanced querying, dashboarding, and alerting capabilities, set up SAP Cloud Logging to ingest observability data with Kyma runtime.
## Related Information
Auditing and Logging Information in Kyma [page 3304]
Create an SAP Cloud Logging Instance through SAP BTP Service Operator SAP Cloud Logging: Ingest via Kyma Runtime
## 6.4.8  Kyma Environment Backup
The user load in a Kyma cluster typically consists of various Kubernetes objects and volumes.
- Objects hold the configuration of user's application applied to the API server using Kubernetes resources
- Volumes hold the actual data that a user may store in a persistent way
Kyma does not provide backup, neither for objects nor volumes, that can replace the configuration or data from a specific point in time.
## Object Backup for Kubernetes Configuration
Kyma environment relies on the managed Kubernetes cluster for periodic backups of Kubernetes objects. It means that it is possible to automatically restore Kubernetes objects in case of inconsistencies or data corruption. However, Kyma environment does not provide backup that can replace the configuration from a specific point in time. Automatic backup doesn't include Kubernetes volumes.
For example, project "Gardener" uses etcd as the Kubernetes' backing store for all cluster data. This means that all Kubernetes objects are stored on etcd. Gardener uses periodic jobs to take major and minor snapshots of the etcd database. A major snapshot (including all the resources) takes place every day, and each minor snapshot (including only the changes in between) takes place every 5 minutes. If the etcd database experiences any problems, Gardener automatically restores the Kubernetes cluster using the latest snapshot.
##  Tip
Follow GitOps principles to reapply the desired state of your Kubernetes objects to any Kubernetes cluster at any time.
- GitOps means managing your Kubernetes objects using Git .
- A Git repository becomes a single source of truth where you declare the desired state of your Kubernetes objects.
- Automation tooling of your choice pulls the desired state from that single source and applies the declared configuration to your cluster.
For more information, see OpenGitOps .
## Volume Backup for Customer Data
Your customer data isn't backed up automatically. If you're using Kubernetes volumes to store data, we recommend that you use Kubernetes VolumeSnapshots to back up and recover your data. The backup and recovery using Kubernetes VolumeSnapshots are supported for AWS, Azure, and Google Cloud.
## Related Information
Creating On-Demand Volume Snapshots [page 3163] Change Storage Size in Kyma [page 3167]
## 6.4.8.1 Creating On-Demand Volume Snapshots
## Prerequisites
A PersistentVolumeClaim (PVC) resource exists in the cluster.
## Context
You can manually back up your volumes using the VolumeSnapshot Kubernetes resource. When you create a volume snapshot, you copy your volume's contents at that particular point in time. A VolumeSnapshot resource requires an existing source PVC and a VolumeSnapshotClass resource specified. Taking volume snapshots is possible thanks to Container Storage Interface (CSI) drivers , which allow third-party storage providers to expose storage systems in Kubernetes. The driver must be specified in the VolumeSnapshotClass resource.
## Procedure
1. Create a VolumeSnapshot resource using the default VolumeSnapshotClass and your PVC name:
```
kubectl apply -n {NAMESPACE} -f <<EOF apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: snapshot spec: volumeSnapshotClassName: default source: persistentVolumeClaimName: {YOUR_PVC_NAME} EOF
```
The VolumeSnapshot resource is created.
2. To verify that the snapshot was taken successfully, run kubectl get -n {NAMESPACE} volumesnapshot -w and check that the field READYTOUSE has status true .
## 6.4.10  Change Storage Size in Kyma
If the amount of data for the applications in your Kyma environment grows, you can expand the storage size for your customer data by resizing the respective Persistent Volume Claim (PVC).
## Prerequisites
- Your user has the authorizations to change PVC resources.
- Your workload uses a Persistent Volume, managed by a PVC.
## Context
In a Kubernetes cluster, your customer data is stored in volumes. A 'Persistent Volume Claim' (PVC) manages that volume for you and defines the size of storage. As the amount of customer data grows, you must adjust the PVC accordingly.
## Procedure
1. Go to Kyma dashboard and select the correct namespace and workload.
2. Find the PVC you want to resize and enter the desired new size of the volume.
3. Save your changes.
The PVC shows the condition type Resizing . Wait until the PVC switches to condition type FileSystemResizePending . This may take a few minutes.
4. Restart your workload by restarting all related Pods.
## Results
The storage size for your customer data has been adjusted to your needs.
## Next Steps
Remember to back up your customer data.
## Related Information
Kubernetes: Expanding Persistent Volumes Claims Kyma Environment Backup [page 3162]
## 7.1.2  Web Access Control
The Cloud Foundry environment extends SAP BTP. It provides platform security functions such as business user authentication, authorization management, and other security functions for access to the applications in the runtime container. To access the runtime container, the business user can use a browser or a browserbased user interface.
The following diagram shows the architecture with the components that are responsible for business user authentication, authorization management, and security. It is not mandatory for applications to use the User Account and Authentication service and the application router.
<!-- image -->
The User Account and Authentication (UAA) component provides a programming model for business applications. It is the central infrastructure component of the runtime platform for business user authentication and authorization management. The users can be stored in the following identity providers:
- SAP ID service
- SAP Cloud Identity Services
- Any SAML 2.0 identity provider
Applications authenticate using OAuth 2.0. When business users access an application, the application router acts as OAuth client and redirects their request to the OAuth authorization server for authentication (see the
Applications section). Runtime containers act as resource servers, using the container security API of the relevant container (for example, Java) to validate the token issued by the OAuth authorization server.
## 7.1.3  API Access Control
The Cloud Foundry environment extends SAP BTP. It provides platform security functions such as business system authentication, authorization management, and other security functions to enable business systems to access the applications (for example, Java or Node.js) in the runtime container. Business systems use APIs to access the runtime container.
A business system uses APIs to directly access the resources in the runtime container.
The following diagram shows the architecture with the components that are responsible for business system authentication, authorization management, and security.
<!-- image -->
The User Account and Authentication (UAA) component is the central infrastructure component of the runtime platform for authentication and authorization management. The users can be stored in the following identity providers:
- SAP Cloud Identity Services
- Any identity provider
Business system use APIs to directly access the resources in the runtime container. The UAA acts as an OAuth authorization server and issues an appropriate access token. It enables the business system to directly access an application in the runtime container. Runtime containers act as OAuth resource servers, using the container security API of the relevant container (for example, Java) to validate the token issued by the OAuth authorization server.
## Related Information
Protecting Your Application [page 533] Tutorials for the SAP Authorization and Trust Management Service [page 558]
## 7.1.4  Authorization Entities
Business users in an application require different authorizations because they work in different jobs.
For example, in a leave request process, there are employees who want to create and submit leave requests, managers who approve or reject, and payroll administrators who need to see all approved leave requests to calculate the leave reserve. The authorization concept of a leave request application has to cover the needs of these employee groups. This authorization concept includes elements such as roles, scopes, and attributes.
A role is an instance of a role template; you can build a role based on a role template and assign the role to a role collection.
Role templates refer to attributes and scopes. The role templates contain the authorizations for activities, such as viewing, editing, or deleting data.
Information that is specific to the user is stored in attributes. For each attribute, administrators can specify the value that restricts data access. Static attributes are stored in the role, whereas in cases in which a custom identity provider provides the business users, you can dynamically reference all the attributes that come with the access token.
Relationship Between Authorization Components
<!-- image -->
## Scopes for Functional Authorization Checks
The application defines scopes, which describe the authorizations required by the application to execute functions such as editing, viewing, and deleting.
The application security descriptor file ( xs-security.json ) defines the scopes used by the application.
## Role Templates
A role template is a description of one or more roles (for example, employee or manager) and any attributes that apply to those roles.
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 country equals UK and another where country equals USA. This instantiates the role template. Else, the roles will have empty attributes (with no concrete values).
Role templates that contain only application-specific local scopes can be instantiated without the administrator having to do anything.
## Role Collections
Role collections reference role templates.
After the developer has created the role templates and deployed them to the relevant application, it's the administrator's task to use those role templates to build roles with the required attributes, aggregate the roles into role collections, and then assign the role collections to business users in the application.
## Attributes
Information retrieved from the user's identity (such as department or cost center) is stored in attributes. Attributes refine the authorizations of business users according to the attributes that come with the business users. For example, you can use static attribute values such as country equals USA, or dynamic attribute values from the access token or identity provider, such as group ID.
## 7.1.5  Monitoring and Troubleshooting
This section provides information on troubleshooting-related activities for the SAP Authorization and Trust Management service in the Cloud Foundry environment.
##  Tip
We also recommend that you regularly check the SAP Notes and Knowledge Base for component BC-CPCF-SEC-IAM in the SAP Support Portal . These contain information about program corrections and provide additional information.
To help you troubleshoot your issue, we also recommend increasing the log verbosity of your application and application router. We provide a script to help you. If for some reason you can't use this script, increase the log verbosity manually, see related link.
To troubleshoot problems with tokens from SAP Cloud Identity Services, see Logging OpenID Connect Tokens in the documentation for SAP Cloud Identity Services.
Our troubleshooting information can be found in Troubleshooting for the SAP Authorization and Trust Management service in the Cloud Foundry environment . Check the individual troubleshooting topics for your error message. If you can't find your problem, create an incident in the component BC-CP-CF-SEC-IAM . For more information, see the related link.
- The Security Tab Is Missing in the Subaccount
- Access Is Denied or Forbidden
- Identity Provider Could Not Process Authentication Request
- Logon Screen Shows "SAP HANA XS Advanced"
- Requested Route Does Not Exist
- Subdomain Does Not Map to a Valid Identity Zone
- No Client with Requested ID
- Login Issues
- Cannot Add Role Templates to Predefined Role Collections
- 502 Error: Call to /oauth/token Was Not Successful
- Unexpected AuthnResponse : Existing authentication - &lt;User&gt;
- AuthnRequest expired - ID: &lt;RequestId&gt; Destination: &lt;IdPDestination&gt;
- InResponseToField of Response doesn't correspond to the sent message
- Response issue time is either too old or with date in the future. Sync IdP to match skew &lt;skew&gt;
- Trust establishment issues
- Token retrieval fails with status code 401
- Cockpit displays HTTP status 500 error on logon with custom IdP user
- IAS application reference isn't created in your IAS tenant
- User base doesn't appear in existing Neo subaccounts
- User from corporate IdP can't log on to Neo subaccount
- 409 error code on deleting a custom identity provider
- Share Authorization and Trust Management service instances
- Invalid "redirect\_uri"
## Related Information
Getting Support [page 3312] Enable and Provide Application Logs [page 3196] Auditing and Logging Information for SAP Authorization and Trust Management Service [page 3198] Authorization and Access Control Cookbook
## 7.1.5.3 Troubleshooting for SAP Authorization and Trust Management Service
This section contains troubleshooting information for the Cloud Foundry environment of SAP Business Technology Platform. It provides assistance with issues concerning platform security functions such as business user authentication, authentication of applications, authorization management, trust management, and other security functions.
The Security Tab is Missing in the Subaccount [page 3206] Access Is Denied or Forbidden [page 3207] Identity Provider Could Not Process Authentication Request [page 3208]
Logon Screen Shows "SAP HANA XS Advanced" [page 3209]
Requested Route Does Not Exist [page 3211]
Subdomain Does Not Map to a Valid Identity Zone [page 3212]
No Client with Requested ID [page 3214]
Login Issues [page 3215]
Cannot Add Role Templates to Predefined Role Collections [page 3216]
409 Error Code on Deleting a Custom Identity Provider [page 3217]
Unexpected AuthnResponse : Existing authentication - &lt;User&gt; [page 3218]
AuthnRequest expired - ID: &lt;RequestId&gt; Destination: &lt;IdPDestination&gt; [page 3219]
InResponseToField of Response Doesn't correspond to the Sent Message [page 3219]
Response Issue Time is Either too Old or with Date in the Future. Sync IdP to Match Skew &lt;skew&gt; [page 3220]
Trust Establishment Issues [page 3221]
Token Retrieval Fails With Status Code 401 [page 3222]
Cockpit Displays HTTP Status 500 Error on Logon with Custom IdP User [page 3224]
IAS Application Reference isn't Created in Your IAS Tenant [page 3225]
User Base Doesn't Appear in Existing Neo Subaccounts [page 3226]
User from Corporate IdP Cannot Log on to Neo Subaccount [page 3226]
Share Authorization and Trust Management service instances [page 3227]
Invalid "redirect\_uri" [page 3228]
400 Error: Call to /oauth/token Was Not Successful [page 3229]
## 7.1.5.3.1 The Security Tab is Missing in the Subaccount
## Symptom
If you navigate to your subaccount in the SAP BTP Cockpit, you can't see the Security tab.
## Reason and Prerequisites
The problem here is that only the user that created the subaccount is granted the security administrator role. If other subaccount users should be able to see the security tab and make changes to the security configuration, the creator of the subaccount has to grant them the security administrator role.
The creator of the subaccount and the users that should be added must have at least one of the following member roles:
- They are members of the Cloud Foundry organization (if available) in the subaccount.
- They are members of any Cloud Foundry space that belongs to the organization.
- They are members of the global account that contains your subaccount.
## Solution
The creator of the subaccount has to grant the security administrator role. To do this, follow these steps:
1. Open your SAP BTP Cockpit.
2. Navigate to your subaccount.
3. Choose the Security tab and choose Administrators .
4. Choose Add Administrators . A popup opens, where you can enter the user ID and assign roles.
5. Type in the ID (e-mail) of the user, that you want to add as a security administrator.
6. To assign roles, make sure that the User &amp; Role Administrator checkbox is selected.
7. Choose OK .
After the role has been granted, the user needs to log out and log back in again to make sure the changes are applied to their subaccount user.
## 7.1.5.3.2 Access Is Denied or Forbidden
## Symptom
After sending a request to a web application in the SAP BTP, Cloud Foundry environment, you get a response containing a nested error element with the value access\_denied and an error\_description element.
The system responds with Access is denied.
The system might also respond with the single word Forbidden.
<!-- image -->
## Reason and Prerequisites
A business user has tried to access the URL endpoint of a web application but is not authorized to do this. The authorizations (scopes) required for the URL endpoint must be assigned to this business user. Scopes
(functional authorizations) allow the business user to perform operations provided by the web application. Attributes (instance-based authorizations) specify the data, for example, company code or cost center, which the business user is authorized to use. In this way, business users can perform the operations they are authorized for.
## Solution
A role collection with the role that contains the required authorizations must be available. Assign this role collection to the business user.
If there are neither instance-based authorizations nor roles containing the required attribute values, create a role based on the corresponding role template. Maintain the attribute values of the new role to define the required data authorizations.
##  Note
- Role templates are predefined and deployed together with the web application. Role templates specify the scopes (functional operations) that the web application supports. You cannot change existing role templates or create new ones.
- After a role collection has been assigned, you might need to clear the cache and cookies and log on to the application again for the changes to take effect.
For more information about roles and role collections, see Building Roles and Role Collections for Applications.
## 7.1.5.3.3 Identity Provider Could Not Process Authentication Request
## Symptom
After sending a request to a web application in the SAP BTP, Cloud Foundry environment, the system responds as follows:
Error - Identity provider could not process the authentication request received. Delete your browser cache and stored cookies, and restart your browser. If you continue to experience issues, send an e-mail to sso@sap.com.
## Reason and Prerequisites
The Cloud Foundry environment uses the Identity Authentication service as its SAML 2.0 identity provider. The SAP Authorization and Trust Management service (XSUAA) forwards unauthenticated requests to the
configured identity provider. This error occurs because the trust relationship between the SAP Authorization and Trust Management service and the identity provider hasn't been fully configured. The subaccount has not been registered in the SAML 2.0 identity provider.
## Solution
Configure the missing part of the trust relationship in your identity provider by doing one of the following:
- Use the simplified trust configuration.
- Download the SAML metadata file from the SAP Authorization and Trust Management service, upload it to your SAML 2.0 identity provider, and complete the configuration by registering your subaccount. The following link provides instructions for configuring the Identity Authentication service as a trusted SAML 2.0 identity provider: Register SAP BTP Subaccount in the SAML 2.0 Identity Provider.
## 7.1.5.3.4 Logon Screen Shows "SAP HANA XS Advanced"
## Symptom
After sending a request to a web application in the SAP BTP, Cloud Foundry environment, you see a logon screen with the title SAP HANA XS Advanced.
Below the Log On field, the following domain is displayed: xs2security.accounts400.ondemand.com
##  Note
The expected system behavior is to return a logon screen with the title Welcome &lt;IdP\_tenant\_name&gt;!.
## Reason and Prerequisites
The request of the business user is not authenticated, so it needs to be redirected to the identity provider where the business user is defined. The trust of the identity provider is configured and assigned to the tenant to which the business user belongs. In this case, SAP BTP, Cloud Foundry environment cannot correctly determine the tenant of the business user. As a result, it cannot find the correct identity provider and falls back to https:/ /authentication.sap.hana.ondemand.com
## Solution
This error indicates a problem with the TENANT\_HOST\_PATTERN environment variable in the manifest.yml file of the web application. The tenant host pattern is a regular expression (regex) and is used to determine the tenant ID (which is identical to the subdomain) with which the request is associated. For more information, see Multitenancy. The system shows the behavior described earlier if the URL of the request does not match with the defined pattern.
The tenant host pattern should be defined as follows:
```
. . . env: XSAPPNAME: <application_name> TENANT_HOST_PATTERN: "^(.*)-<application-routerhostname>.cfapps.<region>.hana.ondemand.com".
```
.
.
.
##  Note
Separate the regular expression and the Cloud Foundry host name with a hyphen (-). The subdomain of the tenant is not a subdomain of the web application in a technical sense. The subdomain would be separated from the Cloud Foundry host name with a dot (.). Since there is no automatic certificate creation process each time that a new tenant is onboarded, you must use a workaround.
The current workaround is to concatenate the subdomain of the tenant with the Cloud Foundry host name using the hyphen (-). All such concatenations share the same Cloud Foundry top level domain, together with the certificate of this top-level domain.
```
The following example shows the web application bulletinboard in the cfapps.eu10.hana.ondemand.com Cloud Foundry domain: . . . env: XSAPPNAME: bulletinboard TENANT_HOST_PATTERN: "^(.*)-approuter.cfapps.eu10.hana.ondemand.com". . . .
```
##  Note
Recheck the definition of the TENANT\_HOST\_PATTERN environment variable in the manifest.yml file, and correct it, if necessary. The route for the TENANT\_HOST\_PATTERN has to be lowercase.
## 7.1.5.3.5 Requested Route Does Not Exist
## Symptom
You send a request to a web application, which is running on SAP BTP, Cloud Foundry environment and the browser responds with the message:
404 Not Found: Requested route ('&lt;cloudFoundryHostname&gt;.&lt;cloudFoundryDomain&gt;') does not exist.
## Reason and Prerequisites
The URL of the request contains a route to an application for which no route mapping has been defined. This means that the Cloud Foundry router can't delegate the request to the respective web application and responds with an error message. Another reason might be that your application has stopped.
## Solution
## Create and Map the Missing Route to the Web Application
Create and map the missing route to the web application.
cf map-route &lt;webApplication&gt; &lt;cloudFoundryDomain&gt; --hostname &lt;cloudFoundryHostName&gt;
<!-- image -->
##  Example
The web application's name is bulletinboard-123456 and the application was created in the European landscape eu10.hana.ondemand.com, the application should be reachable under the following domain: https:/ /bulletinboard.eu10.hana.ondemand.com.
1. Use the following command to create this route: cf map-route bulletinboard-123456 cfapps.eu10.hana.ondemand.com --hostname bulletinboard
2. Check if the route was created: cf routes
## Check if Your Application is Still Running and Restart it
1. Log in to your Cloud Foundry account. cf routes
2. Choose your ORG and SPACE.
3. Check the status of your application. cf app &lt;your application&gt;
4. Restart your application.
2. cf restart &lt;your application&gt;
5. Your application should now have the status running and you can call it through its route.
## 7.1.5.3.8 Login Issues
## Symptom
You log on to SAP BTP via the Cloud Foundry CLI or the browser and you get an HTTP 401 error or see messages on the screen that indicate that your login attempt has failed.
## Reason and Prerequisites
Authentication in Cloud Foundry runs through the UAA service which tunnels the credentials supplied (such as username and password) towards a trusted Open ID Connect Identity Provider (IdP). SAP's default IdP
Create a service instance for your application.
Subscribe to the SaaS application.
is the SAP ID service, which is available at https:/ /accounts.sap.com for SAP ID Service, or at https:/ / account.sap.com for SAP Universal ID.
To narrow down the origin of the issue, you need to check the individual components involved in the login process.
## Solution
## Identify whether a second factor (a one-time token) is mandatory for this user/landscape
1. Open the UAA service in the browser directly, depending on your region: For example, for the European region, go to https:/ /uaa.cf.eu10.hana.ondemand.com/ (For an overview of all Cloud Foundry landscape URLs, see Regions).
2. If you are redirected to https:/ /accounts.sap.com asking for two-factor authentication and a passcode, a second factor in the form of a one-time TOTP token is mandatory.
2. See Activate TOTP Two-Factor Authentication for information about how to configure a device to generate TOTP tokens; for example, with an authenticator app.
3. Log on to your Cloud Foundry environment using two-factor authentication.
1. Type cf login .
2. Enter your e-mail address.
3. Enter your password in the following format: &lt;your global password&gt;&lt;one-time-token&gt;
## 7.1.5.3.9 Cannot Add Role Templates to Predefined Role Collections
## Symptom
You want to update your SAP Authorization and Trust Management service (XSUAA) instance and add role templates to a previously defined role collection in the xs-security.json . The service instance update fails with the error message:
Cannot add or remove role-template-references from role collection if already in use (app subscribed or role collection assigned to user). Please create a new rolecollection with a different name instead.
## Reason and Prerequisites
You tried to add a role template to an existing role collection that is already in use. If your application was either subscribed (for a multi-tenant enabled application) or the role collection in question was already assigned to a user, an update of the role collection is not possible anymore. The security reason for this is that role collections might have already been audited by subscribers and/or the security administrator assigned these role collections to users based on the initial state of the role collections. Changes to the role collections at a later point in time would render these audits invalid.
In general, you should never modify any authorization object (role template, role) that is already in use in a way that it grants additional authorization without explicit approval of the user and role administrator.
## Solution
## Create a new role collection with a different name
You can add an additional role collection with a different name to your xs-security.json . Administrators can then audit the new role collection and migrate the users to the updated role collection. To do this, follow these steps:
1. Add a new role collection with a different name to the xs-security.json .
2. Add/modify the role templates within that role collection according to your needs.
3. Update the SAP Authorization and Trust Management service service instance. See Update Service Instances Using the SAP BTP Cockpit or Cloud Foundry Command Line Interface.
4. Assign the new role collection to the application users.
5. (Optional) When all users have been migrated to the new role collection, remove the old role collection from the xs-security.json .
6. (Optional) Update the SAP Authorization and Trust Management service service instance.
For more information about the creation of role collections and the xs-security.json , see Create Role Collections (with Predefined Roles) and Application Security Descriptor Configuration Syntax.
## 7.1.5.3.10  409 Error Code on Deleting a Custom Identity Provider
## Symptom
- On deleting a custom identity provider (origin: sap.custom ) in the SAP BTP cockpit, you get an error.
- If you open the developer console (F12) and try again, you will see a more detailed error message.
## Reason and Prerequisites
- This issue occurs when there are applications still present in the Identity Authentication service (IAS). For example, this can happen if you have created an identity service instance.
## Solution
1. Check the IAS tenant for which you want to delete the trust configuration in the SAP BTP cockpit.
2. You need to delete all the applications of the error message.
Note : Delete only those applications that you are sure are not needed anymore.
See SAP Note 3148626 for more information.
## 7.1.5.3.11  Unexpected AuthnResponse : Existing authentication - &lt;User&gt;
## Symptom
After logging on to an application with SAML, the user presses the back button of the browser. This leads to the Unexpected AuthnResponse : Existing authentication - &lt;User&gt; error .
## Reason and Prerequisites
Using the back button leads to a second authentication request to the identity provider, with the same ID used for the initial logon. As a result, the identity provider issues a second authentication response for the same ID, which is then rejected.
## Solution
The error message displayed is the correct outcome of this action. If you want to trigger a logout by pressing the back button, this needs to be handled on the application side.
## 7.1.5.3.12  AuthnRequest expired - ID: &lt;RequestId&gt; Destination: &lt;IdPDestination&gt;
## Symptom
When a SAML session is dropped, the audit log shows AuthnRequest expired - ID: &lt;RequestId&gt; Destination: &lt;IdPDestination&gt;. This particular error message can be found only in the audit log.
## Reason and Prerequisites
This error occurs when the identity provider takes more than 15 minutes to issue the authentication response or when the user waits with the logon action for more than 15 minutes on the identity provider side. After this time interval, the session information is dropped for performance and security reasons; and thus, the request and response do not match anymore.
## Solution
## Don't delay the logon action
Ensure that the user login is within the timeframe of 15 minutes.
## Check the identity provider
The identity provider may be out of sync; or if it consistently takes a long time to issue the authentication response, reduce this time and check.
## 7.1.5.3.13  InResponseToField of Response Doesn't correspond to the Sent Message
## Symptom
When the user tries to log on with SAML or by refreshing the session, they see the InResponseToField of Response doesn't correspond to the sent message error.
## Reason and Prerequisites
This error occurs when handling an authentication response without a known corresponding request; for example, as the consequence of a session timeout. The timeout is a safeguard for performance and security reasons.
## Solution
## Don't delay the logon action
Ensure that the user login is within the timeframe of 15 minutes.
## Check the identity provider
The identity provider may be out of sync; or if it consistently takes a long time to issue the authentication response, reduce this time and check.
## Check the audit log
Check the audit log for the AuthnRequest expired - ID: &lt;RequestId&gt; Destination: &lt;IdPDestination&gt; error. If you find this error message, refer to AuthnRequest expired - ID: &lt;RequestId&gt; Destination: &lt;IdPDestination&gt; [page 3219].
For more information about the audit log, refer to Auditing and Logging Information for SAP Authorization and Trust Management Service - SAP Help Portal.
## 7.1.5.3.14  Response Issue Time is Either too Old or with Date in the Future. Sync IdP to Match Skew &lt;skew&gt;
## Symptom
SAML logon doesn't work and the Response issue time is either too old or with date in the future. Sync IdP to match skew &lt;skew&gt; error message is displayed.
## Reason and Prerequisites
This error occurs when the time skew between the SAP Authorization and Trust Management service and the identity provider is larger than 60 seconds in either direction, or when after being issued, the authentication response takes more than 60 seconds to reach the SAP Authorization and Trust Management service.
## Solution
Check the time skew between the identity provider and the SAP Authorization and Trust Management service, and then sync the clock of the identity provider.
## 7.1.5.3.15  Trust Establishment Issues
## Symptom
You could have trust establishment issues if you encounter one of the following symptoms:
- In the BTP Cloud Cockpit:
- After clicking Establish Trust , an Identity Authentication (IAS) tenant is not displayed.
- Failure after the IAS tenant is selected and confirmed by clicking Establish Trust .
- Establish Trust button is not accessible (displayed in the inactive state).
- Trust deletion fails.
- In the REST API:
- Usage of the REST API ( /sap/rest/identity-providers ) returns status code 400 , 401 , or 404 .
- Trust deletion fails.
## Reason and Prerequisites
To establish trust in an automated manner, the customer ID of the IAS tenant has to match the customer ID of the global account.
Consequently, the issues in trust establishment may be because of the following:
- The customer ID maintained in the IAS tenant does not match what is in the global account.
- Trust has already been established (IdP trust with origin sap.custom exists.).
## Solution
## Check that the IAS tenant is displayed
If an IAS tenant is not displayed, verify the following:
- The customer ID maintained in the IAS tenant matches what is in the customer ID of the global account.
- IAS admin UI: Applications &amp; Resources &gt; Tenant Settings &gt; Customer ID
- Global account: Verify the value in the control center.
In case you require a new IAS tenant, see the corresponding documentation. For more information, see this blog article .
## Check that the "Establish Trust" button is accessible
If the Establish Trust button is grayed out, there is probably already an Identity Provider (IdP) trust with origin, sap.custom. To change the trust, you can delete the existing configuration and create a new one. Note that the trust deletion in the Cloud Cockpit implies the deletion of all existing shadow users (for this IdP).
If the Establish Trust button is not visible at all, it could be an issue with the Identity Authentication service (IAS) registry or the certificates. This is usually a temporary issue and you should retry accessing it later.
## Check the usage of the REST API
Depending on the status code, verify the following points:
- 400 : Check the section, Specific IAS tenant is not shown . Further, verify that the /sap/rest/identityproviders/ias REST API returns the used IAS tenant.
- 401 : REST API requires a token of the apiaccess service plan from your subaccount.
- 404 : For newly created IAS tenants, it can take up to 2 hours until the DNS entry is propagated to all the DNS caches. Until that is done, you can get an error when trying to call the new IAS tenant. In such a case, wait and retry after 2 hours.
## Check if trust has already been established
- Verify that you are deleting a custom IdP (the default IdP cannot be deleted).
- Ensure that if you use the identity broker (or a SaaS application that uses it), it does not contain any application references or other applications.
## 7.1.5.3.17  Cockpit Displays HTTP Status 500 Error on Logon with Custom IdP User
## Symptom
## Reason and Prerequisites
After successfully logging on with a custom identity provider (IdP) user, the cockpit displays an error page: HTTP Status 500 - Internal Server Error .
The following are the known reasons for this error:
- The mail claim in the OpenID Connect (OIDC) token from the Identity Authentication (IAS) tenant, is empty. This could happen in the following cases.
- The corporate identity provider (for example, MS Azure AD) is connected to the IAS and the user in the corporate IdP does not have an email address assigned.
- The Identity Authentication user store is enabled, and the corporate identity provider is configured to send the email address of its user in another SAML attribute or OIDC claim than what is defined in the default attributes of the application in the Identity Authentication tenant.
- The Identity Authentication user store is disabled. This requires the corporate identity provider to send the user's email address in a SAML attribute or OIDC claim mail.
- The mail , first\_name , or last\_name claim in the OIDC token from IAS contains multiple values. This could happen in the following cases.
- The IAS tenant or application is configured to use a corporate IdP with identity federation enabled and the user also exists in the IAS user store, or the corporate IdP sends multiple values in the first place.
- In the case of the mail claim, the corporate IdPs OIDC token or SAML assertion does not send the email address in all lowercase. IAS always converts the email address to lowercase for local users.
- The issuer in the connected IAS tenant was changed after the trust to that tenant was established.
## Solution
## Configure the corporate identity provider
As typically, either some attribute is missing or has multiple values instead of a single one, configure the corporate identity provider to correctly send the mail claim or required attributes.
- If a platform user has problems when logging on with the a custom identity provider, refer to the IAS Troubleshooting Logs (OIDC) for that affected user.
- In particular, check if there is exactly one value (and the correct value) for the specified attributes.
## Check the issuer in the IAS
The issuer in the IAS must not be changed after the trust has been established. This is also documented as a restriction here.
## 7.1.5.3.18  IAS Application Reference isn't Created in Your IAS Tenant
## Symptom
When trying to log on to the global account with a custom identity provider (IdP) user, the Identity Authentication (IAS) tenant responds with the following error message: OpenID provider cannot process the request because the configuration is incorrect. Please contact your system administrator.
## Reason and Prerequisites
Most likely, you configured a platform IdP earlier and deleted the resulting IAS application reference (SAP Business Technology Platform, btp-cockpit ) from the IAS tenant.
## Solution
## Delete and recreate the trust to the IAS tenant
In your global account, delete and recreate the trust to the IAS tenant.
## 7.1.5.3.19  User Base Doesn't Appear in Existing Neo Subaccounts
## Symptom
When trying to add new members, Neo member management doesn't have the custom identity provider configured in the global account, as the user base.
## Reason and Prerequisites
For subaccounts in the Neo environment, the identity provider will be offered in the value help only if a user in that identity provider has created at least one Neo subaccount in the corresponding global account and Neo region. For more information about this, see here.
## Solution
## Create at least one new Neo subaccount
A user from the configured custom identity provider needs to create at least one new Neo subaccount in the Neo region where the user base selection is missing.
## 7.1.5.3.20  User from Corporate IdP Cannot Log on to Neo Subaccount
## Symptom
When a user with a corporate identity provider (IdP) logs on to the cockpit and tries to navigate to a Neo subaccount, the Identity Authentication (IAS) tenant shows the logon screen with the E-Mail or User Name and
Password fields. However, with a properly connected and configured corporate IdP, the IAS logon screen should show only the E-Mail or User Name field.
## Reason and Prerequisites
For all the Neo datacenters where you have subaccounts, you might have to configure a separate SAML application (for example, SAP Cloud Platform hhw9g3jrxa ) in the IAS tenant. This behavior is also documented here.
- A custom IdP with a corporate identity provider (e.g. MS Azure AD) is configured in the global account.
- The affected users from the corporate IdP can log on to the cockpit (e.g. https:/ / cockpit.eu10.hana.ondemand.com/cockpit/?idp=ar9ibaxhm.accounts.ondemand.com).
- The affected users are configured as members of the Neo subaccount, with the correct user base.
## Solution
Find the correct SAML application in the configured IAS tenant and configure conditional authentication accordingly. Each Neo region where custom IdP is configured has a separate SAML application in IAS that needs to be configured.
## 7.1.5.3.21  Share Authorization and Trust Management service instances
## Symptom
You want to share Authorization and Trust Management service instances among different Cloud Foundry spaces or environments.
## Reason and Prerequisites
- You use an Authorization and Trust Management service instance of the application type.
- You want to use the service instance in multiple spaces or environments, without recreating it multiple times.
## Solution
Use the SAP BTP command line interface (btp CLI) to share the application plan.
For more information, see Sharing and Unsharing Service Instances.
## 7.1.5.3.22  Invalid "redirect\_uri"
## Symptom
After logging on, you are redirected to a Where-To? page with one of the following error messages:
- The redirect\_uri is invalid
- The redirect\_uri has an invalid domain
- Invalid redirect: {URI} does not match one of the registered values
- Client registration is missing redirect\_uri
- Client registration contains invalid redirect\_uri
## Reason and Prerequisites
The redirect\_uris configuration value for the used service instance has not been properly configured.
## Solution
1. Identify the affected application. The affected application is the application on which you want to be redirected after the logon process.
2. Identify the affected service instance of the xsuaa type.
- Cloud Cockpit: Find out which service instance of the xsuaa type was bound to the application.
- CF CLI: Check the environment of the application, and then find xsuaa to retrieve the name of the service instance: cf env &lt;application-name&gt;
3. Identify the xsappname of the service instance (which is mandatory for xs-security.json ).
- Existing xs-security.json : Y ou can find the xsappname of the xs-security.json file that was used to create the service instance.
- Cloud Cockpit: Create a service key and retrieve the xsappname from it; remove the section after the exclamation mark - for example, myapp!b123 -&gt; xsappname: myapp . For more information, see SAP Note 3319310 .
- CF CLI: Check the environment of the application (see step 2), retrieve the xsappname from the corresponding service, and then remove the section after the exclamation mark.
4. Prepare the security descriptor ( xs-security.json ).
- For more information, see Application Security Descriptor Configuration Syntax.
5. Update the redirect\_uris attribute of the corresponding service instance (within oauth2-configuration ).
- Cloud Cockpit: Click Update in the service, and then provide the xs-security.json file, as required.
- CF CLI: Use cf update-service to update the service instance and provide the required xs-security.json file: cf update-service &lt;instance-name&gt; -c &lt;path-to-xs-security.json&gt;
Note : It is important to provide the complete xs-security.json file during the update as partial updates are not supported.
## 7.1.5.3.23  400 Error: Call to /oauth/token Was Not Successful
## Symptom
You tried to log on to your application and got an error related to the token size exceeding some limits (for example, the HTTP header size).
## Reason and Prerequisites
By default, access and refresh tokens include SAML groups and role collections. If you have a lot of SAML groups or role collections, the token size increases, and this can cause the JWT to exceed the size limit of 16 K. This results in a 400 error and the user not being able to log in.
## Solution
## Keep the JWT size to a minimum
Application security is maintained in the application security descriptor file ( xs-security.json ). In the syntax of the application security descriptor file, do the following to keep the JWT size to a minimum.
- Set the value of the system-attributes parameter to an empty array, like this: "systemattributes": []
- Configure only the required groups in the Identity Provider (IdP).
For more information regarding the xs-security.json file, see Application Security Descriptor Configuration Syntax.