orkungedik/SAP-basis-dataset huggingface dataset:
## 6.1.1.4 Managing Directories Using the Cockpit
Learn how to organize and manage your subaccounts according to your technical and business needs by using directories in the SAP BTP cockpit.
## Context
## Procedure
1. Learn how to Create a Directory [page 2242].
2. Learn how to Manage the Account Explorer Hierarchy [page 2244].
3. Learn how to Manage Users in Directories [page 2245].
4. Learn how to View Directory Usage Analytics [page 2247].
## Related Information
Directories [page 113] Managing Subaccounts Using the Cockpit [page 2249]
## 6.1.1.4.2 Manage the Account Explorer Hierarchy
Create an account structure by creating a hierarchy of directories and subaccounts using the SAP BTP cockpit. Add, move, and delete subaccounts and directories in your structure.
## Context
Here, you'll learn how to:
- Add directories and subaccounts to a directory
- Move directories and subaccounts in the account structure
- Delete directories and subaccounts from the account structure
- Export the account structure to Microsoft Excel format.
A subaccount moves with its assigned service plans and quota. The entitlements of the source and target directories are adjusted accordingly.
If any entitlement for a plan in the target directory is configured with the auto-assign option, it is then automatically applied to the moved subaccount. Automatic quota assignments are subject to available quota in the target directory.
You can create a hierarchical structure that is up to 7 levels deep. The highest level of a given path is always the global account and the lowest is a subaccount, which means that you can have up to 5 levels of directories between the global account and the lowest level subaccount.
## Procedure
- Add directories and subaccounts to a directory.
- In the Create dropdown, choose Directory . When creating the new directory, you choose its location in the account structure by selecting its
- parent directory or the global account directly in the creation dialog box.
- You can also create a directory by selecting Create Directory from the  Actions menu button for the global account or a specific parent directory.
- Move subaccounts in the account structure.
- Click  Actions and select Edit . Then select a new parent.
- Click  Actions and select Move . Then select a new parent.
- Click  Move to move subaccounts by drag and dropping.
- Delete directories and subaccounts from the account structure.
- Click  Actions and select Delete .
- To delete a subaccount, you can also navigate into the subaccount and click Delete Subaccount .
- Export the account structure to Microsoft Excel format.
- Click  Export .
The exported Microsoft Excel file contains a sheet (tab) called Account Structure , which lists all the subaccounts and directories in the account structure, and includes information about each entity. Each subaccount and directory displays its name, ID, description, path, creation/change dates, and the user that created it.
Subaccounts also display information about their environment, provider, region, used for production setting, and whether the beta feature option is enabled. Directories also display whether they are configured to manage users and entitlements.
## Related Information
Directories [page 113]
Create a Directory [page 2242]
Create a Subaccount [page 2249]
Delete a Subaccount [page 2260]
## 6.1.1.4.3 Manage Users in Directories
Manage members in your directory using the SAP BTP cockpit.
## Prerequisites
- You're a directory administrator.
- User management is enabled for this directory. If the feature isn't enabled already, you can do so using one of the following methods:
- Go to the Account Explorer page, edit the directory, and then under Advanced , choose the Enable User Management option.
- Navigate into the directory from the Account Explorer page, and then in the Users page, choose the Enable Entitlement and User Management option (if entitlement management is already enabled for the directory, then choose the Enable User Management option instead).
##  Note
- The user management feature can be enabled only in combination with the entitlement management feature on the same directory in given path.
- Only a single directory in any given directory path can have the user management and/or entitlement management features enabled. See Configure Entitlements and Quotas for Directories [page 2264].
For example, if you have 3 stacked directories in your account hierarchy and the middle directory has both the user and entitlement management features enabled, then neither of these features can be enabled for its parent or child directory since these two directories are in the same direct path as the middle directory.
· Your platform user exists in a trusted identity provider. All users of SAP BTP are stored in identity providers, either in the default or in a custom identity provider. SAP BTP needs a copy of the user, sometimes called a shadow user. You assign the shadow user authorizations to access resources in SAP BTP. When a user authenticates, SAP BTP forwards the request to the identity provider. For more information, see Trust and Federation with Identity Providers [page 2280].
## Context
Assign predefined or custom role collections to users who need to manage or view the directory in SAP BTP cockpit. Examples of predefined role collections include the following:
- Directory Administrator
- Directory Viewer
For more information about these role collections, see Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125].
## Procedure
1. Navigate to your directory.
2. Add a user to your directory.
For more information, see Create Users [page 2347].
3. Assign a role collection to the user.
For more information, see Assign Users to Role Collections [page 2355].
## Results
The next time this user logs on to the SAP BTP cockpit, the user can access this directory.
## Related Information
Working with Users [page 2342]
Role Collections and Roles in Global Accounts, Directories, and Subaccounts [page 125]
## 6.1.1.5 Managing Subaccounts Using the Cockpit
Learn how to structure a global account according to your organization's and project's requirements with regard to members, authorizations, and entitlements by managing subaccounts.
## Context
To learn more about the concept of subaccounts, see Subaccounts [page 112].
## Procedure
1. Learn how to create subaccounts.
Create a Subaccount [page 2249]
2. Learn how to manage users.
Add Members to Your Subaccount [page 2253]
3. Learn how to administer your subaccount.
- Change Subaccount Details [page 2256]
- View Subaccount Usage Analytics [page 2258]
- Delete a Subaccount [page 2260]
## 6.1.1.5.3 Enable Environment or Create Environment Instance
Enable an environment or create an environment instance using the SAP BTP cockpit.
## Prerequisites
- You're managing a multi-environment subaccount.
- You're a subaccount administrator.
- You have free quota assigned to your subaccount.
## Context
On a subaccount level, environments constitute the actual platform-as-a-service (PaaS) offering of SAP BTP that allows for the development and administration of business applications.
Each environment comes equipped with specific tools, technologies, and runtimes that you need to build applications. The availability of different environments allows for greater flexibility in your development process.
For more information, see Environments [page 56].
## Procedure
1. Navigate into the subaccount.
2. Choose your method: Enable Environment or Create an Environment Instance .
- Enable Environment : On the Subaccount - Overview page, click Enable &lt;Environment&gt; .
- Create an Environment Instance : See Environment Instances.
## Results
You can use the environment or environment instance in your subaccount.
## 6.1.1.5.6 Delete a Subaccount
Delete subaccounts using the SAP BTP cockpit to clean up your account hierarchy, free up quota used by services in your subaccounts, and to reduce overall costs.
## Delete a Subaccount
## Prerequisites
- You're a global account administrator.
## Procedure
1. In the cockpit, go to the Account Explorer page of your global account.
2. In the account hierarchy, locate the subaccount that you want to delete.
3. In the Actions (  ) context menu of the subaccount, choose Delete .
The cockpit first checks if the subaccount contains data, such as active subscriptions, service instances, brokers, or platforms.
4. If the subaccount is empty, then confirm the operation, after which the subaccount is deleted.
If you are a subaccount administrator and the subaccount contains data, such as applications, service instances, spaces, active subscriptions, brokers, and members, then we strongly recommended that you visit the Instances and Subscriptions page to review the content in the subaccount and to manually remove the content from there. Then you can come back and safely delete the subaccount.
##  Note
If you are not a subaccount administrator, then you won't be able to access the Instances and Subscriptions . Instead, you'll have to ask a subaccount administrator in your organization to review the content in this subaccount and to manually remove the content from there.
##  Caution
If the subaccount contains data, you may have the option to force delete it. This option deletes the subaccount and all its data. Force deletion is available only if the force deletion of subaccounts is enabled in the global account settings and if the subaccount isn't marked as used for production.
You must use this option with extreme caution because any data in the subaccount is deleted permanently, including productive data, without any recovery option.
It is your responsibility to confirm that the subaccount is safe to delete before using the force-delete option. If you cannot check the content of the subaccount, you can get the subaccount reviewed by other qualified members of your organization.
##  Note
The deletion may take up to 12 hours to complete depending on the amount of content in your subaccount. If your subaccount contains service instances, subscriptions, and runtime environments, these need to be deprovisioned as part of the purge operation, which is a timely process. After the subaccount is deleted, it could take a few more days for some related services to be deleted. Note that you won't be charged for any continued usage of these services in the subaccount during the deletion cleanup.
## Related Information
Navigate in the Cockpit [page 2207]
Relationship Between Global Accounts, Subaccounts, and Directories [page 115]
## 6.1.1.7.1 Configure Application Roles and Assign Roles to Users
View, create, and modify application roles and then assign users to these roles using the SAP BTP cockpit.
## Prerequisites
Your subaccount is subscribed to a multitenant application in the Cloud Foundry environment. See Subscribe to Multitenant Applications Using the Cockpit [page 2274].
## Context
You can use any SAML 2.0 standard compliant identity provider. See Trust and Federation with Identity Providers [page 2280].
## View, Create, and Modify Application Roles
## Procedure
1. Navigate to your subaccount. For more information, see Navigate in the Cockpit [page 2207].
2. In the navigation area, choose Services Instances and Subscriptions .
3. Under the Subscriptions table, click on the row with the application for which you want to manage app roles to open its Overview page.
4. Open the tab Roles to view, create, and modify the application roles.
##  Tip
You can also manage roles without opening the application overview page, by selecting the three dots at the end of the application row. Choose Manage Roles from the drop-down menu.
## Assign Users to Application Roles
## Procedure
1. Navigate to your subaccount. For more information, see Navigate in the Cockpit [page 2207].
2. Choose Security Roles Collections in the navigation area and include the roles into the roles collection.
3. Choose Security Trust Configuration and assign role collections to users.
## Related Information
User and Member Management [page 121]
## 6.1.1.8.1.1  Business Users
User accounts enable users to log on to SAP BTP, access subaccounts, and to use applications according to the permissions granted to them. In this context, it's important to understand the difference between the two types of users that we refer to: business users and platform users.
Business users use the applications that are deployed to SAP BTP. For example, the end users of SaaS apps or services, such as SAP Build Work Zone, or end users of your custom applications are business users.
In the Cloud Foundry environment, application developers (platform users [page 2316]) create and deploy application-based security artifacts for business users. Administrators use these artifacts to assign roles, build role collections, and then assign those role collections to business users or user groups. The assignment of role collections enables administrators to control the permissions that the users have in the deployed applications.
For business users, there's a default identity provider [page 2335]. We expect that you have your own user base. We recommend that you configure the SAP Cloud Identity Services service as the identity provider and connect SAP Cloud Identity Services to your own corporate identity provider.
## Related Information
Platform Users [page 2316]
Establish Trust and Federation Between SAP Authorization and Trust Management Service and SAP Cloud Identity Services [page 2282]
Manually Establish Trust and Federation Between SAP Authorization and Trust Management Service and SAP Cloud Identity Services [page 2302]
Establish Trust and Federation with UAA Using Any SAML Identity Provider [page 2306]
Using Multiple Identity Providers from the Same Subaccount [page 2311]
## 6.1.1.8.1.1.2.1  Prepare for Migration from SAML Trust to OpenID Connect
Before migrating your trust configuration, check which user data are sent today, so you can validate the new configuration after the migration. If you use a corporate identity provider, prepare the trust between your SAP Cloud Identity Services tenant and your corporate identity provider ahead of time.
## Procedure
1. Check what attributes your users have.
To see what attributes your user has, open the following page of your subaccount:
https://&lt;subaccount\_subdomain&gt;.authentication.&lt;region&gt;.hana.ondemand.com/config? action=who&amp;details=true&amp;trustMigrationOnly=true
## For example
https://my-subdomain.authentication.eu10.hana.ondemand.com/config? action=who&amp;details=true&amp;trustMigrationOnly=true
If at logon you see multiple identity providers, choose the one you want to migrate from for your applications.
##  Remember
Save the results. You'll need to compare the attributes with the attributes you get after migrating the trust configuration.
For an example, see Test the Trust Configuration After the Migration [page 2298].
2. Determine if you need to establish trust between your corporate identity provider and your SAP Cloud Identity Services tenant.
If you previously had configured your subaccount trust to your corporate identity provider directly, configure your SAP Cloud Identity Services tenant to trust your corporate identity provider.
<!-- image -->
## Insertion of SAP Cloud Identity Services in Trust Chain of Identity Providers
In the preceding figure, we're configuring the SAML or OIDC trust between the SAP Cloud Identity Services tenant and the corporate identity provider. Configure the corporate identity provider to send the same value for subject name identifier and the attributes. Keep the attribute names the same, too, except for the attribute names listed in the following table.
## From User Attribute
## To Assertion Attribute
| first_name   | given_name   |
|--------------|--------------|
| last_name    | family_name  |
| mail         | email        |
For more information, see Corporate Identity Providers in the documentation of SAP Cloud Identity Services.
## 6.1.1.8.1.1.2.3  Configuration of SAP Cloud Identity Services After Migration from SAML to OIDC
You replaced an SAML trust configuration to your custom identity provider with an OIDC trust configuration to SAP Cloud Identity Services. Now, you need to make sure that the subaccount gets the same user attributes (names and values) as before.
How you proceed depends on which architecture you're trying to achieve. We provide guidance for the configuration according to your target architecture.
- Business users authenticate directly with SAP Cloud Identity Services See SAP Cloud Identity Services Without Corporate Identity Provider [page 2296].
- Business users authenticate with a corporate identity provider. SAP Cloud Identity Services is a proxy:
- Identity federation is disabled (default flow)
- Identity federation is enabled (advanced)
See SAP Cloud Identity Services with Corporate Identity Provider [page 2296].
## Related Information
Migration from SAML Trust to OpenID Connect Trust with SAP Cloud Identity Services [page 2288] Restore SAML Trust Configuration [page 2300] Map User Attributes from a Corporate Identity Provider for Business Users [page 2284]
## 6.1.1.8.1.1.2.3.1  SAP Cloud Identity Services Without Corporate Identity Provider
You've only changed the protocol of the trust configuration between your SAP Business Technology Platform subaccount and SAP Cloud Identity Services.
Copy the following configurations from the old SAML-based SAP Cloud Identity Services application to your new OIDC-based SAP Cloud Identity Services application:
- Subject name identifier
See Configure the Subject Name Identifier Sent to the Application in the documentation of SAP Cloud Identity Services.
- Attributes
Change the names of the following attributes as listed in the following table.
| From User Attribute   | To User Attribute   |
|-----------------------|---------------------|
| first_name            | given_name          |
| last_name             | family_name         |
| mail                  | email               |
See Configuring User Attributes from the Identity Directory.
## Related Information
Configuration of SAP Cloud Identity Services After Migration from SAML to OIDC [page 2295] Test the Trust Configuration After the Migration [page 2298]
## 6.1.1.8.1.1.2.5  Restore SAML Trust Configuration
You replaced a SAML trust configuration to your custom identity provider with an OpenID Connect (OIDC) trust configuration to SAP Cloud Identity Services, and the authentication of application users in the subaccount isn't working as you expected. Restore your SAML configuration to get your applications working again.
## Prerequisites
You previously migrated your trust configuration from SAML to OIDC.
For more information, see Migrate from SAML Trust Configuration to OpenID Connect Trust with SAP Cloud Identity Services [page 2293].
## Procedure
1. Find the inactive SAML trust configuration with the oidc-migration-backup origin key. There's an active trust configuration with the same name and a different origin key. This trust is the one you can restore to a SAML trust configuration.
2. You can look up the origin key in the trust configuration in the SAP BTP cockpit, using the SAP BTP command-line interface (CLI), or the Identity Provider Management API.
Finding the Origin Key in the Cockpit
<!-- image -->
2. To restore the trust configuration from OIDC to SAML, use the SAP BTP command line interface (CLI).
For more information, see Managing Trust from SAP BTP to an SAP Cloud Identity Services Tenant [page 2442].
3. Log on to the btp CLI (see Log in [page 2416]).
4. Make sure that you set the target to the relevant SAP BTP subaccount.
5. Find the name of the (currently active) OIDC trust configuration that you want to restore to the SAML protocol.
<!-- image -->
##  Note
There's also an inactive trust configuration with the same name, but it has the oidc-migrationbackup origin key and the SAML protocol. It still has the data and assignments of the original SAML trust configuration.
6. Restore your trust configuration. Use the original key of the active OIDC trust configuration using the following command:
btp restore security/trust my-origin-key
The btp CLI returns that the restored trust configuration is active and that the protocol is SAML.
7. Check whether your trust configuration with the OpenID Connect protocol has been restored to SAML. Go to your subaccount in the SAP BTP cockpit and choose Security Trust Configuration . Y ou see only one SAML trust configuration - the restored one. The OIDC trust configuration has disappeared.
## Results
The original SAML trust configuration has been restored, with its original role collection assignments and origin key. The respective OIDC trust configuration no longer exists. In your SAP Cloud Identity Services tenant, the application for the OIDC trust configuration, SAP BTP subaccount &lt;subaccount\_display\_name&gt; has been deleted.
## 6.1.1.8.1.1.3  Manually Establish Trust and Federation Between SAP Authorization and Trust Management Service and SAP Cloud Identity Services
Use your SAP Cloud Identity Services tenant as an identity provider or a proxy to your own identity provider hosting your business users. Exchange SAML metadata to establish trust with the SAP Cloud Identity Services tenant and then register your subaccount with the tenant. To complete federation, maintain the federation attributes of the user groups.
## Context
<!-- image -->
##  Note
Instead of manually exchanging SAML metadata, we recommend that you use the automatic method based on the OpenID Connect (OIDC) protocol.
For more information, see Establish Trust and Federation Between SAP Authorization and Trust Management Service and SAP Cloud Identity Services [page 2282].
## 6.1.1.8.1.1.4  Establish Trust and Federation with UAA Using Any SAML Identity Provider
Integrate trust between the SAP BTP subaccount and any SAML 2.0 identity provider.
## Context
<!-- image -->
To establish trust, configure the trust configuration of the SAML 2.0 identity provider in your subaccount using the SAP BTP cockpit. Next, register your subaccount in User Account and Authentication service using the administration console of your SAML 2.0 identity provider. To complete federation, maintain the federation attributes of the SAML 2.0 user groups. This makes sure that you can assign authorizations to user groups.
## 6.1.1.8.1.1.4.1  Establish Trust with Any SAML 2.0 Identity Provider in a Subaccount
You want to use an SAML 2.0 identity provider. This is where the business users for SAP BTP are stored.
## Prerequisites
- You have subaccount administrator permissions.
- You have downloaded the SAML 2.0 metadata file from your SAML 2.0 identity provider using the relevant URL. For more information, see the documentation of your identity provider.
## Context
You want to establish a trust relationship with an SAML 2.0 identity provider in your subaccount in SAP BTP. The following procedure guides you through the trust configuration.
## Procedure
1. Go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Trust Configuration in the SAP BTP cockpit.
2. Choose New SAML Trust Configuration .
3. Enter a name and a description that make it clear that the trust configuration refers to your identity provider.
##  Note
Make sure that the users who are supposed to log on to this identity provider understand the name of the trust configuration.
4. To get the relevant metadata, get to the metadata of your identity provider.
5. Copy the SAML 2.0 metadata and paste it into the Metadata field.
6. To validate the metadata, choose Parse . T ake care that the Subject and Issuer fields are filled with the relevant data from your SAML 2.0 identity provider.
The name of the new trust configuration now shows the value of your identity provider. It represents your custom identity provider.
Check whether the fields for the single sign-on URLs and the single logout URLs are filled.
7. Save your changes.
8. To get the SAML metadata of your subaccount, choose the Download SAML Metadata button.
You download an XML file with the SAML metadata of your subaccount. Its name is saml-&lt;subdomain&gt;sp.xml . Use this file to import the SAML metadata into your identity provider.
## 6.1.1.8.1.1.5.1  Provide Logon Link to Identity Provider for Business Users
You want to provide an understandable link on the logon page and guide business to the right identity provider.
You want to make life easy for business users and provide a logon link that they can easily recognize as such. This link provides an identity provider logon that enables them to log on to the application that they want to
work with. To make it even easier, you can hide the logon of the default trust configuration ( SAP ID service ) for platform users, although it remains active. That way, your business users know at once which link to use for their logon.
We strongly recommend to use the following procedure:
1. Hide the default identity provider ( SAP ID service ) from the logon page. Hide Logon Link for Default Identity Provider [page 2313]
2.
Display the custom identity provider at logon time.
Display Logon Link for Custom Identity Provider for Business Users [page 2314]
3. (Optional) Give the logon link of the custom identity provider a name the business users understand. Rename the Logon Link Text for Custom Identity Providers [page 2315]
## 6.1.1.8.1.1.5.2  Hide Logon Link for Default Identity Provider
You use one or multiple custom identity providers for business users as well as the default identity provider primarily for platform users. To provide a good logon experience for your business users, you want to hide the default identity provider, which remains active.
## Prerequisites
- You have configured a custom trust configuration for a custom identity provider, for example SAP Cloud Identity Services, and set it to active.
- You've checked the Available for User Logon checkbox in your custom trust configuration.
- The default trust configuration ( SAP ID service ) is active.
## Context
To hide the default identity provider at logon time, proceed as follows:
## Procedure
1. Go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Trust Configuration in the SAP BTP cockpit.
You see the list of trust configurations: the default trust configuration and the custom trust configuration(s).
2. Choose  (Edit) for the default trust configuration. It has the status Default .
3. To hide the default trust configuration ( SAP ID service ) for logon, uncheck the Available for User Logon checkbox.
4. Save your changes.
The default trust configuration is now hidden but remains active.
## 6.1.1.8.1.1.5.3  Display Logon Link for Custom Identity Provider for Business Users
You want to display a logon link of the custom identity provider that business users should use to log on to an application.
## Context
## Procedure
1. Go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Trust Configuration in the SAP BTP cockpit.
You see the list of trust configurations: the default trust configuration and the custom trust configuration(s).
2. Go to the desired trust configuration with the status Custom .
3. Choose  (Edit) for the custom trust configuration.
4. Make sure that the status of your custom trust configuration is Active .
5. Check the Available for User Logon checkbox.
6. Save your changes.
## Results
Whenever business users want to log on to their application, they see a logon link for the custom identity provider that they should use.
## 6.1.1.8.1.1.5.4  Rename the Logon Link Text for Custom Identity Providers
You can provide a logon link and give the link a name the business users understand. That way, they know which link they should use to log on.
## Prerequisites
- You have already made your custom identity provider available for user logon (see the related link).
## Context
You want to define an understandable name for the logon link of the custom identity provider that the business users should use.
## Procedure
1. Go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Trust Configuration in the SAP BTP cockpit.
You see the list of trust configurations: the default trust configuration and the custom trust configuration(s).
2. Choose the link of your custom identity provider. It has the Custom status.
3. Choose Edit .
4. Go to Link Text for User Logon and give the logon link an understandable name.
5. Save your changes.
## Results
Whenever business users want to log on to their application, they see the logon link of the custom identity provider that they should use. It has the caption you entered in Link Text for User Logon .
## Related Information
Display Logon Link for Custom Identity Provider for Business Users [page 2314]
## 6.1.1.8.1.2  Platform Users
User accounts enable users to log on to SAP BTP, access subaccounts, and to use applications according to the permissions granted to them. In this context, it's important to understand the difference between the two types of users that we refer to: Platform users and business users.
Platform users are usually developers, administrators or operators who deploy, administer, and troubleshoot accounts, applications and services on SAP BTP.
Platform users who were added as members and have administrative permissions can view or manage the list of global accounts, directories, subaccounts, and Cloud Foundry orgs and spaces that are available to them. Members access them using the SAP BTP Cockpit, the SAP BTP command-line interface (btp CLI), or the Cloud Foundry command-line interface (CF CLI).
##  Note
The content in this section is not relevant for China (Shanghai) and Government Cloud (US) regions.
For platform users, there's a default identity provider [page 2335]. We expect that you have your own user base. We recommend that you configure SAP Cloud Identity Services as the custom identity provider and connect SAP Cloud Identity Services to your own corporate identity provider.
## Related Information
Business Users [page 2281]
Establish Trust and Federation of Custom Identity Providers for Platform Users [page 2316]
Supported Tools and Services When Using Custom Identity Providers for Platform Users [page 2326]
Log On with a Custom Identity Provider to the Cloud Foundry Environment Using the Cloud Foundry Command-Line Interface [page 2328]
Log on with a Browser to the Cloud Foundry CLI and Service Dashboards [page 2333]
## 6.1.1.8.1.2.3  Log On with a Custom Identity Provider to the Cloud Foundry Environment Using the Cloud Foundry Command-Line Interface
Learn how to use different methods to log on to Cloud Foundry using a custom identity provider (IdP).
## Prerequisites
- You've created at least one subaccount and enabled the Cloud Foundry environment in this subaccount. For more information, see Create a Subaccount [page 2249].
- You've downloaded and installed the Cloud Foundry command-line interface (cf CLI). For more information, see Download and Install the Cloud Foundry Command Line Interface [page 2533].
- Your administrator has configured your Cloud Foundry environment to use a custom identity provider. For more information, see Establish Trust and Federation of Custom Identity Providers for Platform Users [page 2316].
- You've configured the login screen to display your custom identity provider, see Log on with a Browser to the Cloud Foundry CLI and Service Dashboards [page 2333] (relevant for the manual login process).
## Context
The cf CLI provides different options to log on using a custom identity provider. One scenario is recommended for an interactive logon because you must switch from the CLI to the browser to log on. This scenario supports multifactor authentication and other passwordless authentication methods, as well as single sign-on. The other scenario focuses on automation scenarios where switching between the CLI and a browser isn't possible.
## Procedure
Decide which scenario applies to you according to this table.
<!-- image -->
| Scenario                                                                                                                                                            | See                                                                    |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------|
| You can open a browser during the logon process.                                                                                                                    | Log On Manually With a Custom Identity Provider [page 2330].           |
| The logon process is automated, for example with a script or there's no possibility to open a browser during logon.                                                 | Log On as a Technical User With a Custom Identity Provider [page 2331] |
|  Restriction This scenario is only supported if the users exist di- rectly in your tenant of SAP Cloud Identity Services and not in a corporate identity provider. |                                                                        |
## Related Information
Log on with a Browser to the Cloud Foundry CLI and Service Dashboards [page 2333]
## 6.1.1.8.1.2.3.1  Log On Manually With a Custom Identity Provider
To log on to Cloud Foundry, using a custom identity provider, use the single sign-on option of the CF CLI.
## Prerequisites
- You've configured the login screen to display your custom identity provider. For more information, see Log on with a Browser to the Cloud Foundry CLI and Service Dashboards [page
2333].
- You know the origin key of the identity provider.
- For more information, see Establish Trust and Federation of Custom Identity Providers for Platform Users [page 2316].
## Context
During logon, the system provides you with a URL to your custom identity provider for you to enter in a web browser. If you're already logged on to your custom identity provider, the system provides a temporary authentication code to complete your logon. If you don't have an active session with your custom identity provider, you need to log on to receive the temporary authentication code.
## Procedure
1. Open a command line.
2. Set the target API endpoint to endpoint of your subaccount.
cf api https://api.cf.&lt;region&gt;.hana.ondemand.com
##  Sample Code
cf api https://api.cf.eu10.hana.ondemand.com
3. Log on to the Cloud Foundry environment with single sign-on:
```
cf login --sso
```
The command-line interface displays a login URL and prompts you to enter a temporary authentication code.
4. Open the URL that is provided on the screen to go to the logon screen. If this is the first time you're logging on or your browser cache has been cleaned of cookies, you're
prompted to provide the origin key of your custom identity provider or choose the default identity provider.
Otherwise, the sign-in page lists your accounts on custom identity providers with which you previously logged on.
5. Choose the account of your identity provider.
If you don't have an active session yet, you're prompted to log on to your identity provider.
After you've successfully logged on, you receive a temporary authentication code.
6. Enter the passcode.
You've logged on successfully. You can now choose your org.
## Related Information
Log on with a Browser to the Cloud Foundry CLI and Service Dashboards [page 2333]
## 6.1.1.8.1.2.3.2  Log On as a Technical User With a Custom Identity Provider
To log on to Cloud Foundry, using a custom identity provider, use the --origin option of the Cloud Foundry command-line interface (cf CLI).
## Prerequisites
## The users exist:
- Directly in your tenant of the SAP Cloud Identity Services.
- In a corporate identity provider with SAP Cloud Identity Services working as a proxy.
- Trust to your SAP Cloud Identity Services tenant must be configured with OIDC and not SAML.
- Your corporate identity provider must support the password grant flow.
For more information, see Configure Trust with OpenID Connect Corporate Identity Provider in the documentation for SAP Cloud Identity Services.
## Context
We recommend this method of logging on if you want to use an automated script and can't open a browser during the logon process.
## Procedure
Set up a script with the following code:
```
cf api https://api.cf.<region>.hana.ondemand.com cf login --origin <origin> -u <user> -p <password>
```
## 
```
Sample Code cf api https://api.cf.eu10.hana.ondemand.com cf login --origin sap.ids -u julie.armstrong@sap.com -p mysecurepassword
```
- Find the &lt;region&gt; value, that applies to you in the section Regions [page 17].
- Find the &lt;origin&gt; value for the user that you want to use in the cockpit.
1. Navigate to the subaccount of your user.
2. Choose Cloud Foundry Org Members .
3. Find the &lt;origin&gt; value of your user in the table.
## 6.1.1.8.1.2.4  Log On with a Custom Identity Provider to the SAP BTP Cockpit
All users can log on to the SAP BTP cockpit with a custom identity provider.
## Prerequisites
- Your user has administration or viewer 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].
- You have established trust with a custom identity provider for platform users. For more information, see Establish Trust and Federation of Custom Identity Providers for Platform Users [page 2316].
## Context
Use the Open link in the SAP BTP Cockpit column. It contains a URL for the user to log on with the custom identity provider.
<!-- image -->
##  Example https:/ / emea.cockpit.btp.cloud.sap/cockpit/?idp=mytenant.accounts.ondemand.com
## Procedure
1. Go to your global account or subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Trust Configuration in the SAP BTP cockpit.
2. Use the Open link in the SAP BTP Cockpit column.
- To enable other platform users to log on with a custom identity provider, send the link to these users.
- To work with your user accounts from multiple identity providers at the same time, open the link in a private or incognito browser window or tab.
<!-- image -->
##  Note
A browser that isn't in private or incognito mode has one single session with the cockpit. If you have an existing cockpit session with one identity provider and log on with another one, the existing session closes and creates a new session. For this reason, you can't have parallel sessions with different identity providers.
3. Log on using the custom identity provider.
## 6.1.1.8.1.2.5  Log on with a Browser to the Cloud Foundry CLI and Service Dashboards
Platform users of the Cloud Foundry environment have the option to log on with a custom identity provider or the default identity provider.
## Prerequisites
- You know the origin key of the identity provider. For more information, see Establish Trust and Federation of Custom Identity Providers for Platform Users [page 2316].
- You don't already have a session with the Cloud Foundry environment. If you're already authenticated, you skip the logon process and go straight to your application.
## Context
When accessing a web application, like a service dashboard (for example logs.cf.eu10.hana.ondemand.com ) or you log into your Cloud Foundry account using the CLI with cf login -sso , you're prompted by a login screen. This method enables you to log on to a custom identity provider or makes it easier to log on when multifactor authentication is required.
## Procedure
1. Navigate to the URL for your service dashboard or provided by the CF CLI.
The login screen appears.
If this is the first time you're logging on or your browser cache has been cleaned of cookies, you're prompted to provide the origin key of your custom identity provider or choose the default identity provider.
## SAP Business Technology Platform
Choose your identity provider
## Sign in with default identity provider
Enter the origin of your identity provider key .
Sign in with alternative identity provider
Logon Page Without Cookies
Otherwise, the sign-in page lists your accounts on custom identity providers with which you previously logged on.
Logon Page With Previous Logon
<!-- image -->
2. Choose your identity provider and log on.
## Related Information
Log On with a Custom Identity Provider to the Cloud Foundry Environment Using the Cloud Foundry Command-Line Interface [page 2328]
## 6.1.1.8.1.3.1  Create SAP User Accounts
To grant authorizations to people from the default identity provider in your subaccount, ensure that they have a user account.
## Context
If the person in question already has a user account on sap.com Web sites, then that person already has a user in the default identity provider. Add this user to your accounts, if you know this person's e-mail address.
##  Recommendation
We strongly recommend that you configure your custom tenant of SAP Cloud Identity Services as the identity provider and connect SAP Cloud Identity Services to your own corporate identity provider.
For more information, see Trust and Federation with Identity Providers [page 2280].
##  Note
For technical users, create the user in your custom identity provider. In your custom identity provider, you control the access policies of these users independently from the policies we set for the default identity provider. Our default identity provider is meant for human users, who interact with SAP and our solutions.
## Procedure
Send your colleagues the self-registration URL.
https://account.sap.com/core/create/register? redirectURL=https%3A%2F%2Femea.cockpit.btp.cloud.sap%2Fcockpit%2F
The Web site registers you with SAP Universal ID, which also registers you with the SAP ID service. If you already have a user in the SAP ID service, associate this user with your new SAP Universal ID account. SAP Universal ID manages the users of official SAP sites, including the SAP developer and partner community.
##  Tip
After your colleagues sign up, add them to a subaccount. Assign role collections to them. Then your colleagues can log on to the SAP BTP cockpit.
## Related Information
Add Users from SAP ID Service for Multi-Environment Subaccounts [page 2340] Default Identity Provider [page 2335]
## 6.1.1.8.1.3.2  Add Users from SAP ID Service for MultiEnvironment Subaccounts
Before you can assign role collection to a user from SAP ID service, ensure that this user exists in your subaccount.
## Prerequisites
The user you want to add to your subaccount must have an SAP user account (for example, an S-user or P-user).
For more information, see Create SAP User Accounts [page 2339].
## Context
When you create your own trial account, your SAP user is automatically created and assigned to SAP ID service. When you onboard new members to your subscribed app, add them to your subaccount. Then you can assign a role collection to the user.
## Procedure
Create users and assign role collections to users in Security Users .
It's possible to create users in custom identity providers and in the SAP ID service.
For more information, see Working with Users [page 2342].
## Related Information
Platform Identity Provider for Tools
Mapping Role Collections [page 2358]
## 6.1.1.8.1.4  Switch Off Automatic Creation of Shadow Users
To switch off the creation of shadow users in the trust configuration of custom identity providers, administrators must explicitly allow users to log on. Administrators then have full control over who is allowed to log on.
## Context
Whenever a user authenticates at an application in your subaccount using any identity provider, the User Account and Authentication service always stores user-related data provided by the identity provider in the form of shadow users. The UAA uses details of the shadow users to issue tokens that refer to a certain user.
By default, the UAA allows any user of any connected identity provider to authenticate to applications in the subaccount. When there's no corresponding shadow user, it automatically creates one based on the information received from the identity provider.
##  Note
With new subaccounts created after 24 September 2020, automatic creation of shadow users is switched off by default for the default identity provider, SAP ID service.
Usually, you want your administrators to be fully aware of which users they allow to log on. If you've switched off automatic creation of shadow users for a certain identity provider, you enforce that only those users can log on where shadow users have been created explicitly. You can create them in the SAP BTP cockpit, typically when you assign the first role collection to them. For more information, see Create Users [page 2347].
To switch off creation of shadow users during logon, proceed as follows:
## Procedure
1. In the SAP BTP cockpit, go to your subaccount (see Navigate in the Cockpit [page 2207]) and choose Security Trust Configuration .
2. Choose your custom trust configuration.
3. Choose Edit .
4. Go to Create Shadow Users During Logon and remove the checkmark.
5. Save your changes.
From now on, the User Account and Authentication service doesn't automatically create shadow users for a certain identity provider during logon.
## Related Information
Deletion [page 3278]
## 6.1.1.8.2.1  Find Users and Their Role Collection Assignments
You want to find the authorizations granted to specific users in your global account and subaccount. You can search or sort the list of users, and view their role collection assignments.
## Context
You want to find out which authorizations have been granted to single or multiple users. To do so, access the list of all users, find the users you want to review, and check the role collection assignment. From the user's role collection, you can drill down to the roles of the role collection.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and/or subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Users .
You see all the users of your subaccount.
 Tip
If you want to see users that were updated before a certain point of time, use the Last Updated field. You can filter the list according to the point of time of the last update.
4. To search for users, choose  (Search).
5. Enter a string occurring in the user name, last name, first name, or e-mail address. The SAP BTP cockpit returns a list of all the users containing this string.
6. Select a user and open the overview section.
You can see all of the role collection assignments of this user. You can also drill down into the roles.
## 6.1.1.8.2.2  Find Inactive Users
As an administrator, you want to have an overview of the users in your subaccount, no matter which identity provider stores them. You want to clean them up if necessary.
## Context
- You want to find users that haven't been used for some time. The reason could be that employees left the company, but the users still exist in the system.
- You want to find users who never logged on. For example, they could be manually created shadow users with a typo in their e-mail address, so they didn't match the user ID provided by the identity provider. They were never used, and it might make sense to delete them.
## Procedure
1. Open the SAP BTP cockpit.
2. Go to your global account and/or subaccount (see Navigate in the Cockpit [page 2207]).
3. Choose Security Users .
You see all the users in your subaccount.
4. If you want to see users that were updated at a certain point in time, use the Last Updated field. Y ou can filter the list according to the following filter criteria:
- All
- Today
- This week
- This month
- This year
If you want to see the users who haven't logged on at a certain point in time, use the Hasn't Logged On field. You can filter the list according to the following filter criteria:
- All
- Last 7 Days
- Last 30 Days
- Last 180 Days
- Last 365 Days
- Choose a Date
The SAP BTP cockpit displays the filtered list of users. The Last Updated column shows you the point in time when the user was updated last. The Last Logon column shows you the point of time of the user's last logon.
5. (Optional) To see whether a user has never logged on, choose the user to display the user's overview section.
The SAP BTP cockpit displays the user's overview section. If the user has never logged on, the Last Logon field shows the message User has never logged on .
6. (Optional) To delete the user, close the overview section and choose  (Delete).
##  Remember
You can't undo the deletion of a user.