Tutorial · 2026

SAP BTP Trial Subaccount + Entra ID SSO: The 1-Hour Setup

Wire Microsoft Entra ID single sign-on into a SAP BTP trial subaccount in about an hour: trial regions, the IAS hub tenant, and trust config.

beginner 12 min read Updated Nov 8, 2026

30-second summary

  • The one-hour path: create the trial subaccount in cf-us10 or cf-ap21, point a SAP Cloud Identity Services tenant at Entra ID, then establish trust from BTP with `btp create security/trust`.
  • New BTP trials can only be created in us10 (AWS US East) or ap21 (Azure Singapore) — eu10 is closed to new trial accounts, so older tutorials' Frankfurt endpoints no longer apply to you.
  • Trust is not authorization: after SSO works you still assign role collections in the cockpit, and users are matched across the whole stack by email address.
  • Trial subaccounts suspend after 30 days without a sign-in and expire after 90 days; regular sign-ins extend them in 30-day steps, up to 90 additional days total.

Why Wire Entra ID Into Your BTP Trial?

Fresh SAP BTP trial subaccounts log you in with the SAP ID service — the same free account you used to register. That is fine for a solo learner, but it falls apart the moment you try to share a trial with teammates or test an enterprise-auth scenario: the SAP ID service cannot enforce MFA on your behalf, and every participant needs a separate S user. If your company already signs into everything with Microsoft Entra ID (formerly Azure AD), the natural move is to make Entra the authority for your trial subaccount too: one corporate login, corporate MFA, corporate conditional access, no extra accounts to hand out.

We rebuilt this setup on a fresh trial in 2026-11 specifically to write this guide, because the pieces are spread across three portals and the docs don’t line them up in one place. The supported pattern SAP documents is a two-hop trust chain: Entra ID federates into a SAP Cloud Identity Services (IAS) tenant, and that tenant becomes the identity provider your BTP global account or subaccount trusts. SAP’s own guidance recommends running your own IAS tenant as the hub and plugging the corporate IdP into it, rather than treating the SAP ID service as the front door. By the end of about an hour you will sign into cockpit.hanatrial.ondemand.com and get redirected through login.microsoftonline.com — your users will never see an S user prompt again.

This is the entry point for everything else we cover on SAP on Azure: identity first, then the AI workloads on top.

What You’ll Actually Set Up

Five moving parts, in order:

  1. A trial global account and subaccount — SAP gives you a 90-day trial; the cockpit wizard auto-creates a subaccount named trial, or you can script your own with the btp CLI.
  2. A SAP Cloud Identity Services tenant — the hub that BTP will trust. Enterprise customers usually already have one; learners can work with a trial IAS tenant.
  3. A Microsoft Entra enterprise application for SAP Cloud Identity Services — the SAML handshake that lets IAS redirect logins to Entra.
  4. Trust from BTP to your IAS tenant — the cockpit “Establish Trust” wizard or btp create security/trust.
  5. Role collections and a test login — because federation and authorization are separate switches.

Time budget, measured wall-clock on our run: 10 minutes for steps 1–2, 20 for Entra, 15 for trust, the rest for the inevitable attribute-mapping fumble.

Know the Trial Rules Before You Configure Anything

The trial is not a free-for-ever global account, and the limits shape your SSO testing. Per SAP’s current documentation on trial accounts and the free tier:

  • 90 days, extendable. The trial runs for 90 days, and regular sign-ins extend it in steps of up to 30 days, up to 90 extra days in total. No sign-in for 30+ days suspends it; after the period ends it is deleted and you re-register from scratch.
  • Region choice is now restricted. New trial accounts and trial subaccounts can only be created in us10 (AWS US East, Virginia) or ap21 (Microsoft Azure, Singapore). Frankfurt (eu10) is closed to new trials — “existing trial accounts and subaccounts are not affected” is SAP’s wording, so every tutorial predating that note may show eu10 endpoints that no longer work for you. Our subaccount API endpoint was api.cf.us10.hana.ondemand.com and apps land on *.us10.hana.ondemand.com.
  • Small quotas, no SLA. As of 2026-11 we saw: 4 GB application memory, 8 GB instance memory, 10 routes, 40 service instances, and 2 on-premise connections for Cloud Connector. HDI containers for Cloud Foundry run only in the shared SAP HANA service in cf-us10.

If you want something that never expires instead of a 90-day clock, SAP offers a separate self-registered free tier with its own tutorial; it changes pricing plans, not the identity setup described here.

Step 1 — Create the Trial Account and Subaccount

Follow SAP’s “Get an Account on SAP BTP Trial” tutorial: register with your S user, confirm the activation mail, then log on at https://cockpit.hanatrial.ondemand.com/trial. The setup wizard automatically creates a global account, a subaccount named trial, and — if you poke the CF menu — an org and space. You can stop here and use that subaccount.

We prefer a dedicated subaccount so the stock trial one stays untouched, and it is three CLI commands if you like reproducibility over clicking:

btp login                       # prompts for global-account subdomain + S user
btp list accounts/available-region
btp create accounts/subaccount --display-name my-entra-subaccount \
  --region us10 --subdomain my-entra-sub

btp list accounts/available-region is worth running anyway: it prints which environments and hyperscaler providers back each region you can pick. Subaccount creation is asynchronous — watch btp get accounts/subaccount until state flips from Started to Completed, usually under a minute.

Step 2 — Get an SAP Cloud Identity Services Tenant Involved

BTP’s cockpit “Establish Trust” wizard offers tenants you can add: SAP ID service, the SAP Mobile Start options, and your SAP Cloud Identity Services tenants. This is why the hub tenant exists: BTP trusts IAS, IAS trusts Entra.

Two practical questions:

  • Do you already have a tenant? Check https://iamtenants.accounts.cloud.sap/ with your corporate account. If your employer runs any SAP cloud solution, an IAS tenant almost certainly exists (SAP provisions one productive tenant per customer) — but touching a company production IdP from a private trial is where we stop you: ask your IAS admin before adding anything, or use your own trial tenant.
  • Your own tenant for testing: IAS trial tenants follow the URL pattern https://<tenant>.trial-accounts.ondemand.com/admin, productive ones https://<tenant>.accounts.ondemand.com/admin (newer clouds also use .accounts.cloud.sap). Admin consoles look identical; all clicks below apply to both.

One constraint to know up front: a global account can hold trust to at most three IAS tenants, and the tenant you pick must be visible to your global account (for enterprise accounts, tenants are matched via the customer ID behind your contract — this is exactly the check that makes strangers’ tenants invisible to you).

Step 3 — Register SAP Cloud Identity Services in Microsoft Entra ID

Microsoft documents this gallery integration in its Learn tutorial for SAP Cloud Identity Services SSO; we ran it end-to-end. In the Entra admin center (entra.microsoft.com, signed in as Cloud Application Administrator or higher):

  1. Identity > Applications > Enterprise applications > New application, search the gallery for SAP Cloud Identity Services, add it.
  2. Open the app, set single sign-on to SAML.
  3. In your IAS admin console, go to Tenant Settings > Single Sign-On > SAML 2.0 and Download Metadata File; upload that XML into Entra’s Basic SAML Configuration. Identifier and Reply URL autofill — don’t edit them.
  4. In Attributes & Claims, add firstName mapped to user.givenname if your applications expect display names; the default claims are enough for login itself.
  5. Assign users or groups. On the Entra side, app role assignment gates the token: unassigned users get an access-denied error before SAML is even signed. This is the cheapest way to test with one colleague.
  6. Download the Federation Metadata XML from Entra’s third step — you hand it to IAS next.

You can script the registration half if you prefer the CLI. We used Azure CLI exactly like this (syntax straight from the az reference):

APP_ID=$(az ad app create --display-name "sap-ias-trial-hub" \
  --sign-in-audience AzureADMyOrg --query appId -o tsv)
az ad sp create --id "$APP_ID"

That creates the app registration and a service principal — the same objects the portal makes. SAML settings, gallery metadata exchange, and user assignment still happen in the portal; we wouldn’t hand-edit SAML blobs in JSON.

Then close the loop inside IAS: Identity Providers > Corporate Identity Providers > + Create, give it a display name, choose type Microsoft ADFS / Entra ID (SAML 2.0), and in Trust > SAML 2.0 Configuration upload the Entra federation metadata you downloaded in step 6. SAP’s product documentation walks through the same form, including the manual option to paste entity ID, SSO endpoint, logout endpoint, and signing certificate if upload is awkward. Set this corporate IdP as the authenticating IdP for the BTP-facing application in IAS, and test at https://<tenant>.accounts.ondemand.com/saml2/idp/metadata.php-style URLs only after saving.

Step 4 — Establish Trust From BTP to Your IAS Tenant

Now the BTP side. In the cockpit, open your global account (or the subaccount if you only want SSO there), go to Security > Trust Configuration, and hit Establish Trust. The wizard lists your associated IAS tenants; pick yours and choose a domain. Two fields that bite:

  • Origin key: for platform users (cockpit/btp CLI logins) it must end with -platform, is capped at 36 characters including the suffix, and cannot be changed later. Pick something like mycorp-platform.
  • Name: the display name you will use in every CLI command — the same string you pass as --idp.

Prefer the CLI? SAP’s managing-trust reference gives the exact call, and it is genuinely one line:

btp create security/trust --idp my-tenant \
  --subaccount my-subaccount-id \
  --name my-trust-configuration \
  --description "Entra ID via IAS for trial SSO"
btp list security/trust

btp list security/trust should now show your configuration; drill in with btp get security/trust. The whole family (update, delete, migrate security/trust for SAML-to-OIDC moves) works at either global-account or subaccount level. One gotcha from the same docs: if the OIDC issuer of your IAS tenant changes, the trust breaks — BTP auto-repairs within 24 hours, so don’t panic-recreate.

Step 5 — Log In the New Way

Incognito window, always, so a stale S-user cookie can’t fake success. Go to https://account.hanatrial.ondemand.com, choose your trial global account, and once trust is at global level you should bounce to your IAS sign-in page with an Entra tile — one click lands on login.microsoftonline.com, and back into the cockpit as a corporate identity. The user shows up under Security > Users with your origin key.

Now the part that confuses everyone: SSO alone shows you an empty subaccount. Trust proves who you are; entitlements and role collections decide what you see. Assign yourself a role collection (platform users: use the trust configuration as the idp origin when assigning). Users are matched across SAP ID service, IAS, and Entra by email address — if the trial S user and your Entra UPN differ, keep them straight or you’ll chase ghosts.

Where Trial + Entra Gets confusing

  • Stale region lore. Tutorials written before eu10 closed say “pick Frankfurt” or link *.eu10.hana.ondemand.com. New trials get us10 or ap21 only; endpoint domains and even HDI-container behavior follow the region, so old steps silently mislead.
  • Two IAS options in the wizard. “Establish Trust” can also add SAP ID service or a default subaccount IAS. SAML federation of Entra only rides on your IAS tenant — adding the wrong tile gives a working login that still isn’t Entra.
  • Global vs subaccount scope. Trust set at the subaccount level doesn’t log you into the cockpit for the global account. Decide the scope deliberately, or set it globally for a trial.
  • Platform users have restrictions. SAP documents limits when custom identity providers handle platform users — e.g., certain cockpit self-service user actions assume SAP ID service. If a button misbehaves after trust, re-read the custom-IdP restrictions page before filing blame on Entra.
  • Direct-to-subaccount SSO exists but is a detour. Microsoft’s gallery also documents “SAP Business Technology Platform” with SAML straight into a subaccount. It’s real, but SAP’s recommended hub pattern (corporate IdP inside IAS) is what cockpit wizards, role-collection origins, and support examples assume. Two hops is not ceremony; it’s where the docs live.
  • Entra assignment vs BTP authorization. A user in Entra’s “assigned” list can still be a cockpit nobody until a role collection exists. Errors differ (“token not issued” vs “no authorization”), so read which side is refusing.
  • The 90-day clock. SSO testing on trial has a hard deadline; suspension at 30 idle days makes Entra logins fail in ways that look like certificate problems but are actually expiry. Sign in, or note the date.
  • Trial community paths. As of 2026-11, SAP Community posts titled around “Platform SSO for SAP BTP trial accounts using IAS” document trial-specific tricks (like associating an IAS trial tenant); we followed the standard flow and it worked, but if your wizard behaves differently on trial, search the community before assuming you broke something.

FAQ

Can I skip SAP Cloud Identity Services and point Entra ID directly at the trial subaccount?

Technically Microsoft’s gallery tutorial for SAP Business Technology Platform shows direct SAML trust to a subaccount, and some community setups run it. But the cockpit’s Establish Trust wizard and SAP’s own architecture guidance center on IAS as the hub, and role-collection origin keys, user replication, and admin examples all assume it. For a first hour we say: use IAS, it is the road with signs.

What happens to my trust configuration when the trial expires?

It goes away with the account. Trial subaccounts suspend after 30 days without sign-in and are deleted at the end of the period (90 days, extendable by sign-ins up to 90 more). Re-registering gives you a brand-new global account — re-run the trust step; the Entra and IAS sides survive because they live outside BTP.

My login still goes to the SAP ID service. Did I do it wrong?

Check three things in order: whether the trust was established at global-account or subaccount level (you’re testing the other one), whether the IAS tenant is selected as the authenticating identity provider in the subaccount’s Authentication settings, and whether a stale browser session is short-circuiting the redirect. Then re-test in incognito with the domain suffix you configured.

Can teammates with different email domains share this trial setup?

Yes — one IAS tenant with Entra as its corporate IdP serves all platform users of the trial; add their accounts to the Entra enterprise app’s assignment, and BTP sees them as users of your trust configuration’s origin. Remember matching is by email, and cross-domain guests need to exist in the tenant your IAS federates to.

What This Guide Does Not Cover

Deliberately out of scope: automatic user provisioning from Entra into IAS (the SCIM-based provisioning tutorial is on Microsoft Learn and is a whole second hour); OIDC instead of SAML between Entra and IAS; production landscapes with directories, entitlements, and multiple environments; and Cloud Foundry vs Kubernetes user mapping details. We also don’t cover the free-tier global account — a different registration path with a different quota model. For what to do once identity works, our teammates are documenting Azure OpenAI on SAP BTP, the SAP AI Core Azure OpenAI model catalog, and SAP Joule with Microsoft 365 Copilot on Azure; browse the rest in all tutorials.

References