essay 2026.05.10 13 min readcloud security · compliance

Federating SAP BTP with Microsoft Entra — Zero-Sync, Claim-Based Access with Governed Provisioning

A comprehensive guide to setting up federation between SAP BTP and Entra ID with claim-based access to SAP BTP resources using Entra ID identity governance and entitlement management.

Identity and Access Management with Microsoft Entra

Managing Access to SAP BTP — A Step-by-Step Technical Guide

---

Table of Contents

1. Background & Why This Matters
2. Scenario Overview
3. How It All Works — The Big Picture
4. Prerequisites
5. Phase 1 — Register SAP Cloud Identity Services in Entra
6. Phase 2 — Configure OIDC Corporate IDP in IAS
7. Phase 3 — Complete the App Registration in Entra
8. Phase 4 — Create the User Group in Entra
9. Phase 5 — Assign the Group to the BTP Role Collection
10. Phase 6 — Create the Access Package
11. Phase 7 — Test the Full Workflow
12. What You’ve Built — End-to-End Summary

---

Background & Why This Matters

SAP has announced that its SAP Identity Management (IDM) solution is approaching end of maintenance by 2027 (with extended maintenance until 2030). SAP’s official recommendation is for IDM customers to transition to Microsoft Entra (formerly Azure Active Directory) as their primary IAM platform.

This guide covers: a cloud-only, federated approach for cross-domain identity and access management between Microsoft Entra and SAP Business Technology Platform (BTP).

Why federated? Instead of replicating users and their group memberships into BTP directly, the federated approach means Entra ID remains the single source of truth. BTP trusts claims issued in tokens from Entra — no sync job, no duplication.

---

Scenario Overview

This guide walks through a real-world workflow:

• John Doe (a developer) needs access to SAP Business Application Studio on BTP
• To gain access, John must be assigned to the Developer role in BTP
• That role is part of the Business_Application_Studio_Developer role collection
• John requests this access through Microsoft Entra’s Entitlement Management
• Jane Smith (an Entra admin) approves the request
• Once approved, John’s group membership in Entra is securely carried through to BTP via token claims

---

How It All Works — The Big Picture

Understanding the flow before touching any configuration is crucial. Here’s what happens end-to-end when John logs in:

John's Browser
     │
     ▼
SAP Business Application Studio URL
     │  (redirected to trusted IDP)
     ▼
IAS (SAP Cloud Identity Services) ← acts as OIDC proxy
     │  (forwards auth request to corporate IDP)
     ▼
Microsoft Entra ID ← John authenticates here
     │  (issues ID token with "groups" claim containing John's group GUIDs)
     ▼
IAS receives token, forwards "groups" attribute to BTP
     │
     ▼
BTP checks role collection → matches group GUID → grants Developer access
     │
     ▼
John can use SAP Business Application Studio ✓

Why does BTP care about a GUID?

In BTP, role collections can be mapped to user groups by their Object ID (OID) from Entra. So when Entra says “this user is in group abc-123-guid”, BTP recognises that GUID as the Business_Application_Studio_Developer role collection and grants access. No username-to-role mapping needed — it’s all claim-based.

Why does IAS sit in the middle?

BTP’s trusted identity provider is IAS, not Entra directly. IAS acts as an OIDC proxy — it speaks to Entra on behalf of BTP applications, and forwards the relevant claims downstream. This keeps BTP decoupled from Entra’s specifics while still allowing Entra to be the authoritative identity source.

---

Prerequisites

Before starting, ensure you have access to:

Requirement	Notes
IAS tenant with full admin access	Can be a trial instance linked to a BTP trial account
SAP BTP subaccount with Space Manager access	Free trial works; IAS already configured as trusted IDP
Microsoft Entra ID P2 subscription with admin access	Free Microsoft 365 E5 developer subscription works; request Entra ID Governance trial
Two Entra test users	One to request access (John), one to approve (Jane)

💡 Why P2? Entitlement Management (used for Access Packages) is an Entra ID Governance feature, which requires a P2 or Governance licence. It’s not available on free or P1 tiers.

---

Phase 1 — Register SAP Cloud Identity Services in Entra

What we’re doing and why

Before IAS can talk to Entra as a trusted OIDC client, Entra needs to know IAS exists. This is done via an App Registration — essentially Entra’s way of registering any external application that will authenticate users through it.

We also configure the token claims here, specifically telling Entra to include the user’s security group memberships in the ID token. Without this, BTP never knows which groups John belongs to.

Steps

1. Log in to Entra Admin Center → Identity → Applications → App Registrations → click New registration

2. Enter a name (e.g. SAP Cloud Identity Services) → click Register

3. From the Overview page, copy the Application (client) ID — save it to a text file. You’ll need this when configuring the IAS side.

4. Click Endpoints and copy the OpenID Connect metadata document URL — save this too. IAS will use this URL to auto-discover Entra’s OIDC configuration.

5. Go to Token configuration → Add groups claim → check Security groups → click Add

💡 Why add a groups claim? By default, Entra tokens don’t include group memberships. By adding this claim, Entra will emit a groups array in the token containing the Object IDs (GUIDs) of every security group the authenticated user belongs to. BTP uses these GUIDs to evaluate role collection assignments.

---

Phase 1 — What happened?

You’ve told Entra: “There’s an application called SAP Cloud Identity Services, and when it authenticates users, include their group memberships as a claim in the token.” The app registration is the trust anchor — IAS will present itself as this registered application when requesting tokens.

---

Phase 2 — Configure OIDC Corporate IDP in IAS

What we’re doing and why

Now we switch to the IAS side. We need to tell IAS that Entra ID is its upstream (corporate) identity provider. IAS will forward authentication requests to Entra, receive tokens back, and act as a proxy — passing the relevant claims (including groups) onward to BTP.

We also configure how IAS authenticates itself to Entra when requesting tokens. Instead of a shared client secret (which expires and must be rotated), we use Private Key JWT — a much more secure method where IAS signs a JWT with its own private key, and Entra verifies it using IAS’s public certificate. No secret ever travels over the wire.

Steps

8. Log in to IAS Admin Console at https://<your-ias-tenant>.accounts.ondemand.com/admin → go to Identity Providers → Corporate Identity Providers → click Create

9–10. Enter a display name (e.g. BestRun Corp. Entra ID Tenant) → set Identity Provider Type to OpenID Connect Compliant → click Create

11–12. Select OpenID Connect Configuration from the Trust tab → paste the Discovery URL (the metadata URL from Step 5 of Phase 1) → click Load

IAS auto-discovers all Entra endpoints from this URL — token endpoint, authorisation endpoint, JWKS, etc.

13. Set Client Authentication Method to Private key JWT

💡 Why Private Key JWT? A client secret is a shared password — it must be rotated periodically and is sent on every token request. Private Key JWT uses asymmetric cryptography: IAS signs an assertion with its private key, Entra verifies with IAS’s public cert. Far more secure, and no rotation of shared secrets.

14. Paste the Application (client) ID (from Phase 1, Step 3) into the Client ID field

15–16. Scroll to Scopes → Add → enter offline_access → save

💡 Why offline_access? This scope requests a refresh token alongside the access and ID tokens, allowing IAS to silently renew sessions without forcing users to re-authenticate frequently.

17. Save the configuration, then click OIDC Callback URL to copy it — you’ll need this in Phase 3 to register the redirect URI back in Entra.

18–20. Go to Applications & Resources → Tenant Settings → Authentication → OpenID Connect Configuration → download the default Signing Certificate

⚠️ Known issue: The Download button is broken in most browsers. Instead, click the Display icon, copy the certificate content, and manually wrap it with:

-----BEGIN CERTIFICATE-----
<paste content here>
-----END CERTIFICATE-----

21–23. Go to Applications & Resources → Applications → find your SAP BTP subaccount under Bundled Applications → Conditional Authentication → set the Default Identity Provider to the Entra corporate IDP you just created → save

💡 This tells IAS: “For this BTP subaccount’s applications, send users to Entra to authenticate.”

24–26. Select Attributes → click Add → create the following attribute:

Field	Value
Name	groups
Source	Corporate Identity Provider
Value	${corporateIdP.groups}

💡 Why this attribute? Entra sends the groups claim in the token it issues to IAS. However, IAS doesn’t automatically forward every claim it receives to downstream BTP apps — you have to explicitly map it. This attribute definition tells IAS: “Take the groups claim from the corporate IDP token and pass it on to BTP applications.”

---

✅ Phase 2 Complete — What happened?

IAS now knows Entra is its upstream identity provider and will proxy all authentication requests to it. Crucially, it will extract John’s groups claim from Entra’s token and pass it along to SAP BTP. The private key JWT setup means this trust relationship is secure without shared passwords.

---

Phase 3 — Complete the App Registration in Entra

What we’re doing and why

We’ve now done the IAS side. We need to go back to Entra to complete the loop:

1. Register IAS’s Callback URL so Entra knows where to redirect after authentication
2. Upload IAS’s signing certificate so Entra can verify the JWT that IAS uses to authenticate itself

Steps

27–29. Back in Entra Admin Center → open your app registration → Manage → Authentication → Add Platform → Web → paste the OIDC Callback URL (from Phase 2, Step 17) as a Redirect URI → click Configure

💡 Entra will only issue tokens to redirect URIs that are explicitly registered. This prevents token hijacking to unknown endpoints.

30–32. Go to Manage → Certificates & Secrets → Certificates tab → Upload certificate → upload the IAS signing certificate file (from Phase 2, Step 20) → click Add

💡 This is how Entra verifies IAS’s identity when IAS performs private key JWT authentication. Entra checks that the JWT was signed by the private key corresponding to this certificate.

Validate the OIDC Proxy Setup

33–34. Back in the IAS Admin Console → Identity Providers → Corporate Identity Providers → select your provider → OpenID Connect Configuration → Validate

35. Accept the requested permissions from the Entra SAP Cloud Identity Services app (optionally consent on behalf of your organisation)

36. Inspect the token returned by Entra — you should see the groups claim with GUIDs for your user’s groups. This confirms the end-to-end token flow is working.

---

✅ Phase 3 Complete — What happened?

The OIDC proxy tunnel between Entra and IAS is fully established and validated. You can see real token data flowing, including the groups claim. The certificate handshake means IAS can authenticate to Entra without any shared secret.

---

Phase 4 — Create the User Group in Entra

What we’re doing and why

We need a Security Group in Entra that represents “SAP BTP Developers”. Membership in this group is what grants BTP access. When a user is added to this group, their next login to BTP will automatically reflect the new access — no manual role assignment needed on the BTP side.

Steps

37–38. In Entra Admin Center → Identity → Groups → New Group:

Field	Value
Group type	Security
Group name	SAP BTP Developer
Membership type	Assigned

Click Create

39–40. Open the newly created group → copy the Object ID and save it

💡 Why the Object ID? This GUID is what appears in the groups claim in Entra tokens. BTP doesn’t understand group names — only GUIDs. You’ll map this GUID to a BTP role collection in the next phase.

---

✅ Phase 4 Complete — What happened?

You have a container (SAP BTP Developer group) that will be used to gate BTP access. Adding a user to this group → their token gets the group’s GUID → BTP recognises the GUID → access granted. Removing a user reverses the process automatically.

---

Phase 5 — Assign the Group to the BTP Role Collection

What we’re doing and why

Now we connect the Entra group to BTP’s authorisation model. BTP’s role collections control what users can do. We map the Entra group’s Object ID to the Business_Application_Studio_Developer role collection, so BTP knows: “if a user’s token contains this GUID in the groups claim, they’re a developer.”

Steps

41. Log in to BTP Cloud Cockpit → select your subaccount

42. Navigate to Security → Role Collections → select Business_Application_Studio_Developer → click Edit

43. Under User Groups:

• Select your IAS tenant as the identity provider
• Paste the Object ID of the SAP BTP Developer Entra group

💡 Why IAS as the IDP here? BTP trusts IAS as its identity provider (not Entra directly). The groups claim flows from Entra → IAS → BTP. So from BTP’s perspective, the group assertion is coming from IAS, even though IAS got it from Entra. BTP maps it based on the value of the claim, regardless of its ultimate origin.

---

✅ Phase 5 Complete — What happened?

BTP is now primed: if a user’s token (issued by IAS, which got it from Entra) contains the specific group GUID in the groups claim, BTP will grant them the Developer role. The chain from Entra group → IAS claim forwarding → BTP role is complete. We just need a way to add users to that Entra group in a controlled, approved manner — which is what the Access Package does.

---

Phase 6 — Create the Access Package

What we’re doing and why

An Access Package in Entra ID Governance is a bundle of resources (groups, apps, SharePoint sites, etc.) with a policy that governs who can request it, who needs to approve it, and how long it lasts. This is the self-service, governed workflow that replaces manual IT ticket-based access requests.

Instead of IT manually adding John to the SAP BTP Developer group, John requests the access package, Jane approves it, and Entra handles the group membership automatically.

Steps

44. In Entra Admin Center → Identity Governance → Entitlement Management → Access Packages → New access package

45. Enter:

• Name: SAP BTP
• Description: brief description of what access this grants
• Assign to the General catalog (default)

Click Next: Resource roles

46–47. Click Groups and Teams → check “show all groups” → search for SAP BTP Developer → select it → click Select

This links the access package to the group. Approving a request will add the user to this group.

48–52. On the Requests tab:

• Select For users in your directory → allow All members (excluding guests)
• Set Require approval to Yes
• Under First Approver, choose specific approvers → add Jane (or your admin user)
• Set Enable new requests to Yes

💡 Why require approval? This is the governance layer. Without it, anyone could self-grant BTP Developer access. The approval workflow ensures a human (Jane) reviews and authorises every request, creating an audit trail.

53–56. Click through Requestor information, Lifecycle, Rules (leave defaults) → Review + create → Create

57. After creation, copy the MyAccess portal link — this is the URL John will use to request the package.

---

✅ Phase 6 Complete — What happened?

You now have a full self-service access workflow. The Access Package wraps the SAP BTP Developer group with a governed request-and-approve process. The link you copied is the entry point for users to request BTP developer access. Everything downstream (group membership → token claim → BTP role) is already wired up from the previous phases.

---

Phase 7 — Test the Full Workflow

7a — Verify Access is Denied (Before Request)

58. In BTP Cockpit → your subaccount → Services → Instances and Subscriptions → copy the SAP Business Application Studio URL

59. Open a private browser window → paste the URL → log in as John (your test requester user)

60. You should see an error: no access due to missing role assignment ✓

This confirms the baseline — John has no access yet, as expected.

7b — Request the Access Package (as John)

61. In the same private window, open the MyAccess portal URL (from Phase 6, Step 57)

62. Find the SAP BTP access package → click Submit request

63. You receive a confirmation that the request is being processed → close the private window

7c — Approve the Request (as Jane)

64. Open a new private window → navigate to the MyAccess portal URL → log in as Jane (your approver user)

65. Go to Approvals → find John’s pending request → click Approve

66. Click Submit → you receive a confirmation → close the window

7d — Verify Access is Now Granted (as John)

68. Open a new private window → go to the SAP Business Application Studio URL → log in as John

69. This time, John successfully loads SAP Business Application Studio ✓

The full chain worked: Entra group membership → token claim → IAS forwarding → BTP role collection → access granted.

---

What You’ve Built — End-to-End Summary

Congratulations — here’s a recap of the complete architecture you’ve implemented:

┌─────────────────────────────────────────────────────────────────┐
│                    MICROSOFT ENTRA ID                           │
│  ┌───────────────┐    ┌──────────────────────────────────────┐  │
│  │  SAP BTP      │    │  Entitlement Management              │  │
│  │  Developer    │◄───│  Access Package "SAP BTP"            │  │
│  │  Group        │    │  (request → approve → group assign)  │  │
│  └───────┬───────┘    └──────────────────────────────────────┘  │
│          │ groups claim (GUID)                                   │
│          ▼                                                       │
│  Token issued to IAS (via Private Key JWT auth)                 │
└──────────┬──────────────────────────────────────────────────────┘
           │ OIDC (groups claim forwarded)
┌──────────▼──────────────────────────────────────────────────────┐
│                    SAP IAS (OIDC Proxy)                         │
│  Forwards groups claim via attribute mapping                    │
└──────────┬──────────────────────────────────────────────────────┘
           │ OIDC (groups in token)
┌──────────▼──────────────────────────────────────────────────────┐
│                    SAP BTP                                       │
│  Role Collection: Business_Application_Studio_Developer         │
│  ↕ mapped to group GUID                                         │
│  → John gets Developer role → SAP BAS access granted ✓         │
└─────────────────────────────────────────────────────────────────┘

Key Decisions Made in This Architecture

Decision	Why
OIDC (not SAML) between Entra and IAS	Better support for token exchange, principal propagation, and some Entra-specific features
Private Key JWT for client auth	No shared secrets, no rotation overhead, more secure
Groups as GUIDs in token claims	Decoupled from group names; BTP maps GUIDs to role collections directly
Access Packages for provisioning	Self-service with approval workflow, full audit trail, automatic group membership management
IAS as OIDC proxy	Keeps BTP decoupled from Entra; IAS handles protocol translation and is the single trusted IDP for all BTP apps

---