Skip to Content
Product Information
Author's profile photo Juergen Adolf

Custom platform IdP support for feature set B released!

It has been a long journey. A highly-requested and long awaited feature has been released on the 25th of July 2022. You can now use your custom SAP Identity Authentication service tenant to log in to your BTP management tools. That includes the BTP cockpit (including Neo), BTP CLI, and the different clients for the Cloud Foundry Environment. In the past that was only possible in feature set A with a rather complicated setup. In feature set B, however,  the setup process is as easy as the trust setup for an application identity provider in a subaccount, and you do this centrally for a whole global account. The magic happens behind the scenes. Now all customers on feature set B can manage their BTP accounts in a fully compliant way, and integrated into their corporate IAM processes. For instance, think about enforcement of multi-factor authentication, full control over password policies and user lifecycle as well as the usage of technical users for automation.

More information can found in the release note.

A detailed procedure description on how to use a custom identity provider for the platform users of SAP BTP is already available on SAP Help Portal: Establish Trust and Federation of Custom Identity Providers for Platform Users [Feature Set B].


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Diego Ismael Ibarra
      Diego Ismael Ibarra

      Hello Juergen,

      So glad to hear about this feature is now released.

      We've just setup the trust relationship  according to the document. The procedure is in fact very straightforward.

      However, when we try to login to our cockpit we see that we go though our Custom IDP MFA process correctly but we are not able to get to the cockpit main screen. Instead of getting to the cockpit screen we receive the error:

      HTTP STATUS 500 - Internal server Error.


      Do we have some way to trace this error?


      Kind regards



      Author's profile photo Luca Falavigna
      Luca Falavigna

      Hi Diego,

      please check whether you have the attribute "mail" defined in your SAML2 payload. If not, you have to instruct your IDP to send it.

      For instance in Azure I needed to define "mail" to take value from user.mail:




      Here are listed all assertion attributes which Identity Authentication Service expects: Configure the User Attributes Sent to the Application


      Hope it helps,


      Author's profile photo Heiko Ettelbrueck
      Heiko Ettelbrueck

      Actually, the user attributes needed for custom platform IdPs with BTP cockpit are quite few ones, no need to check the generic IAS documentation linked above. What you need are:

      • mail
      • first_name
      • last_name

      (Specific documentation for this will follow.)

      These are the attribute names expected by BTP. Where you define them depends on your IAS configuration: If it's working as proxy, without the internal user store being enabled (see screenshot below)

      you need to either define these names in the corporate IdP itself, or in IAS using "Enriched Assertion Atributes" (see next screenshot, sample with Azure AD connected using OpenID Connect):

      Author's profile photo Tyrone Scamaton
      Tyrone Scamaton

      Hi Heiko,

      Do you know how this configuration should look for Okta, where we are using SAML 2.0?  I have tried a similar config, but I do not see the "mail" attribute in the SAML Assertion, I still only see "email", which I expect BTP will not understand?



      Author's profile photo Heiko Ettelbrueck
      Heiko Ettelbrueck

      Hi Tyrone,

      when the SAML assertion sent by Okta contains attribute "email", then the "Value" from the screenshot should fit to your case.

      To make it easier to analyze the integration, try to log in to e.g. BTP cockpit using your custom IAS tenant, then use the "Troubleshooting Logs" in IAS to check which information IAS actually sent to BTP cockpit. You can use filter term "openIdConnect" to reduce the amount of logs you find. Log details will show the complete payload of the OpenID Connect token sent to BTP cockpit, so you also see whether and which email address it includes. (As you mentioned, BTP cockpit only looks for "mail" and would ignore e.g. "email".)

      Example log message:

      state="successful", action="issueJwtToken", objectType="openIdClient", objectId="35a65403-3f3d-466b-a8e3-d37731b47a32", category="audit.authentication", jwtPayload="{"ias_iss":"https:\/\/","sub":"P000000","uid":"P000000","aud":"35a65403-3f3d-466b-a8e3-d37731b47a32","scim_id":"747841f9-5a0e-47f0-8c2f-5523b11dfead","mail":"","last_name":"Ettelbrück","cnf":{"x5t#S256":"Lp9Xj03BHNX4OQbsZW4xfbLhVaU2qUG11Y1hGACzHoQ"},"first_name":"Heiko","sid":"S-SP-5280d941-2cd9-4518-a7fc-450f3be73ee5"}", workflow="openIdConnect", userIdentifier="P000000", grant_type="authorization_code", serviceProvider="btp-platform"

      If you still have trouble figuring out why it doesn't work for you, I suggest you open a support ticket on BC-CP-CF-SEC-IAM.

      Kind regards


      Author's profile photo Carsten Olt
      Carsten Olt

      Hi all,

      great stuff, works fine for Cockpit and CLI.

      But what about the many Neo accounts that already exist, is there a way to have the user base selection when adding members?

      From SAP Help:

      For subaccounts in the Neo environment, the identity provider will be offered in the value help only if a user in that identity provider has created at least one Neo subaccount in the corresponding global account and Neo region

      That seems to be true. Custom IDP works fine for newly created Neo subaccounts but not for existing ones. Here you get the message: Target could not be found. The issues is most likely due to inconsistent IDP tenant settings.

      Has anyone already made experience here?

      Thanks & Cheers



      Author's profile photo Binson Varikkasseril Abraham
      Binson Varikkasseril Abraham

      Hi Carsten,

      Have you tried to create a new "dummy" NEO subaccount with the user from the new IdP in the same NEO region, and then check whether the new IdP name is listed for the existing NEO subaccounts also?



      Author's profile photo Carsten Olt
      Carsten Olt

      Dear Binson,

      now its working... that did the trick, great.

      Thanks a lot 🙂

      Cheers Carsten

      Author's profile photo Middleware PI SDT
      Middleware PI SDT


      I still see this custom IdP support for platform users in feature set B as a limitation in the below SAP note.

      3027721 - FAQ: SAP BTP Global Account Upgrade from Feature Set A to Feature Set B



      Author's profile photo Heiko Ettelbrueck
      Heiko Ettelbrueck

      Hi Senthil,

      although I realized your comment a little late: In the meanwhile, the note you refer to has been updated, since feature set B upgrades with custom IdP for platform users are now possible, too (with a few restrictions, but sufficient for most customers).

      Check to learn more, esp. how the upgrade process looks like. Looking forward to upgrading your account 🙂

      Kind regards