Identity and Access Management with Microsoft Entra, Part I: Managing access to SAP BTP

[MartinRaepple]

SAP and Microsoft have announced their collaboration to modernize identity and access management (IAM) for SAP customers. SAP recommends its SAP Identity Management (IDM) customers transition to Microsoft Entra (formerly known as Microsoft Azure Active Directory) as the SAP IDM solution approaches the end of maintenance by 2027, with extended maintenance until 2030. This blog post series aims to provide technical guidance on how to plan and implement IAM for SAP applications with Microsoft Entra following SAP's reference architecture for Cloud-leading identity lifecycle. Part I (this blog post) looks at a Cloud-only scenario applying a federated approach for cross-domain identity and access management. Part II covers a hybrid setup for user provisioning across on-premise and the Cloud. Stay tuned for new scenarios as part of this series.

Scenario overview

This blog post series focuses on key scenarios, starting with the implementation of a workflow-based access management solution to SAP Business Technology Platform (BTP) with Microsoft Entra ID Governance.

📢 📢 📢  Note

In session XP202, Identity lifecycle management with SAP BTP and Microsoft Entra, at SAP TechEd 2024, @RegineSchimmer and I talk about our collaboration between SAP and Microsoft and show a live demo of the scenario from this blog post. Also check out the recording (in German language only) of my online session from December 5th 2024 with the Deutschsprachige SAP Anwendergruppe e.V. (DSAG), AG Identity Access Management, on a deep-dive and live demo for this scenario.

Figure 1 illustrates the scenario in more detail:

Figure 1: Access management to BTP with Entra ID Governance

The developer (John Doe) requires access to SAP Business Application Studio which serves as an example for an SAP BTP application in this scenario. To work with SAP Business Application Studio, John's user must be a assigned to the Developer role in the BTP subaccount, which is part of the Business_Application_Studio_Developer role collection that gets automatically created with the subscription to SAP Business Application Studio. Granting the access must be approved by the Entra ID administrator (Jane Smith).

To implement this workflow for managing the access to BTP, the following entities in Entra are required:

• All users in the Entra tenant working with SAP Business Application Studio must be a member of the SAP BTP Developer Group. This is a group of type Security. 
• The SAP BTP Developer Group is assigned to the SAP BTP Access Package. Access Packages are a feature of Entitlement Management in Microsoft Entra ID Governance that allows administrators to bundle resources such as groups, applications, and SharePoint Online sites into a single package. This package can then be assigned to users based on policies that define who can request access, approval workflows, and lifecycle settings. In this scenario, John requests his membership in the SAP BTP Developer Group by starting a workflow for the SAP BTP Access Package that Jane as an Administrator for the package can approve.

If John's request gets approved by Jane and he becomes a member of the Entra ID security group SAP BTP Developer, how is this information securely transferred to SAP BTP? Microsoft Entra ID issues security tokens to successfully authenticated users, such as access tokens, refresh tokens, and ID tokens. Depending on the token type they contain different information, expressed as name-value pairs (also known as claims), that reliably provide facts about the user's identity. Claims can include details like the user's unique ID, email address, the user's department, job title, and other attributes related to the user's role within the organization. To securely transfer John's membership in the SAP BTP Developer group to BTP, Entra can be configured to include John's group memberships as a claim in the ID token. Since different applications usually require different sets of claims in the tokens, customization of the claims is done on an application registration for IAS (SAP Cloud Identity Services Application Registration in figure 1) in the Entra tenant.

When John opens the URL to SAP Business Application Studio in an browser, he first gets redirected to the trusted identity provider (IDP) in the BTP subaccount to authenticate. In BTP, this task is delegated to an Identity Authentication Service (IAS) tenant of the SAP Cloud Identity Services using the OpenID Connect (OIDC) protocol. Since the IAS tenant is not aware of John's memberships in Entra security groups, it forwards the application's OIDC authorization request to Entra ID by acting as an OIDC proxy. This requires to configure the Entra ID tenant as a Corporate IDP in IAS which causes John to sign-in to Entra instead of IAS. Upon successful authentication, Entra sends the OIDC authentication response back to IAS, containing an authorization code to request the ID and access tokens from Entra.

To identify the IAS tenant as a legitimate client when sending the OIDC token request, Entra requires IAS to authenticate. OIDC defines several authentication methods for clients, such as a client secret, which is a shared secret with a configurable expiration date (maximum 24 months) generated by Entra and shared with IAS. The drawback of using a client secret is that it is sent every time when IAS performs client authentication to obtain the tokens from Entra. When the secret is about to reach its expiration, the secret must be rotated in Entra ID and shared again with the administrator of the IAS tenant.

To reduce the administrative overhead and avoid sending a shared secret, OIDC also supports client authentication based on an asymmetric key pair. Here, the IAS tenant as the OIDC (proxy) client generates a JSON Web Token (JWT) according to RFC 7532 and uses its private key to sign it. The corresponding public key certificate is shared with the Entra tenant to establish the trust relationship. Similar to the claim configuration of the issued tokens, trust to the IAS JWT signing certificate is configured in the SAP Cloud Identity Services Application Registration. 

Now that the information about John's membership in the Entra security group SAP BTP Developer can be securely transferred to BTP when John authenticates with IAS on BTP, one question still remains opens: How is John assigned to the Developer role in BTP if he is a member of the SAP BTP Developer group in Entra? Let's have a look at John's OAuth JWT access token issued by Entra ID in the token response to the IAS token request: 

Figure 2: Entra ID Access Token

John's membership to the SAP BTP Developer group is emitted as a claim with the name groups that contains an array of GUIDs (globally unique identifiers). Each GUID is the value of the Security group's object identifier (OID) attribute in Microsoft Entra. In BTP, a role collection can be assigned to a user group by mapping the group(s) OID(s) to the role collection. This approach follows the recommendations for federated authorization management between Entra and IAS, and will be configured in the following steps.

Prerequisites

To follow the steps in this tutorial, make sure you have access to the following services:

• An IAS tenant with full administrative access. You can request an IAS trial instance as described here for your BTP trial account.
• An SAP BTP subaccount with Space Manager access. A free trial account will work for this scenario. The IAS tenant is already configured as a trusted identity provider for the applications in this subaccount.
• Administrator-level access to an Microsoft Entra ID P2 subscription. You can obtain a P2 tenant for development and learning purposes with a free Microsoft 365 E5 developer subscription. With this subscription you can request a trial of Microsoft Entra ID Governance by following these steps.
• Two test users in your Entra ID tenant, one for requesting the access to BTP, and the other for approving it.

Register SAP Cloud Identity Services application in Entra

Let's get started with creating the application registration for SAP Cloud Identity Services and configuring the token claims for it.

Step	Description	Screenshot
1	Login to the Entra admin center with your Entra administrator. Go to Identity -> Applications -> App Registrations. Click New registration.
2	Enter a name, e.g. "SAP Cloud Identity Services". Click Register.
3	Copy the Application (client) ID from the Overview to the clipboard and paste it into a text file for later use.
4	Click Endpoints.
5	Copy the OpenID Connect metadata document URL to the clipboard and paste it into a text file for later use. Close the dialog window.
6	Select Token configuration from the menu. Click Add groups claim.
7	Activate the Security groups checkbox. Click Add.

OIDC corporate IDP configuration in IAS

The data captured from the app registration in Entra is now required to configure the OIDC proxy settings for the corporate IDP in IAS.

Step	Description	Screenshot
8	Open a new tab in the browser and login to the Administration Console of your SAP CIS IAS tenant at  https://<ias-tenant-name>.accounts.ondemand.com/admin Go to Identity Providers -> Corporate Identity Providers.
9	Click Create.
10	Enter a Display Name, e.g. "BestRun Corp. Entra ID Tenant". Select OpenID Connect Compliant for the Identity Provider Type. Click Create.
11	For the newly created Corportate Identity Provider, select OpenID Connect Configuration from the Trust tab.
12	Paste the URL copied in step 5 into the Discovery URL field. Click Load.
13	From the Client Authentication Method drop-down list, select Private key JWT.
14	Paste the value of the Application (client) ID copied in step 3 into the Client ID field.
15	Scroll down to the Scopes section and click Add.
16	Enter offline_access for the new scope value. Click Save.
17	Scroll up and click Save. Then, click OIDC Callback URL to copy the value into the clipboard.
18	From the navigation menu, select Applications & Resources -> Tenant Settings
19	On the Authentication tab, go to your tenant's OpenID Connect Configuration.
20	Click the Download button of the default Signing Certificate. Note: If the download is not working, click on the Display icon. Copy the Certificate Information content into a text file and add the BEGIN/END-CERTIFICATE tags as follows: -----BEGIN CERTIFICATE----- MIIFSDCCBDCg........................................ -----END CERTIFICATE-----
21	From the navigation menu, select Applications & Resources -> Applications
22	Select your SAP BTP subaccount listed under Bundled Applications. Select Conditional Authentication from the SAP BTP subaccount's Trust settings.
23	From the Default Identity Provider drop-down list, select the corporate identity provider created earlier. Click Save.
24	Select Attributes from the SAP BTP subaccount's Trust settings.
25	Click Add.
26	In the Name field of the new attribute, enter "groups". Select "Corporate Identity Provider" as the Source. Enter "${corporateIdP.groups}" in the Value field. This additional attribute setting forwards the value of the groups claim in the Entra ID token to the BTP applications in the SAP BTP subaccount. Click Save.

Complete the Application Registration in Entra

To complete the OIDC proxy setup between Entra ID and IAS, the trust relationship must be established by uploading the IAS signing certificate to Entra and registering the IAS callback URL.

Step	Description	Screenshot
27	Go back to the Entra Admin center browser tab. Go to Manage -> Authentication.  Click Add Platform.
28	Select Web.
29	Paste the OIDC Callback URL copied in step 17 into the Redirect URIs field. Click Configure.
30	Go to Manage -> Certificates & Secrets. On the Certificates tab, click Upload certificate.
31	Open the file upload dialog and select the certificate file you downloaded in step 20. Click Add.
32	The IAS signing cerificate is now listed under the Certificates tab.

Validate the OIDC Proxy Setup

Now that the OIDC proxy setup is completed in Entra, you can validate the configuration in IAS.

Step	Description	Screenshot
33	Go back to the IAS Administration console browser tab. Navigate to Identity Providers -> Corporate Identity Providers in the menu.
34	Select your corporate identity provider from the list and select OpenID Connect Configuration. Click Validate.
35	Accept the requested permissions from the Entra SAP Cloud Identity Services app. You may also activate the checkbox to consent on behalf-of your organization.
36	You can now inspect the token sent by Entra to IAS and see for example the groups claim and its values for your user.

Create the user group in Entra

Continue the setup in the Entra Admin center by creating the group for SAP BTP Developers.

Step	Description	Screenshot
37	Go back to the Entra Admin center browser tab. Navigate to Identity -> Groups. Click New Group.
38	Select Security for the Group type. Enter a Group name, e.g. "SAP BTP Developer". Select Assigned from the Membership type drop-down list. Click Create.
39	Select the newly created group from the list.
40	Copy the Object ID to the clipboard and paste the value into a text file for later use.

Assign the group to the BTP role collection

Lorem ipsum

Step	Description	Screenshot
41	In a new browser tab, login to your BTP subaccount in the BTP Cloud Cockpit. For a trial account, use this link. Select your subaccount.
42	Navigate to Security -> Role collections. Select the Business_Application_Studio_Developer role collection from the list. Click Edit.
43	Under User Groups, select the IAS tenant as the identity provider, and paste the Object ID from the Entra ID group you copied in step 40.

Create the Access Package

Now it is time to configure the workflow for requesting and approving access to BTP by creating the access package in Entra ID Governance entitlement management.

Step	Description	Screenshot
44	Go back to the Entra Admin center browser tab. Navigate to Identity Governance -> Entitlement management -> Access Packages. Click New access package.
45	Enter a Name, e.g. "SAP BTP", and provide a short Description. You can leave the assignment of the new access package to the General catalog. Click Next: Resource roles.
46	Click Groups and Teams.
47	Activate the checkbox to see all Groups and Teams not in the General catalog. In the search field, enter the name of the group you created, e.g. "SAP BTP Developer" Activate the checkbox of the group from the search results list. Click Select.
48	Click Next: Requests.
49	Select For users in your directory and allow All members (excluding guests) therein to make a request for the access package.
50	Scroll down to the Approval section.  Choose Yes to Require approval. For the First Approver, select Choose specific approvers from the drop-down list. Click Add approvers.
51	Search for your user who will approve the access request and click Select.
52	Choose Yes to Enable new requests. Click Next: Requestor information.
53	Click Next: Lifecycle.
54	Click Next: Rules.
55	Click Next: Review + create.
56	Click Create.
57	Copy the link to MyAccess portal to the clipboard and paste it into a text file for later use.

Test access to BTP without the assignment

Now you are ready to test the scenario! Let's start with verifying that access is still denied for your test user.

Step	Description	Screenshot
58	Go back to the BTP Cloud Cockpit browser tab. Navigate to your subaccount's Services -> Instances and Subscriptions. Copy the URL to the SAP Business Application Studio to the clipboard.
59	Open a new private browser window. Paste the URL you copied in the previous step to your SAP Business Application Studio instance from the clipboard into the browser and hit Enter. You are redirected by the IAS tenant to Entra ID as the corporate IDP for your BTP subaccount's business applications. Login as the test user who will request access to SAP Business Application Studio.
60	You see a message that the user has no access yet due to the missing assignment to the Developer role.

Request the access package

Step	Description	Screenshot
61	Start the request workflow in a new tab of the private browser window by opening the URL to the MyAccess portal you copied in step 58. Click Continue.
62	Click Submit request.
63	You receive a confirmation message that your request to access the SAP BTP package is being processed. Close the private browser window.

Approve the request

Now you take over the role as the approver.

Step	Description	Screenshot
64	Re-open a private browser window. Start the approval workflow by opening the URL to the MyAccess portal you copied in step 57. Login as the user who you selected in step 51 for approving requests of the SAP BTP access package.
65	Naviate to Approvals in the MyAccess portal. Select your other test user's access request from the list of Pending approvals. Click Approve.
66	Click Submit.
67	You receive a confirmation message you approved the request. Close the private browser window.

Test access with the assignment

Now let's try again to open SAP Business Application Studio as the test user with the approved access request.

Step	Description	Screenshot
68	Re-open a private browser window. Go to the URL of the SAP Business Application Studio you copied in step 58. You are redirected by the IAS tenant to Entra ID as the corporate IDP for your BTP subaccount's business applications. Login as the test user who has requested access to SAP Business Application Studio.
69	This time the user can successfully load and use the SAP Business Application Studio.

With this last step you've successfully completed the scenario and I hope you enjoyed it!

[tskwin]

Hello @MartinRaepple,

Thank you for the guide. I tried setting it up, but I'm getting an Access Denied error when trying to access BAS. I think the attributes from Azure are not being accurately sent to SAP BTP.

Are my settings in IAS correct?

Here’s what I have:

• Application Settings:
• Subject Name Identifier: Corporate Identity Provider -> ${corporateIdP.mail}
• Default Name ID Format: Email
• Attributes: Corporate Identity Provider -> ${corporateIdP.mail}, ${corporateIdP.groups}, ${corporateIdP.givenName}
• Corporate Identity Provider Settings:
• Subject Name Identifier: Email
• Subject Name Identifier: Use Identity Authentication user store=OFF, Allow Identity Authentication users only=OFF

Also, Shadow User is enabled in SAP BTP.

In SAP BTP, the users appear like this

this-default-was-not-configured.invalid

Could you please advise me on what might be causing the issue?

Many Thanks

[Uppdeep_Mann]

Well detailed , Thanks for putting this together.

[MartinRaepple]

Hi @tskwin ,

I checked my settings im IAS and they are as follows:

Application Settings of the BTP subaccount:

• Subject name identifier: Identity Directory, Email
• Attributes: email, email_verified, family_name, given_name, user_uuid -> all sourced from Identity Directory, only groups comes from the corporate IDP as described in the blog

Corporate Identity Provider:

• Subject name identifier: None (sub claim is the identifier)

I created a fresh BTP trial account and IAS trial tenant for this tutorial and did not change any of the default settings for the subject name identifiers and attributes. Only the groups attribute is added as described.

You may also want to go this path, or change your settings accordingly. Let us know if it works.

Best regards

Martin

[MarissL1]

Thank you for your post I do believe this is open for discussion regarding specific use cases.  I look forward to discussing further.

[jrondorf]

Great post @MartinRaepple, thanks therefore 🙂

[H_Ettelbrueck]

@MartinRaepple Great guide, and looking forward for the upcoming ones. Especially looking for the "deeper" integration which also populates SAP Cloud Identity's identity directory, in line with our strategic direction (see CIO guide).

A detail: I see you only add OIDC scope "offline_access" to the trust between IAS and Entra. I suggest adding the standard OIDC scopes "profile" and "email", to make sure BTP gets the typical user attributes in the standard token claims.

[sam_venkat]

@MartinRaepple  Hi, is it possible to use SAML between IAS and EntraID and OIDC between IAS and BTP? 

[H_Ettelbrueck]

@sam_venkat Yes, IAS handles the "protocol translation". Yet for curiosity: Why do you prefer SAML (between IAS and Entra)?

[sam_venkat]

@H_Ettelbrueck Thanks. It is not a preference thing but trying to minimize number of changes as we are operating this way for several years now. Is it easy to transition from SAML to OIDC for the setup between Entra and IAS?  Would it mpact the various BTP, SaaS applications that use IAS as a proxy?

[H_Ettelbrueck]

@sam_venkat Regarding switching the protocol, please check https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/switch-protocols-for-corpo.... My personal impression: It's definitely doable, yet it's a very sensitive change as it affects all applications connected to IAS in a fundamental way (=> if broken, it's effectively an outage).

With an existing tenant already integrated with Entra and already used with some applications, I don't see a strong urgency to switch immediately. Just keep in mind every new application increases the hurdle to switch later, but that might be ok. With a new tenant, or no existing integration with Entra yet, I'd rather start immediately with OIDC.

[sam_venkat]

@H_Ettelbrueck  Thanks for the suggestions.

[tskwin]

Hi @MartinRaepple and @H_Ettelbrueck,

As I understand it,  OIDC is recommended for the setup between IAS and cloud applications. What protocol would you recommend for the integration between Entra ID and IAS?

Many Thanks

[H_Ettelbrueck]

@tskwin For most SAP scenarios, I think it's up to your personal preference for either SAML or OIDC. I just tend towards OIDC for two reasons:

• There are a few SAP scenarios which require OIDC between IAS and Entra ID. Usually this is about principal propagation between MS and SAP "worlds", which works best when just exchanging OAuth/OIDC tokens. From that perspective, OIDC has an advantage over SAML because it covers something that SAML doesn't.
• Afaik, but without deeper insights, my understanding is that Entra ID supports some features only with OIDC. @MartinRaepple Can you shed some more light on this?

[Brian_Stempien]

First off, great article and I was able to get it to work with an SAP Trial Account and MS Entra Trial Account with Id Governance trial.

One issue was Step 20. For some reason in both Chrome and Edge the Download of the Signing Certificate didn't work. I had to view the Certificate, Copy the Certificate Information and paste that into a text file. Then add the BEGIN and END certificate lines to the first and last line. That imported into Entra just fine. 

I had played a bit with CIS before starting this article and had created my own groups in CIS. That causes the groups attribute to already exist. I ended up having to delete the attribute, then add it back in with both Corporate ID and Identity Directory entries. 

Thank you for a great article!

[MartinRaepple]

@sam_venkat : Yes, you could also configure IAS as a SAML proxy to Entra ID, and add the groups attribute to the SAML assertion issued by Entra ID. Please find more details here.

[MartinRaepple]

Thank you for testing the scenario and your feedback @Brian_Stempien!

I've checked step 20 and now also saw the same issues with the Download button for all common web browsers (Edge, Chrome, Firefox). So I've added your workaround to the description of this step. Thanks for making us aware.

@H_Ettelbrueck : Can you possibly check if there is an issue with the Download of the OIDC signing cert? I remember 3 weeks ago the download worked. 

[tskwin]

Hi @MartinRaepple,

Thank you very much for your response/support. Can you please explain how the user attribute transfer (under OpenID) works?

How are user attributes transferred to SAP BTP under OpenID (user is not present in IAS)?

I have defined attributes in IAS like this

 but when I log into SAP BTP, it looks like this:

Do the attributes need to be assigned to the app in Azure?

I don't understand how attributes are transferred under OpenID. Where should the attributes be maintained?

How can I transfer for exymple attributes like employee_id?

Many Thanks

Best Regards

[Guido_Jacobs]

@tskwin

I have added the claims "family_name" en "given_name" in Entra app registration for SAP Cloud Identity Services. 

And requested in addition to what is mentioned in the blog the following scopes in the Corporate Identity Provider "email" and "profile":

Hope this helps...

Regards,

Guido

[markus_fugger_de]

@MartinRaepple  Yes, the download button is not working, it just adds the error "Uncaught TypeError: this.onDownloadButtonPressed is not a function" to the dev console. 

So I manually downloaded the OpenID certificate in step 20 and uploaded it to Entra ID. However during the verification (step 34-36) I got the error: Failed to receive tokens from URI [https://login.microsoftonline.com/xyz/oauth2/v2.0/token]. Received response error [401 Unauthorized: "{"error":"invalid_client","error_description":"AADSTS700027: The certificate with identifier used to sign the client assertion is not registered on application. [Reason - The key was not found., Thumbprint of key used by client: 'A42...E9',

I found that the signing certificate under "SAML 2.0 Configuration" in the IAS is the one used for this request. When I download this from the IAS SAML 2.0 Configuration and upload it to the Entra ID App registration then the validation is working fine. 

@H_Ettelbrueck Why is the IAS using the SAML certificate to sign the client assertion? 

UPDATE: Just verified this with a third tenant: It looks like upon creation the same certificate is added to the saml and openID section, so you do not notice a problem. When you renew the OpenID certificate, it differs from the SAML one, however IAS will use the SAML certificate to sign the OpenID requests. To verify this, you can recreate the OpenID certificate. Then delete the old one in Entra ID and upload the new one and it should not be working anymore. 

[markus_fugger_de]

I connected two IAS tenants to the same Entra ID with OpenID Connect (two App registrations). On one of them it is working (despite the strange certificate thing I wrote about before), on the other one I get the message "Invalid JWT." during the validation. When I check the json under Raw Response in "Step 2 - Token" and compare it with the working one, they look almost identical, of course some IDs are different.

So I don't know why the one JWT should be invalid. There is nothing in the Troubleshooting Logs, is there any other way to check why the JWT is invalid? 

[sarathgs1]

How to bring in SAP GRC Access Control User access requesting with Entra ID, so that we can send the request to SAP GRC AC for SoD checks.

for this scenario, we also may need to bring in BRM defined business roles to Entra ID, so that provisioning scenario can check SoDs in GRC. 

[ncktz]

Hi @MartinRaepple,

Thanks a lot for this great post and detailed step-by-step guide!

How will this work with the new Authorization Management Service that SAP "generally recommends for newly built applications" (https://community.sap.com/t5/technology-blogs-by-sap/authorization-management-service-in-sap-cloud-i...) and that requires users to be replicated to the Identity Directory Service? 
I guess this is also what @H_Ettelbrueck mentioned with "especially looking for the "deeper" integration which also populates SAP Cloud Identity's identity directory, in line with our strategic direction."
Is this already planned to be released in the near future or when is this expected to work? Currently, it seems to me like two approaches that unfortunately do not fit together (yet?).

Thanks a lot for the clarification,
Nico

[tskwin]

Hello Experts

@MartinRaepple, @Guido_Jacobs @H_Ettelbrueck  - Many Thanks for support.

I have completed the configuration with ODIC. It works. Thank you for the guide.

I have one question: When users log in to SAP BTP, the email address is populated in the "User Name" field. How can I populate a different attribute, such as UPN from Azure, into the "User Name" field in BTP?

And the second question: I can only log in in BTP  with the UPN (firstname.lastname@mail.com). Logging in with the email address doesn't work. What did I do wrong?

Many Thanks

Best Regards

Thank you.

[H_Ettelbrueck]

@ncktz Picking up your point:

How will this work with the new Authorization Management Service that SAP "generally recommends for newly built applications" (https://community.sap.com/t5/technology-blogs-by-sap/authorization-management-service-in-sap-cloud-i...) and that requires users to be replicated to the Identity Directory Service? 
I guess this is also what @H_Ettelbrueck mentioned with "especially looking for the "deeper" integration which also populates SAP Cloud Identity's identity directory, in line with our strategic direction."
Is this already planned to be released in the near future or when is this expected to work? Currently, it seems to me like two approaches that unfortunately do not fit together (yet?).

I assume your point is: This blog "only" describes the federation approach, where users and their assignments are only stored in Entra ID, and IAS acts as pure proxy, propagating the information received from Entra ID to BTP. This works for "traditional" BTP applications that use the SAP Authorization and Trust Management service (XSUAA) which supports this federation approach, and not for newer applications which natively use SAP Cloud Identity service and specifically its Authorization Management service. That's because the latter requires users to exist in the Identity Directory of Cloud Identity, and assignments being stored there, too.

My answer is twofold then:

• The federation approach is also planned for the Authorization Management service, since heading for feature parity (+ some advantages, of course). See the following roadmap entry: https://roadmaps.sap.com/board?PRODUCT=73555000100800000287&range=CURRENT-LAST#Q1%202025;INNO=15836D...
• Strategically, I definitely recommend to still populate the Identity Directory with all relevant users, because there's a growing amount of applications and scenarios that require this data to be available for different reasons. In general, our vision for SAP Cloud Identity services is to become a central integration hub for IAM between your corporate IAM and the whole SAP cloud landscape, and handle the integration between Cloud Identity and the applications more and more by SAP ("SAP-managed" setup). That means, it's not about establishing yet another target for your user provisioning, but to reduce the whole number you have today by ideally just a single one, namely your Cloud Identity tenant.

@MartinRaepple Seems like we should also describe this "provisioning" case, replicating original users, groups, and assignments, from Entra ID to the Identity Directory 😉

[tskwin]

Hello everyone,

@MartinRaeppleThanks again for this blog!

I have two questions:

1. Question: In IAS, I have set the "Subject Name Identifier=Corporate Identity Provider=email". However, I cannot log in to BAS using my email address, only with the UPN. If I set the Subject Name Identifier=Corporate Identity Provider=upn", I get the error message "Configuration Error". Why can't I log in using my email address?

2. Question: I have deleted all attributes for the BTP application in IAS and left only Group=Corporate Identity Provider=${corporateIdP.groups}. In Azure, under "App Registration / My App / Token Configuration / Optional Claims", I have defined the attributes family_name, given_name, groups, email, and upn. @Guido_Jacobs thanks for the tip! These attributes are then transferred to BTP. If I delete these attributes in Azure, no attributes are transferred to BTP.  So, does it not matter which attributes are defined for IAS/Bundled Applications (ODIC)? Are only the attributes defined in Azure transferred?

Many Thanks

Best regards

[MartinRaepple]

@ncktz, @H_Ettelbrueck ,

good news 😉: Just finished part II of this blog post series which covers user provisioning in a hybrid scenario using Entra Cloud Sync, Entra ID Governance, SAP Cloud Identity Service Provisioning Service, & SAP Cloud Connector.

Hope you enjoy it and please let me know if you have any questions/comments/suggestions for improvements etc.

[sam_venkat]

@MartinRaepple @H_Ettelbrueck Hi, trying to set up a new IAS tenant with OIDC integration with Entra ID following this blog.  In IAS Admin Console, Application > System Applications > Administration Console shows "Protocol Type: SAML2.0".    How to change it to OIDC?

[markus_fugger_de]

This setting is only for the authentication between IAS and the Admin interface and I don't think you can change this as it is a system application. 

For the OIDC integrations between IAS and Entra ID you have to go to Identity Providers > Corporate Identity Providers and create your Entra ID provider here with Type OIDC like Martin showed above from step 8 on. 

[H_Ettelbrueck]

This setting is only for the authentication between IAS and the Admin interface and I don't think you can change this as it is a system application.

Or to put it more clearly: There's not even a need to change the protocol for this application. The protocol is chosen separately for each application and each corporate IdP, and IAS "translates" between them as required.

[sam_venkat]

@H_Ettelbrueck Following this blog we set up  authentication as follows: 

Entra ID - (OIDC)- IAS - (OIDC) - App.    This set up works .  

But for Admin Console are you suggesting  to configure Entra ID - (SAML) - IAS admin console system application in IAS?  Is it possible to have both OIDC and SAML against the same EntraID Enterprise App registration? 

[H_Ettelbrueck]

@sam_venkat There is no direct integration between Entra ID and the IAS admin console (system application). It's rather:

Entra ID - (any protocol, SAML or OIDC) - IAS - (SAML) - IAS admin console system app

Or generically, since the admin console is just like all the other applications in this regard:

Entra ID - (protocol chosen by customer) - IAS - (protocol chosen by app) - application

So no need to integrate IAS and Entra ID twice with two different protocols. Just once, with whatever protocol you prefer.

[markus_fugger_de]

The good thing about SAML is that you can use "Allow users stored in Identity Authentication service to log on" option when the protocol between IAS and the application is SAML and you have configured the corporate provider to be used by default but not all app users have a user there. With OIDC this is not possible according to the documentation. 

[H_Ettelbrueck]

@markus_fugger_de In general, IAS has a similar feature also with OIDC, just not IdP-initiated, but SP-initiated. In any case, the user gets a URL which contains two pieces of information: The targeted application and the desired (corporate) IdP. This just works a bit differently with OIDC.

More concretely: You open an OIDC application by its URL, and this URL contains the desired corporate IdP. The application propagates this information to IAS, which then routes you to the respective corporate IdP (resp. authenticates you locally at IAS).

IAS documentation: https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/create-url-to-access-saml-...

Currently there's still the challenge that adoption by applications is quite low. Yet, as a positive example, SAP approuter already supports it, so you can use it in custom BTP applications.

[markus_fugger_de]

Hello @H_Ettelbrueck , 

Thanks for your reply!

Yes, I know this parameter, but does it really offer the same functionality? I know you can control which one of the identity provider in the BTP subaccount it should use if you have more than one configured in your subaccount. For Example your subaccount is connected to IAS and Entra External ID you can control which one is used. How would I create a URL to tell the application to use the IAS as identity provider but that it should not forward the request to the Corporate Identity provider that is configured as Default Authenticating Identity provider for the application but use its own user directory? 

For example this URL will always use the Default Authenticating Identity Provider for the btp-platform application:
https://emea.cockpit.btp.cloud.sap/cockpit/?idp=yourtenant.accounts.ondemand.com#/globalaccount/<UID> 
The login_hint does not help to change this. You could only use rules to work around that but in my opinion rule are not very nice because users have to enter their mailaddress manually and I Ranges are hard to configure correctly. 

For SAML you had the default URL (e.g. https://www.successfactors.com/yourtenant) with SSO for the major part of the users and this URL for the few users that only exist in IAS, no rules were required: https://yourtenant.accounts.ondemand.com/saml2/idp/sso?sp=https://www.successfactors.com/yourtenant&...  

Or did I miss anything on this parameter? 

Best regards,
Markus 

[sam_venkat]

@H_Ettelbrueck  Thanks for clarifying. the Admin Console SSO works fine now with SAML2 configuration between IAS and Admin console app.

[H_Ettelbrueck]

@markus_fugger_de Your question touches exactly what I meant by this statement:

Currently there's still the challenge that adoption by applications is quite low.

Afaik currently you can use it with custom BTP applications if they authenticate directly with IAS and not via Authorization and Trust Management service (XSUAA). In that case, only your custom application needs to propagate the desired corporate IdP (which you'll usually achieve by having an own approuter as part of the application). Documentation for direct usage of IAS with BTP applications: https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/integrating-service-with-i...

For SAP Build Work Zone, which has the option for direct IAS authentication only, this is a known requirement and I think it's planned.

Most BTP applications currently don't integrate directly with IAS yet, so this option doesn't work for them so far. I'd be very happy to be able to support propagation also in the longer chain, from application over XSUAA to IAS. However, unfortunately I have no way to get it into the near-term development backlog at this point.

Proposal: Open an influence request on https://influence.sap.com/sap/ino/ and then let's collect demand there.