Identity
SAML 2.0
OIDC
MFA

SAP Identity Authentication Service (IAS)

SAP's cloud identity provider — acting as a proxy between corporate identity stores and SAP BTP applications. Provides SAML 2.0, OIDC, MFA, Risk-Based Authentication, and branding customisation.

IAS Authentication Flow — Corporate IdP Federation
Rendering diagram…

Executive Summary

SAP IAS is the cloud identity provider bundled with SAP BTP. It acts as a proxy IdP — federating authentication requests from BTP applications to corporate identity stores (Azure AD, Okta, ADFS, etc.) via SAML 2.0 or OIDC. IAS provides MFA, risk-based authentication, branding, and a self-service user store for scenarios without a corporate IdP.

Every SAP BTP customer receives one IAS tenant bundled with their CPEA or subscription contract. This single IAS tenant serves as the identity hub for all BTP subaccounts and SAP cloud applications.

IAS Architecture Concepts

IAS TenantOne per SAP customer — provisioned automatically with BTP. Accessed at <subdomain>.accounts.cloud.sap. Admin console at admin.accounts.cloud.sap.
Applications in IASEach BTP subaccount registers as an 'Application' in IAS. The application configuration controls authentication rules, branding, and corporate IdP association.
Corporate IdP FederationIAS acts as Service Provider (SP) to the corporate IdP (Azure AD, Okta). The corporate IdP handles the actual credential verification and MFA.
IAS User StoreIAS maintains its own user store for non-federated users (partners, contractors without corporate AD accounts). Supports SCIM API management.
Conditional AuthenticationRisk-based rules: IP range restrictions, device type, time of day, user group → trigger step-up MFA or block access.
Multi-Factor AuthenticationTOTP (authenticator app), SMS OTP, email OTP, FIDO2/WebAuthn passkeys. Configure at application level or as global default.
Social LoginOptionally enable Azure AD, Google, or LinkedIn as direct login options (not recommended for enterprise — use corporate IdP federation instead).
User Attribute MappingCorporate IdP SAML attributes → IAS user schema → XSUAA JWT claims. Map custom attributes (department, cost center) for use in CAP authorization logic.
REST APIsSCIM 2.0 API for user/group CRUD operations. Authentication API for programmatic authentication flows. Token API for token exchange.

IAS Authentication Flow Explained

1User accesses BTP app URL. App Router detects no active session.
2App Router redirects to IAS using OIDC Authorization Code flow.
3IAS checks its configuration — sees a corporate IdP (Azure AD) is configured for this application.
4IAS redirects to Azure AD with a SAML 2.0 authentication request.
5Azure AD presents the corporate login page. User authenticates and completes MFA (Conditional Access).
6Azure AD returns a SAML Assertion to IAS with user attributes and group memberships.
7IAS issues an OIDC ID Token and Access Token to the App Router.
8App Router exchanges the OIDC token for a BTP JWT at XSUAA. Scopes are evaluated.
9App Router stores the JWT in a session cookie. User sees the rendered application.

IAS SCIM API — User Management

Use SCIM API for automated user operations
The SCIM 2.0 API supports bulk operations, filtering, and delta queries. Use it for automated onboarding workflows and migrations — not the admin console which has no audit trail for bulk actions.
ias-scim-create-user.sh
1# Create user in IAS via SCIM API
2curl -X POST \
3  'https://your-ias-tenant.accounts.cloud.sap/service/scim/Users' \
4  -H 'Authorization: Basic <base64-encoded-clientid:secret>' \
5  -H 'Content-Type: application/scim+json' \
6  -d '{
7    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
8    "userName": "ahmed.ali@dewa.gov.ae",
9    "name": {
10      "givenName": "Ahmed",
11      "familyName": "Ali"
12    },
13    "emails": [{"value": "ahmed.ali@dewa.gov.ae", "primary": true}],
14    "urn:sap:cloud:scim:schemas:extension:custom:2.0:User": {
15      "attributes": [
16        {"name": "customAttribute1", "value": "UAE-GOV"}
17      ]
18    }
19  }'

Enterprise Example: DEWA Azure AD Integration

DEWA IAS Configuration
DEWA integrates IAS with Azure Active Directory (50,000+ employees). Azure AD is the authoritative user store. IAS configured as SP with Azure AD as corporate IdP. MFA enforced via Conditional Authentication rule for all BTP app access. Custom branding applied: DEWA logo, green color scheme, Arabic/English language support. Risk-based step-up MFA for admin actions (access from outside UAE IP ranges triggers FIDO2). IPS provisions users from Azure AD → IAS → BTP Role Collections nightly.

Best Practices

Configure corporate IdP federation

Never manage users manually in IAS for large enterprises. Azure AD / Okta is the authoritative source — IAS is the proxy, not the user store.

Enable MFA as a default authentication rule

Set MFA (TOTP, FIDO2) as the default for all IAS application types. Use Conditional Authentication to enforce step-up MFA for sensitive actions.

Set up custom domain for IAS

Configure auth.company.com as the IAS endpoint for a consistent SSO experience. Prevents user confusion with the default accounts.cloud.sap URL.

Configure logout URLs for all BTP applications

Set the logout URL in every IAS Application configuration to ensure proper session termination. Missing logout leaves dangling SSO sessions.

Use IAS API for bulk user operations

The SCIM 2.0 API supports bulk create/update/delete. Use it for large migrations or automated provisioning — not the admin console.

Common Pitfalls

Proxy mode without testing logout
When IAS acts as a proxy to a corporate IdP, logout must be propagated to both IAS and the corporate IdP. Untested logout leaves active sessions open.
Not mapping corporate IdP groups to IAS groups
Without group attribute mapping, AD security groups are lost at the IAS boundary — breaking IPS group-to-role-collection assignments.
Using default IAS login page without branding
The generic SAP login page confuses end users who expect DEWA branding. Always configure custom logo, colors, and text in the IAS admin console.
Duplicate users in IAS and corporate IdP
If a user exists in both the IAS user store and corporate IdP, authentication conflicts arise. Federated users must not also exist as local IAS users.

Security Hardening

IAS is the security perimeter for all SAP applications. Apply these controls to every IAS tenant:

Enable FIDO2 (passkeys) for all privileged admin and BTP administrator accounts
Configure IP allowlisting for corporate network ranges — block external access to admin console
Enable IAS audit logging and route events to SIEM
Set maximum session duration to 8 hours (not the default 12 hours)
Enable automatic account lockout after 5 consecutive failed authentication attempts
Review IAS application registrations quarterly — remove unused application entries

References

SAP IAS documentation
Complete SAP Identity Authentication Service reference and administration guide
IAS SCIM API reference
SCIM 2.0 API for user and group management in IAS
IAS admin console guide
Administration console (admin.accounts.cloud.sap) operation guide
Corporate IdP federation guide
Step-by-step guide for federating IAS with Azure AD, Okta, ADFS