orkungedik/SAP-basis-dataset huggingface dataset:
## 6.1.1.8.2.4  Provision Users to SAP BTP Accounts
As people join, change roles, and eventually leave your organization, you care for the onboarding, maintenance, and offboarding of their users in your systems. If you're a small organization, you can use manual processes; otherwise, you should consider automating your processes.
## Prerequisites
- You have the required authorizations.
For more information, see Security Administration: Managing Authentication and Authorization [page 2278] or Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125].
- For global account, directory, and subaccount levels, you have API credentials. For more information, see Accessing Administration Using APIs of the SAP Authorization and Trust Management Service [page 2495].
## Context
We recommend creating users within the SAP Cloud Identity Services. The persistency layer of SAP Cloud Identity Services is the Identity Directory. Use SAP Cloud Identity Services - Identity Provisioning to provision users to SAP cloud solutions, such as SAP BTP. Identity Provisioning has connectors to distribute user artifacts needed at different levels of your SAP BTP accounts. By managing your identities centrally, you also ensure that when you offboard users, they're removed from target systems.
## Procedure
Integrate with your identity and access management solution.
- To integrate with SAP Cloud Identity Services, see SAP BTP Integration Scenario for more information.
- To integrate with another solution, use the User Management SCIM API. See User Management (System for Cross-domain Identity Management (SCIM)) for more information.
##  Note
For user management of Cloud Foundry organizations, use the provisioning connectors of SAP Cloud Identity Services - Identity Provisioning. For more information, see SAP BTP Integration Scenario.
## 6.1.1.8.2.5  Delete Users
As an administrator, you can delete users from your subaccount. When you delete a user, you also delete the user's role collection assignments.
## Prerequisites
You have the required authorizations.
For more information, see Security Administration: Managing Authentication and Authorization [page 2278] or Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125].
## Context
All users in the subaccounts of SAP BTP are shadow users. As an administrator, you might want to clean up users from your subaccount. Or for data protection and privacy reasons, it might be a legal obligation that administrators delete shadow users who belonged to employees who left the company. For more information, see Working with Users [page 2342].
It's also possible to delete users using APIs. For more information, see the related links.
Keep in mind that you also delete the user's role collection assignments.
##  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.
##  Caution
You cannot undo the deletion of a user.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account, directory, or subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Users
##  Note
For directories, choose Users . There is no Security menu item.
4. Choose from the following options:
| Options               | Procedure                                                                                     |
|-----------------------|-----------------------------------------------------------------------------------------------|
| Delete a single user  | 1. Select the row of a user. 2. Choose  Delete .                                             |
| Delete multiple users | 1. Choose  Select multiple users and select users (see the related link). 2. Choose Delete . |
## Related Information
Working with Users [page 2342]
Deletion [page 3278] Delete Shadow Users for Data Protection and Privacy Using APIs [page 3282]
.
## 6.1.1.8.3 Working with Role Collections
As an administrator, you group application roles in role collections. You then assign role collections to application users.
Application developers have defined application-specific role templates in the security descriptor file. The role templates contain the role definitions. You can assign the role to a role collection.
##  Tip
Application developers can even directly define role collections with default roles. For more information, see Create Role Collections with Predefined Roles [page 569].
Typically, these role collections provide authorizations for certain types of users, for example, sales representatives.
Once you have created a role collection, you can pick the roles that apply to the typical job of a sales representative. Since the roles are application-based, you must reference the application to see which roles come with the role template of this application. You are free to add roles from multiple applications to your role collection.
Finally, you assign the role collection directly to users or indirectly to attributes such as groups. For more information, see the related link.
## Prerequisites
- Your user has administration rights in this subaccount and or global account. For more information, see Security Administration: Managing Authentication and Authorization [page 2278] or Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125].
- The roles defined by your application developers in the application security descriptor are available in the SAP BTP cockpit. For more information, see Adding Authentication and Authorization [page 530].
- The users are stored in identity providers that are connected to SAP BTP.
- Default identity provider ( SAP ID service ). For more information, see Default Identity Provider [page 2335].
- Custom identity provider. For more information, see User Management in SAP Cloud Identity Services.
##  Note
SAP BTP provides default role collections. You can use the default role collections, but you can't change or delete them. For this reason, the Delete icon of a default role collection is grayed out.
You can perform the following tasks:
- Define a Role Collection [page 2352]
- Add Roles to a Role Collection [page 2353]
- Delete Roles from a Role Collection [page 2354]
- Assigning Role Collections to Users or User Groups [page 2354]
- Assign Users to Role Collections [page 2355]
- Delete Users from Role Collections [page 2356]
- Assign User Groups to Role Collections [page 2356]
- Delete User Groups from Role Collections [page 2357]
## Related Information
Security Administration: Managing Authentication and Authorization [page 2278]
Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125] Limits for Technical Artifacts of the SAP Authorization and Trust Management Service [page 3248]
## 6.1.1.8.3.1  Define a Role Collection
To define a role collection, you can create a new role collection or copy an existing one. Add the roles, users, and user groups as needed.
## Context
One way to define a role collection is to create a new role collection. After you've entered a name and description, you find the new role collection in the list of role collections. Y ou can then add the roles you need and assign users and user groups.
If you have an existing role collection that you want to use as a template, it's a good idea to copy it. The copied role collection includes all of the roles of the origin. However, it doesn't include the users or user groups. You can give it a new name and description. You can find the copy in the list of role collections and assign users and user groups.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Role Collections .
4. To create a new role collection, choose Create . T o copy an existing role collection, choose Copy at the end of the row.
5. Enter a new name and description. If you copied an existing role collection, you can see the included roles.
6. Save your changes.
You can now add or remove roles and assign users or user groups.
## 6.1.1.8.3.1.1  Add Roles to a Role Collection
You can add roles to a role collection.
## Context
The roles are derived from role templates that are provided by applications. For more information, see the related links.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Role Collections .
4. To add roles, choose the role collection name.
5. Go to the Roles section and choose Edit .
6. To add a role to the role collection, choose the input field. The role selection screen opens.
7. Use the dropdown list or the F4 function key under Role Name to display the roles that are available. The roles are sorted alphabetically. Choose the role you want to add. You can also select multiple roles from the list below.
8. Choose Add .
9. Save your changes.
## Related Information
Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125] Protecting Your Application [page 533]
## 6.1.1.8.3.1.2  Delete Roles from a Role Collection
You can delete roles from a role collection.
## Context
The roles are derived from role templates that are provided by applications. For more information, see the related links.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Role Collections .
4. To delete roles, choose the role collection name.
To drill down into the role details, choose the chevron on the right side of the row.
5. Choose Edit .
6. Choose the  (Select multiple roles) button.
7. Select the roles you want to delete from the role collection.
8. Choose Remove .
9. Confirm the popup.
10. Save your changes.
11. Repeat to delete more roles.
## 6.1.1.8.3.2  Assigning Role Collections to Users or User Groups
You can assign role collections to users and user groups.
## Prerequisites
- You have administration rights in this subaccount or global account. For more information, see Security Administration: Managing Authentication and Authorization [page 2278] or Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125].
- The roles defined by your application developers in the application security descriptor are available in the SAP BTP cockpit. For more information, see Adding Authentication and Authorization [page 530].
- The users are stored in identity providers that are connected to SAP BTP.
- Default identity provider ( SAP ID service ). For more information, see Default Identity Provider [page 2335].
- Custom identity provider. For more information, see User Management in SAP Cloud Identity Services.
You perform the following tasks to assign role collections to users and user groups stored by identity providers. The identity providers are connected to SAP BTP using trust configurations.
##  Note
Custom identity providers can provide user groups and users whereas default identity providers can only provide individual users.
- Assign Users to Role Collections [page 2355]
- Delete Users from Role Collections [page 2356]
- Assign User Groups to Role Collections [page 2356]
- Delete User Groups from Role Collections [page 2357]
## 6.1.1.8.3.2.1  Assign Users to Role Collections
You can assign users to role collections by adding them to the desired role collection in the SAP BTP cockpit. Use this function to manage user authorizations and access control within your global account or subaccount in the cloud platform.
## Context
You can assign users to a role collection. After having entered the user's user ID, choose the name of the trust configuration and the e-mail address.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account or subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Role Collections .
4. Choose the role collection to which you want to assign users.
5. Go to the Users section and choose Edit .
6. Enter the user ID, identity provider, and e-mail address of the user that you want to assign to the role collection.
7. (Optional) To add more users, choose  (Add a user).
8. Save your changes.
You've now assigned this user to the role collection. The user has the authorizations of the role collection.
## 6.1.1.8.3.2.2  Delete Users from Role Collections
You can unassign users from a role collection by deleting them from the role collection.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Role Collections .
4. Choose the role collection from which you want to unassign users.
5. Choose Edit .
6. Choose  (Delete) in the row of the user you want to unassign.
7. Save your changes.
You've now unassigned this user by deleting the user from the role collection.
## 6.1.1.8.3.2.3  Assign User Groups to Role Collections
You can assign users groups to a role collection by adding them to the role collection.
## Prerequisites
- You're using a custom identity provider. For more information, see Trust and Federation with Identity Providers [page 2280].
## Context
You can assign user groups from custom identity providers to a role collection. After having chosen the identity provider, enter the user group name.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Role Collections .
4. Choose the role collection to which you want to assign user groups.
5. Go to the User Groups section and choose Edit .
6. Select the identity provider where the user group is stored.
7. Enter the name of the user group.
##  Note
If you're using SAP Cloud Identity Services, you can find the name of the user group in the administration console under Users &amp; Authorizations User Groups . For more information, see the related link.
8. (Optional) To add other user groups, choose  (Add a user group).
9. Save your changes.
## Related Information
User groups in the SAP Cloud Identity Services
## 6.1.1.8.3.2.4  Delete User Groups from Role Collections
You can unassign users groups from a role collection by deleting them from the role collection.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Role Collections .
4. Choose the role collection from which you want to unassign a user group.
5. Go the to User Groups section and choose  (Delete).
6. Confirm the popup and save your changes.
## 6.1.1.8.3.3  Mapping Role Collections
You've arranged roles in role collections, and now want to assign or map these role collections to business users.
How you assign users to their authorizations depends on the type of trust configuration and on whether or not you prefer to maintain the authorizations of individual users rather in the identity provider or in SAP BTP. The following options are available:
- Directly assign role collections to users.
- Map role collections to user groups or other user attributes defined in the identity provider. You initially maintain the mapping between user groups or other user attributes and role collections once in SAP BTP, and maintain group memberships or other attributes of users in the identity provider.
##  Note
If you're using the default trust configuration with the default identity provider, you directly assign users to role collections. For more information, see Default Identity Provider [page 2335].
However, if you're using a custom trust configuration, for example, with SAP Cloud Identity Services, you can use more options. For more information about configuring the trust between your subaccount and a custom identity provider, see Establish Trust and Federation Between SAP Authorization and Trust Management Service and SAP Cloud Identity Services [page 2282]. For more information about configuring the trust between your global account and a custom identity provider, see Establish Trust and Federation of Custom Identity Providers for Platform Users [page 2316].
Options for Assignment of Role Collections
| Trust Configuration                                                               | Assignment Options                                                                                                                                                       |
|-----------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Default trust configuration (SAP ID service)                                      | Assign Users to Role Collections [page 2355]                                                                                                                             |
| Custom trust configuration (for example: a tenant of SAP Cloud Identity Services) | • Assigning Role Collections to Users or User Groups [page 2354] • Map Role Collections to User Groups [page 2358] • Map Role Collections to User Attributes [page 2360] |
## Related Information
Working with Role Collections [page 2351]
Trust and Federation with Identity Providers [page 2280]
## 6.1.1.8.3.3.1  Map Role Collections to User Groups
You want to assign a role collection to a user group provided by an identity provider that has a custom trust configuration in SAP BTP. In this case, the assignment is a mapping of a user group to a role collection. Your
identity provider provides the user groups using the attribute called Groups . Each value of the attribute is mapped to a role collection as described in this procedure.
## Prerequisites
- You've configured your custom identity provider and established trust with your subaccount.
##  Remember
The name of the trust configuration is different from SAP ID service. The name of a custom trust configuration to SAP Cloud Identity Services could be as follows:
https://&lt;tenant\_id&gt;.accounts.ondemand.com
- You've configured the identity provider so that it conveys the user's group memberships in the groups attribute.
- For business users, see Map User Attributes from a Corporate Identity Provider for Business Users [page 2284].
- For platform users, see Map User Attributes from a Corporate Identity Provider for Platform Users [page 2322].
- You've created role collections.
## Context
The identity provider provides the users, who can belong to user groups. It's efficient to map user groups to role collections. The role collection as a reusable element contains the authorizations that are necessary for this user group. Mappings save time when you want to add a new user. Simply add the user to the respective user group or groups, and the user automatically gets all the authorizations that are included in the role collections.
## Procedure
To map a user group to a role collection, see Assign User Groups to Role Collections [page 2356].
You can also map role collections to attributes other than groups. For more information, see the related links.
## Related Information
Trust and Federation with Identity Providers [page 2280] Map Role Collections to User Attributes [page 2360]
## 6.1.1.8.3.3.2  Map Role Collections to User Attributes
Map role collections to users dynamically through the use of user attributes. When user agents present the attributes of their users, the SAP Authorization and Trust Management service can assign role collections based on the values of those attributes.
## Prerequisites
- You've configured your custom identity provider and established trust with your subaccount.
- You've configured the identity provider so that it conveys the user attributes in the assertion attributes.
- For business users, see Map User Attributes from a Corporate Identity Provider for Business Users [page 2284].
- For platform users, see Map User Attributes from a Corporate Identity Provider for Platform Users [page 2322].
- You've created role collections.
## Context
The identity provider hosts the users and their attributes. When a user is authenticated by the SAP Authorization and Trust Management service, a user agent presents a number of attributes of the user, such as an e-mail address. The SAP Authorization and Trust Management service uses this attribute to identify the user. You can use such attributes to assign role collections. For example, you can use the company\_region attribute to assign role collections specific to the provinces or states your users are located. More use cases are to have different role collections for different cost centers or job functions. Mapping role collections to the attribute Groups is so common that we have a separate use case for it. For more information, see Map Role Collections to User Groups in the related links.
##  Tip
Mappings save time when you add new users. Simply set the relevant attributes in the identity provider for the users, and the users automatically gets all the authorizations that are included in the role collections.
## Procedure
1. Go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Role Collections .
2. Search for and choose a role collection.
3. In the overview page for the role collection, choose the Edit button.
4. Under Attribute Mapping , select an identity provider.
5. Enter the name of the attribute and the value for the SAP Authorization and Trust Management service to use to map the role collection to users. The attributes are combined with logical OR operations. If you assign multiple attributes to the role collection, and one of them is true, the users with this attribute are assigned to this role collection.
6. Save your entries.
<!-- image -->
## Related Information
Trust and Federation with Identity Providers [page 2280] Map Role Collections to User Groups [page 2358] Create Role Collections with Predefined Roles [page 569]
## 6.1.1.8.4 Building Roles and Role Collections for Applications
As an administrator, you can maintain application roles and role collections which can be used in user management.
The user roles are derived from role templates that are defined in the security description ( xssecurity.json ) of applications that have been registered as OAuth 2.0 clients at the User Account and Authentication service during application deployment. The application security-descriptor file also contains details of the authorization scopes that are used for application access and defines any attributes that need to be applied. The roles you create can be added to role collections.
You can perform the following tasks:
- Create and delete user roles User roles define authorization scopes and are based on the role templates and scopes defined in the application's security descriptor file
- Add user roles to one or more 'role collections'
- Configure and manage role collections
##  Tip
Using the SAP BTP cockpit, you can assign the role collections to users directly or indirectly over attributes, such as groups.
## Related Information
Add Roles to Role Collections on the Application Level [page 2370]
Mapping Role Collections [page 2358] Protecting Your Application [page 533] Working with Role Collections [page 2351] Limits for Technical Artifacts of the SAP Authorization and Trust Management Service [page 3248] Adding Authentication and Authorization [page 530]
## 6.1.1.8.4.1  Roles and Role Collections
Usually a role collection consists of one or multiple roles. You can use the SAP BTP cockpit to add or remove roles.
## Role
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. The SAP BTP cockpit helps you to display information about the selected application and any related roles in the following windows, tabs, and panes:
- Roles
- Scopes
- Attributes
- Role templates
## Role Collection
Roles are assigned to role collections which are assigned in turn to users or user groups if an SAML 2.0 identity provider stores the users. Using the SAP BTP cockpit, you can display information about the role collections that have been maintained as well as the roles available in a role collection. Additional information includes: which templates the roles are based on, and which applications the roles apply to. Role collections enable you to group together the roles you create. The role collections you define can be assigned as follows:
- To users logged on to the SAP ID service .
- To user groups containing users logging on with SAML 2.0 assertions.
## Related Information
Attributes [page 2365]
## 6.1.1.8.4.2  Create Roles for Applications Using Existing Role Templates
Use the SAP BTP cockpit to create a role using an existing role template. You can refine the role by assigning attributes and add the role to role collections.
## Context
You can use existing role templates to create new roles. An SAP BTP cockpit wizard helps you to configure new roles.
##  Note
You can only create roles from roles templates that come with attributes.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security in the navigation pane.
4. Choose Roles .
Here you see a complete list of all existing roles sorted by application name. It also contains the role template, role names, and role description. On the right side, you find the action buttons.
5. Choose Create Role in the row of the role template that you want to use.
The Create Role wizard opens.
6. Enter a role name and a description, and choose Next .
7. Configure the attributes and choose Next . The attributes further refine the role. For more information, see the related link.
8. Select the available role collections for your new role and choose Next .
9. You can review your role configuration in the next window and complete the creation of the role by choosing Finish .
## Related Information
Attributes [page 2365]
## 6.1.1.8.4.3  Create Roles for Subscribed Applications Using Existing Role Templates
Use the SAP BTP cockpit to create a role for a subscribed application using an existing role template. You can refine the role by assigning attributes and add the role to role collections.
## Context
You can use existing role templates to create new roles. An SAP BTP cockpit wizard helps you to configure new roles.
##  Note
You can only create roles from roles templates that come with attributes.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Services Instances and Subscriptions in the navigation pane.
4. To see your subscribed application, choose the Subscriptions tab.
5. To get to the place where you can manage roles, choose the chevron next to your subscribed application.
6. Here you see a complete list of all existing roles sorted by the role template. It also contains the role names and the role description. On the right side, you find the action buttons.
6. To add more roles, choose Create .
The Create Role wizard opens.
7. Enter a role name and a description, and choose Next .
8. Configure the attributes and choose Next . The attributes further refine the role. For more information, see the related link.
9. Select the available role collections for your new role and choose Next .
10. You can review your role configuration in the next window and complete the creation of the role by choosing Finish .
11. (Optional) Use  (Add to role collection) to add a role to a role collection.
## Related Information
Configure Application Roles and Assign Roles to Users [page 2277] Attributes [page 2365]
## 6.1.1.8.4.4  Delete Roles
Use the SAP BTP cockpit to delete a role. If this role has been added to a role collection, it's also deleted from the role collection.
## Context
You can use existing role templates to create new roles. An SAP BTP cockpit wizard helps you to configure new roles.
##  Note
You cannot delete roles that belong to default role collections delivered by SAP BTP.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. If your role comes with a subscribed application, continue as described in Configure Application Roles and Assign Roles to Users [page 2277].
4. Choose Security in the navigation pane.
5. Choose Roles .
Here you see a complete list of all existing roles sorted by application name. It also contains the role template, role names, and role description. On the right side, you find the action buttons.
6. Choose the  (Delete) action button in the row of the role that you want to delete. If the role has been added to a role collection, it's also deleted from the role collection.
7. Confirm that you want to delete the role.
## 6.1.1.8.4.5  Attributes
Attributes use information that is specific to the user, for example the user's country. If the application developer in the Cloud Foundry environment of SAP BTP has created a country attribute to a role, this restricts the data a business user can see based on this attribute.
A lot of applications provide purely functional role templates which grant access for all data of a certain type within your subaccount. Roles for such role templates are generated automatically. Some other applications also provide the possibility for administrators to restrict access not only by functional authorizations, but also by instance-based authorizations. That means that users can only work with a certain subset of the data in your subaccount.
The restriction can be either based on information within the respective role, or on user-specific information provided by the identity provider. This makes instance-based authorizations specific for each customer
because the respective roles cannot be generated automatically. Instead, administrators must create them. Typical restrictions depend on information like the user's country or cost center.
Each restriction is represented by a dedicated attribute which belongs to a role template of the application.
##  Note
Application developers can define attribute references in the application security descriptor file ( xssecurity.json ): For more information, see Application Security Descriptor Configuration Syntax [page 576].
For each attribute, administrators have multiple options to specify the value which restricts data access:
- Static attributes They are stored in the role. The user is given the attribute value when the administrator assigns the role collection with this role to the user.
- Attributes from a custom identity provider Since an identity provider provides the business users, you can dynamically reference all attributes that come with the SAML 2.0 assertion. You define the attributes and the attribute values in the identity provider. In the Cloud Foundry environment of SAP BTP, administrators can use the attributes to refine the roles.
##  Note
If you want to reference attributes from your identity provider, you must know the exact identifier of the attribute. Go to the SAML 2.0 or OpenID Connect configuration of your identity provider and use the attributes as they are defined there.
- Unrestricted attributes In this case, you want to express that it is not necessary to set a specific value for this attribute. The
behavior is the same as if the attribute would not exist for this role.
## Related Information
Specify Attributes in a Role [page 2367]
Specify Attributes in a New Role [page 2368]
## 6.1.1.8.4.6  Add Roles to Role Collections on the Application Level
Roles are used to define the type of access granted to an application.
## Context
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 collections are then assigned to SAML 2.0 groups or users. The role template defines the type of access permitted for an application, for example: the authorization scope, and any attributes that need to be applied. Attributes define information that comes with the respective user, for example 'cost center' or 'country' (see the related link). This information can only be resolved at run time.
##  Note
The User Account and Authentication service automatically creates default roles for all role templates that do not include attribute references. They have the same name as the role template. You can't delete them. You can recognize them because their description contains Default Instance .
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security in the navigation pane or go to Cloud Foundry Spaces &lt;your\_space&gt; &lt;your\_application&gt; .
4. Choose Security Roles in the navigation pane.
Here you see a complete list of all roles sorted by role templates. It also contains information about attributes used in this role and about the role collections the role has been added to. On the right side, you find the action buttons.
##  Note
You cannot edit or delete predefined roles for default role collections. For this reason, the action buttons are grayed out. For more information, see the related link.
5. To directly assign a role to role collections, choose the action button  (Add to role collection) in the same row.
A new window shows all role collections that are available in your global account or subaccount.
6. Select the role collections to which you want to add your role.
7. Choose Add .
The number in the role collections column counts up. You have now assigned this role to the role collections you selected earlier.
## Related Information
Attributes [page 2365]
Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125]
## 6.1.1.8.5 Managing Secrets of the SAP Authorization and Trust Management Service
The SAP Authorization and Trust Management service maintains a number of secrets to ensure secure operation of the service. Your organization can have policies that require you change secrets or you may need to respond to the loss of a secret.
The SAP Authorization and Trust Management service uses the following secrets in its operation:
- Service Instance Secrets [page 2371]
- Rotate Binding Secrets [page 2373]
- Migrate from Instance Secrets to Binding Secrets [page 2376]
- Rotating Instance Secrets [page 2377]
- Binding Parameters of SAP Authorization and Trust Management Service [page 2378]
- Rotate Signing Keys of Access Tokens [page 2384]
- Rotate Signing Keys of SAML Token [page 2390]
## 6.1.1.8.5.2  Rotate Binding Secrets
Service instances of the SAP Authorization and Trust Management service use different binding secrets for each binding. To rotate binding secrets, unbind and rebind any consuming applications.
## Prerequisites
- You've enabled support for binding secrets. For more information, see Migrate from Instance Secrets to Binding Secrets [page 2376].
- If you have to replace any service keys, create the new service keys before proceeding. For more information, see Creating Service Keys [page 259].
## Procedure
1. Unbind the application that consumes your service instance.
Use the following syntax:
```
cf unbind-service <APP_NAME> <SERVICE_INSTANCE>
```
```
cf unbind-service my-app my-xsuaa-service
```
2. Rebind the application that consumes your service instance.
Use the following syntax:
```
cf bind-service <APP_NAME> <SERVICE_INSTANCE> [-c <PARAMETERS_AS_JSON>]
```
```
cf bind-service my-app my-xsuaa-service
```
## Results
When you rebind the application, the system creates a new binding secret.
## Next Steps
Delete any old service keys that you don't need anymore.
## Related Information
Service Instance Secrets [page 2371]
## 6.1.1.8.5.3  Rotate X.509 Secrets
When your private key is exposed or your certificates are about to expire, it's time to rotate secrets. Rotating secrets can be as easy as unbinding and rebinding your application or service key.
## Prerequisites
- If you provide your own certificates, you've prepared new certificates.
- If you need to replace any service keys, create the new service keys before proceeding. For more information, see Creating Service Keys [page 259].
## Context
##  Note
The service doesn't check for certificate revocation. To stop the service from accepting a certificate that is still valid, delete the relevant bindings or service keys. As soon as the binding is deleted, the service stops accepting the certificate.
For bindings with self-managed certificates and the certificate-pinning parameter set to false , you can rotate the secrets without deleting bindings. Just use a new certificate with the same subject and issuer distinguished name (DN). The service saves the new validity date of the new certificate.
For more information, see Parameters for Self-Managed X.509 Certificates [page 2381].
## Procedure
1. Unbind the application that consumes your service instance.
Use the following syntax:
```
cf unbind-service <APP_NAME> <SERVICE_INSTANCE>
```
```
cf unbind-service my-app my-xsuaa-service
```
2. Rebind the application that consumes your service instance.
Use the following syntax:
```
cf bind-service <APP_NAME> <SERVICE_INSTANCE> [-c <PARAMETERS_AS_JSON>]
```
```
cf bind-service my-app my-xsuaa-service -c parameters.json
```
If you provide your own certificates, include them in a parameters.json file.
## Related Information
Binding Parameters of SAP Authorization and Trust Management Service [page 2378]
```
Binding Service Instances to Applications [page 257] Service Instance Secrets [page 2371]
```
## 6.1.1.8.5.4  Migrate from Instance Secrets to Binding Secrets
To simplify the management of secrets for service instances of the SAP Authorization and Trust Management service, we recommend that you configure service instances to use binding secrets.
## Context
By default, service instances of the SAP Authorization and Trust Management service use the instance secret for all bindings of the service instance. In the application security descriptor ( xs-security.json ), enable binding secrets for service instances. All bindings have their own secret. You can enable both at once for the following plans:
- Application plan
The API access plan only uses binding secrets.
## Procedure
1. Modify the application security descriptor ( xs-security.json service use the instance) to support both instance secrets and binding secrets.
Edit the OAuth client configuration of the xs-security.json as follows:
```
 Sample Code "oauth2-configuration": { "credential-types": ["binding-secret","instance-secret"] }
```
2. Update the service instance with the new application security descriptor.
3. Unbind and rebind any consuming applications.
With each new binding, the system creates a new binding secret.
4. Replace any service keys with new service keys.
At this point, none of the applications consuming your service instance need the instance secret anymore.
5. Modify the application security descriptor ( xs-security.json ) to disable support for instance secrets.
Edit the OAuth client configuration of the xs-security.json as follows:
```
 Sample Code "oauth2-configuration": { "credential-types": ["binding-secret"] }
```
6. Update the service instance with the new application security descriptor.
## Related Information
Update a Service Instance [page 561]
```
Creating Service Keys [page 259] Service Instance Secrets [page 2371]
```
## 6.1.1.8.5.5  Rotating Instance Secrets
When configured for instance secrets, a service instance of the SAP Authorization and Trust Management service uses the same instance secret for all bindings. You can't really rotate instance secrets, but must rotate the applications and service instance together.
##  Recommendation
Migrate to using binding secrets instead of instance secrets.
Using instance secrets forces you to redeploy the entire application under a new xsappname and repeat the assignment of any role collections.
For more information, see Migrate from Instance Secrets to Binding Secrets [page 2376].
## Related Information
Service Instance Secrets [page 2371]
## 6.1.1.8.5.6  Binding Parameters of SAP Authorization and Trust Management Service
When binding applications or creating service keys for services instances of the SAP Authorization and Trust Management service (XSUAA), provide configuration parameters in JSON format.
Set parameters according to the following use cases:
- For instance or binding secrets, you want to supress the creation of client secrets.
- For X.509 secrets, set parameters according to the following scenarios:
- The SAP Authorization and Trust Management service generates certificates for you.
- You already have your own public key infrastructure (PKI), with certificates issued from one of the supported certificate authorities (CA). See the links in the related information.
##  Remember
The types of secrets that a service instance can accept in a binding or service key is configured in the application security descriptor ( xs-security.json ).
For more information, see Application Security Descriptor Configuration Syntax [page 576].
## Related Information
Parameters for Suppressing Client Secrets [page 2378]
Parameters for X.509 Certificates Managed by SAP Authorization and Trust Management Service [page 2380]
Parameters for Self-Managed X.509 Certificates [page 2381]
Trusted Authorities for X.509 Certificates [page 2384]
Limits for Technical Artifacts of the SAP Authorization and Trust Management Service [page 3248]
## 6.1.1.8.5.6.1  Parameters for Suppressing Client Secrets
When binding or creating a service key for an xsuaa service instance, you can pass some parameters in JSON format or in a JSON file (see cf bind-service and cf create-service-key in the related links). The "hide-secret" element enables you to suppress the client secret when binding or creating a service key. It's useful if some applications only want to bind the xsuaa service for authorization purposes.
## Prerequisites
- In the application security descriptor file ( xs-security.json ), you've included the 'credential-type' key with "instance-secret" and/or "binding-secret" when you created or updated the service instance. The "hide-secret" element is only taken into account if the credential type is "instancesecret" or "binding-secret" .
##  Note
If the "credential-type" element isn't defined in the binding descriptor, it defaults to the first value of the array passed as "credential-types" in xs-security.json for the service instance or for the first value of the default list.
For more information, see Application Security Descriptor Configuration Syntax [page 576].
## Parameters for Suppressing Client Secrets
The cf create-binding or cf create-service-key commands expect a valid parameters.json file containing the service-specific configuration parameters in the following format.
```
 Sample Code { "credential-type": "instance-secret", "hide-secret": "true" }
```
```
 Sample Code { "credential-type": "binding-secret", "hide-secret": "true" }
```
The hide-secret element defines whether the client secret is omitted.
Element for Suppressing Client Secrets
| Element     | Value           | Description                                                 |
|-------------|-----------------|-------------------------------------------------------------|
| hide-secret | true            | The client secret is omitted in the bind- ing information.  |
|             | false (default) | The client secret is included in the bind- ing information. |
## Related Information
Cloud Foundry CLI Reference
## 6.1.1.8.5.6.2  Parameters for X.509 Certificates Managed by SAP Authorization and Trust Management Service
Use the parameters to have the service generate X.509 certificates for you.
## Prerequisites
You've enabled the service instance to use X.509 secrets.
For more information, see Application Security Descriptor Configuration Syntax [page 576].
## Parameters for Certificates Managed by the Service
The create-binding or create-service-key commands expect a parameters.json in the following format.
```
{ "credential-type": "x509", "x509": { "key-length": 2048, "validity": 8, "validity-type": "DAYS" } }
```
The following table describes the supported parameters.
Parameters for Service-Managed Certificates
## Parameter
Description
| credential-type   | Only required to use X.509 when X.509 isn't specified as default in the application security descriptor ( xs- security.json ). For more information, see Application Security Descriptor Configuration Syntax [page 576].   |
|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| x509              | In this parameter, you define the certificate options of key length, validity period, and unit of length. This parameter is optional.                                                                                       |
| key-length        | Specifies the byte length of the generated private key. The default length is 2048 bytes. You can also choose 4096 bytes or 8192 bytes.                                                                                     |
| Parameter     | Description                                                                                                                                                        |
|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| validity      | Specifies the number of time units for validity-type . The default value is 7. Together with the validity-type the range of validity runs from 1 DAYS to 30 DAYS . |
| validity-type | Specifies the time unit for validity. Supported value is DAYS . The default value is DAYS .                                                                        |
## Related Information
Service Instance Secrets [page 2371]
## 6.1.1.8.5.6.4  Trusted Authorities for X.509 Certificates
Service instances of the SAP Authorization and Trust Management service (XSUAA) trust the following certificate authorities (CA). To use your own public key infrastructure (PKI) for bindings, the certificates must be issued from one of these CAs.
Supported CAs for X.509 Certificates
| Subject                                                                                              | Issuer                                                                                               | Validity                |
|------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|-------------------------|
| C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2                                | C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2                                | Jan 15 12:00:002038GMT  |
| C=DE, L=Walldorf, O=SAP AG, CN=SAP Global Root CA                                                    | C=DE, L=Walldorf, O=SAP AG, CN=SAP Global Root CA                                                    | Apr 26 15:46:272032GMT  |
| C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA                                | C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA                                | Nov 10 00:00:00 2031GMT |
| C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 Secure Server CA                         | C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA                                | Sep 22 23:59:592030GMT  |
| C=US, O=Entrust, Inc., OU=www.entrust.net/ legal-terms, CN=Entrust Root Certification Authority - G2 | C=US, O=Entrust, Inc., OU=www.entrust.net/ legal-terms, CN=Entrust Root Certification Authority - G2 | Dec 07 17:55:542030GMT  |
## Related Information
Parameters for Self-Managed X.509 Certificates [page 2381] Service Instance Secrets [page 2371]