54 · SAP Identity Authentication Service

Configure IAS as the IdP, establish trust in BTP Cockpit, add custom attributes, and enable risk-based MFA.

Episode 54 — SAP Identity Authentication Service (IAS)

What you'll learn

Why this matters

XSUAA is the authorization server. IAS is the authentication server — it handles passwords, MFA, and corporate SSO (connecting to Active Directory or other IdPs). Most enterprise BTP apps eventually integrate IAS for central user management.

IAS vs XSUAA — quick distinction

IAS  = WHO is the user? (authentication, MFA, corporate SSO, user directory)
XSUAA = WHAT can they do? (OAuth 2.0, scopes, role templates, JWT issuance)

Typical flow:

Browser → AppRouter → XSUAA (authorization code) → XSUAA redirects to IAS → IAS authenticates
→ sends SAML assertion → XSUAA issues JWT with scopes → CAP validates JWT

IAS tenant setup

  1. BTP Cockpit → Subaccount → Trust Configuration
  2. Click "Establish Trust" → choose IAS tenant
  3. BTP automatically creates a SAML trust between IAS and XSUAA
  4. Download the metadata, upload to IAS if not auto-registered

IAS application configuration

In IAS admin console (accounts.ondemand.com/):
1. Applications → Add → Web Application
2. Name: "Bookshop"
3. SAML 2.0 → Upload XSUAA metadata
4. Subject Name Identifier: User UUID or email

Custom user attributes from IAS

IAS can pass custom attributes from the corporate user directory to XSUAA:

Corporate AD → IAS (custom schema attributes) → SAML assertion → XSUAA → JWT
  1. In IAS: User Attributes → Add custom attribute (e.g., costCenter from AD attribute)
  2. Map to SAML assertion attribute name
  3. In xs-security.json: declare the attribute under attributes
  4. XSUAA includes it in JWT xs.user.attributes

Risk-based authentication (MFA)

IAS authentication policy:
- Low risk: standard login
- Medium risk: email OTP
- High risk: TOTP app required

Rules based on:
- User group
- IP range
- Time of day
- Application sensitivity

Configure in IAS admin → Risk-based Authentication → Create policy → assign to your application.

SSO across BTP apps

With IAS as the IdP, a user who has logged into App A is automatically logged into App B (same IAS tenant):

Alice logs into Bookshop (App A) → IAS session established
Alice opens Catalog App (App B) → IAS recognises the session → issues SAML assertion directly
→ App B issues JWT → Alice is in, no password prompt

Debugging IAS integration

# Check SAML assertion content (IAS admin console)
# IAS → Troubleshooting → SAML Tracer
# Shows the SAML assertion sent to XSUAA — verify attributes

# Check XSUAA trust configuration
# BTP Cockpit → Trust Configuration → your IAS tenant
# Should show: "Active", "User Logon Disabled: No"

# Decode JWT after IAS login and check 'iss' claim
# Should be your XSUAA URL, not the IAS URL
# (XSUAA issues the JWT; IAS is not visible in the JWT)

Production checklist for IAS

□ IAS tenant linked to BTP subaccount via Trust Configuration
□ XSUAA SAML trust configured (auto via "Establish Trust" button)
□ Corporate IdP (AD/LDAP) connected to IAS for employee users
□ MFA policy applied to sensitive applications
□ Custom attributes mapped: department, costCenter, region
□ Test SSO across at least two apps before go-live
□ Document the IAS tenant URL for support tickets

Hands-on exercise

  1. In BTP trial, click "Establish Trust" on your trial IAS tenant
  2. Log in to your CAP app via the browser (not Basic auth) — observe the IAS login page
  3. Check the JWT's sub claim — it's now an IAS user UUID, not an email
  4. Map the email attribute explicitly in IAS SAML configuration

Checkpoint ✓

Sign in for progress tracking & Q&A →