Configuring Trust and Corporate IdP Federation with Identity Authentication

Explanation

Once a project has decided to use a dedicated Identity Authentication tenant instead of the default SAP ID Service, two configuration layers must be established: trust between the BTP subaccount (and its consuming services, such as Integration Suite) and the IAS tenant, and federation between the IAS tenant and the corporate identity provider. The first layer, subaccount trust, is configured in the BTP cockpit under the subaccount's Trust Configuration (Security area). Here an administrator establishes a trust relationship pointing to the custom Identity Authentication tenant, typically by uploading or referencing SAML 2.0 metadata exchanged between the subaccount and the IAS tenant, or by registering the subaccount as an OIDC application within IAS. Once this trust is active and set as the default identity provider for the subaccount, users attempting to reach BTP cockpit, Integration Suite launchpad, or any subscribed application under that subaccount are redirected to the IAS tenant's login page rather than the SAP ID Service page. The second layer, corporate IdP federation, is configured inside the Identity Authentication administration console itself. Here an administrator defines a corporate identity provider as a trusted source, using either SAML 2.0 (uploading the corporate IdP's metadata, defining the assertion consumer service URL, and configuring attribute mappings such as email, first name, last name, and group membership) or OpenID Connect (registering IAS as a relying party against an OIDC-compliant provider such as Azure AD/Entra ID, including client ID, client secret or certificate, and discovery endpoint). Once configured, IAS can be set to either always redirect to the corporate IdP (proxy mode), or to present a choice of identity providers, or to fall back to IAS's own user store for accounts not present in the corporate directory. The runtime login flow works as follows: a user requests access to an Integration Suite URL under the subaccount; the subaccount trust configuration redirects the browser to the configured IAS tenant; IAS evaluates its own federation rules and, if configured for the corporate IdP, redirects again to that corporate IdP's login page; the user authenticates there (potentially with MFA); the corporate IdP issues a SAML assertion or OIDC token back to IAS; IAS validates it, applies any attribute mapping and conditional authentication policies (such as risk-based rules or IP range restrictions), and issues its own SAML assertion or OIDC token back to the BTP subaccount; the subaccount trust configuration validates this final assertion and establishes the authenticated session, after which authorization checks (role collections) take over. Verification after configuration should include testing with a real corporate user account end-to-end, confirming that user attributes (especially the email or user ID used for BTP role collection assignment) arrive correctly, and checking that group or role attribute mappings match what authorization design expects. A common verification technique is to use the IAS tenant's built-in test tool or browser developer tools to inspect the SAML assertion or ID token contents before troubleshooting authorization issues that are actually attribute-mapping issues in disguise. On troubleshooting: login failures at this stage typically stem from either metadata mismatches (expired certificates, wrong entity IDs, wrong ACS URLs) between the corporate IdP and IAS, or between IAS and the subaccount, or from attribute mapping problems where the identifier IAS forwards does not match the identifier expected by BTP role collections. Clock skew between systems can also cause SAML assertion validation failures. Because trust changes affect all users of a subaccount, teams should test configuration changes carefully, ideally in a non-production subaccount first, and keep a documented rollback path (such as reverting the default identity provider back to the previous trusted IdP) before changing production trust settings.

Code example

# Illustrative SAML metadata attribute mapping snippet configured in Identity Authentication# (conceptual representation, not a literal API payload) AttributeMapping:  source: "corporate_idp_saml_assertion"  mappings:    - source_attribute: "http://schemas.corp.com/claims/email"      target_attribute: "mail"    - source_attribute: "http://schemas.corp.com/claims/groups"      target_attribute: "groups"    - source_attribute: "http://schemas.corp.com/claims/givenname"      target_attribute: "firstName" # Subaccount trust configuration reference (BTP cockpit, Security > Trust Configuration)# - Identity Provider Type: Custom Identity Authentication tenant# - SAML metadata URL: https://<ias-tenant>.accounts.ondemand.com/saml2/metadata# - Default IdP for subaccount: true

Real project scenario

During a production cutover for an Integration Suite implementation, the security team federates the shared IAS tenant with the company's Azure AD via OIDC and switches the target subaccount's trust to that IAS tenant. Post go-live, several business users report they can authenticate but see no authorizations in the Integration Suite launchpad. Investigation using the IAS assertion inspection tool reveals Azure AD sends the user's email in a claim named differently than IAS's default mapping expects, so the attribute IAS forwards to BTP does not match the identifier used in role collection assignments, requiring a correction to the attribute mapping and a re-test before authorizations resolve correctly.

Common mistakes

• Changing a subaccount's default identity provider directly in production without testing in a non-production subaccount first. • Misconfiguring or forgetting to update attribute mappings when the corporate IdP's claim names do not match IAS defaults, causing authorization mismatches that look like access problems but are actually identity mapping problems. • Letting SAML signing certificates expire on either the corporate IdP or IAS side without a renewal process, causing sudden authentication outages. • Not accounting for corporate IdP conditional access or MFA policies interacting unexpectedly with the SAML/OIDC redirect chain, causing loops or unexpected prompts.

Best practices

• Always test subaccount trust and IdP federation changes in a non-production subaccount before applying to production. • Keep attribute mappings between the corporate IdP and IAS explicitly documented and reviewed whenever the corporate IdP claim schema changes. • Monitor SAML/OIDC certificate expiration dates proactively rather than reactively after an outage. • Use the IAS assertion/token inspection tooling to distinguish authentication issues from authorization/role-collection issues before escalating. • Maintain a documented rollback procedure for reverting a subaccount's default identity provider in case federation changes cause a production login outage.

Interview angle

Candidates are often asked to trace the full authentication redirect flow from a user hitting a BTP application URL through to an authenticated session, and to explain where in that flow an attribute mapping problem would surface versus where a pure trust/certificate problem would surface. Being able to separate authentication failures from downstream authorization failures caused by attribute mapping is a strong signal of hands-on troubleshooting experience.