Lesson 1 of 5
Trust and identity providers
9 min
Listen to this lesson
Before anyone can use the fleet order status app, the subaccount must know who they are. SAP BTP does not keep its own passwords for business users; it trusts identity providers to authenticate people and then works with the identity and attributes the provider asserts. This lesson covers the trust setup Contoso uses in cmc-ext-dev, cmc-ext-test and cmc-ext-prod, and why each subaccount needs it.
Default and custom identity providers
Every subaccount starts with trust to SAP ID service, the default identity provider for both platform users (administrators and developers in the cockpit) and business users (people using applications). It works without configuration and is fine for starter scenarios and early tests. SAP's documentation strongly recommends configuring your own tenant of SAP Cloud Identity Services as the identity provider instead, and connecting that tenant to your corporate identity provider. One reason is control: with SAP ID service, users can turn on multifactor authentication themselves, but there is no way to enforce it; with your own tenant you can enforce it.
- User opens the appMaria opens the fleet app tile in SAP Build Work Zone
- Redirect to identity providerThe subaccount sends her to its trusted SAP Cloud Identity Services tenant
- DelegationThe tenant forwards authentication to Contoso's corporate identity provider, where she signs in with single sign-on and MFA
- Assertion backThe tenant returns her identity and attributes, including her groups, to the subaccount
- Token issuedSAP BTP issues a token for the app containing her authorizations, derived from role collections
Establishing trust
In the SAP BTP cockpit, a subaccount administrator opens Security > Trust Configuration and chooses Establish Trust. The wizard lists the SAP Cloud Identity Services tenants associated with the customer ID of the global account; the trust uses OpenID Connect, so no SAML metadata has to be exchanged by hand. The administrator confirms the name and origin key (the key that identifies users from this provider), chooses the domain, and decides three switches: Available for User Logon (show it on the logon page), Create Shadow Users on User Logon (SAP recommends keeping this on if unsure; without a shadow user, logons fail) and Default for Noninteractive Logon (for command line tools). On the identity service side, an application named after the subaccount is created automatically.
- Only one SAP Cloud Identity Services tenant can be trusted per subaccount with this OIDC method.
- If the tenant's issuer changes, the trust breaks; the Refresh button on the trust configuration updates it.
- Once the custom identity provider works, the default SAP ID service can be set inactive or its logon link hidden for business users.
- Platform users can also be federated through a custom identity provider; that is a separate configuration with its own restrictions.
Contoso's setup
| User group | Where they authenticate | Attributes passed to SAP BTP |
|---|---|---|
| Fleet desk employees | Corporate identity provider, via SAP Cloud Identity Services | Email, name, groups such as BTP_FLEET_AGENTS |
| Fleet supervisors | Corporate identity provider, via SAP Cloud Identity Services | Email, name, group BTP_FLEET_SUPERVISORS |
| Great Lakes Fleet Services contacts | User store of SAP Cloud Identity Services (no corporate account) | Email, name, group BTP_FLEET_CUSTOMERS, attribute customer with their business partner number |
| Platform administrators | Corporate identity provider for platform users | Email, name; cockpit access through administrator role collections |
Identity sources for the fleet app. Group names are Contoso's own conventions.
What would you do?
Weeks before go-live, the fleet app in cmc-ext-prod still trusts only SAP ID service, and supervisors sign in with personal SAP accounts. Grace asks whether that can stay for the first months. What should the security lead answer?
- Subaccounts trust identity providers; SAP ID service is the default and suits starter scenarios.
- SAP recommends your own SAP Cloud Identity Services tenant, connected to the corporate identity provider.
- Establish trust under Security > Trust Configuration using OIDC; keep shadow user creation on if unsure.
- One tenant per subaccount with this method; refresh trust if the issuer changes.
- Hide or deactivate the default provider for business users once the custom setup works.
Check your understanding · not graded
Lesson check
1. Which identity provider does a new subaccount trust by default?
2. Why can't Contoso rely on SAP ID service for MFA?
3. What happens at logon if shadow user creation is off and no shadow user exists?
4. Which protocol does the cockpit's Establish Trust wizard use with SAP Cloud Identity Services?