Sap Btp Cloud Identity Services

SAP Cloud Identity Services

SAP Cloud Identity Services are a group of services on SAP BTP that manage identity and access across cloud and on-premise systems. They provide single sign-on, user provisioning, and policy-based authorization.

The services comprise:

• Identity Authentication (IAS) — cloud-based authentication, SSO (OIDC/SAML 2.0), corporate IdP federation, conditional authentication, and user store management. Acts as the identity provider for SAP BTP applications.
• Identity Provisioning (IPS) — identity lifecycle management as a service. Synchronizes users and groups between source and target systems (SAP and non-SAP) with full and delta read modes, real-time provisioning, and transformation support.
• Identity Directory — the central user store. Provides SCIM 2.0 REST API, custom schemas, and generates the Global User ID distributed by IPS to SAP cloud applications.
• Authorization Management (AMS) — policy-based authorization for BTP applications. Developers define policies in Data Control Language (DCL); administrators refine and assign them via the administration console.

Related Skills

• sap-btp-connectivity — destination service and connection authentication mechanics (OAuth client credentials, principal propagation through Cloud Connector)
• sap-cap-capire — CAP application-level auth usage (role templates, @requires annotations, cds deploy with xs-security.json)
• sap-btp-best-practices — high-level security governance and production deployment patterns
• sap-btp-cloud-platform — BTP account setup, subaccount configuration, service instance creation

When to Use This Skill

• Registering an OIDC or SAML 2.0 application in IAS
• Configuring corporate identity provider federation (IdP proxy)
• Establishing trust between a BTP subaccount and an IAS tenant
• Setting up Identity Provisioning source/target systems and jobs
• Writing or refining AMS authorization policies (DCL)
• Migrating from XSUAA to IAS-based authentication
• Troubleshooting token validation, audience, or issuer mismatch errors
• Configuring conditional authentication (risk-based, MFA)
• Integrating IAS with the SAP BTP Identity service (automatic OIDC app creation)

Quick Reference

Identity Authentication (IAS)

IAS is the entry point for authentication in SAP BTP applications. It supports OIDC and SAML 2.0 protocols, acts as an identity provider or a proxy to corporate IdPs, and provides conditional authentication based on user attributes, email domain, user group, or IP range.

Application Registration

Register applications in the IAS admin console under Applications and Resources > Applications. Each application defines:

• Application Type — OIDC or SAML 2.0
• Trust Configuration — SP metadata upload (SAML) or redirect URIs (OIDC)
• Authentication — method, conditional rules, IdP selection
• User Attributes — which attributes are sent in tokens/assertions

When using the SAP BTP Identity service (xsuaa replacement), the service instance automatically creates an OIDC application in IAS. No manual registration is needed.

Corporate IdP Federation

IAS can act as a proxy: end users authenticate at a corporate IdP (Azure AD, Okta, etc.), and IAS bridges the token for SAP applications. Configure under Applications and Resources > Corporate Identity Providers.

For details, see references/identity-authentication.md.

Identity Provisioning (IPS)

IPS synchronizes users and groups between systems. It supports source, target, and proxy system types with configurable transformations and scheduling.

Key Concepts

• Source systems — read users/groups from (e.g., SAP SuccessFactors, Azure AD, SAP S/4HANA Cloud)
• Target systems — write users/groups to (e.g., IAS tenant, SAP BTP XSUAA, SAP Analytics Cloud)
• Proxy systems — hybrid scenarios where IPS reads from one system and writes through another
• Transformations — JSON-based attribute mappings between source and target schemas
• Jobs — scheduled or on-demand provisioning runs (full or delta read)
• Real-time provisioning — immediate entity propagation from source to target

For details, see references/identity-provisioning.md.

Authorization Management (AMS)

AMS enables policy-based, instance-level authorization for BTP applications. Developers define authorization policies in Data Control Language (DCL) — an SQL-like language — and deploy them with the application. Administrators refine policies in the IAS admin console.

Policy Lifecycle

1. Developer defines policies in DCL and deploys with the application 2. Base policies appear in the IAS admin console under Authorization Policies 3. Administrator creates custom policies (copies of base) with refined restrictions 4. Administrator assigns policies to users via groups

DCL Example

DEFINE POLICY SalesOrderAccess
  AS (SELECT FROM SalesOrder
      WHERE buyer = CONTEXT('userIdentityLogonName')
      OR region = CONTEXT('userAttributes.region'));

For details, see references/authorization-management.md.

XSUAA to IAS Migration

SAP is migrating BTP authentication from XSUAA (SAP Authorization and Trust Management Service) to Cloud Identity Services. The recommended posture:

• New BTP applications: Use the Identity service (BTP service) + IAS. The Identity service automates OIDC application creation in IAS.
• Existing XSUAA applications: Coexistence is supported. Migration is incremental — SAP recommends migrating authentication to IAS while keeping XSUAA for backward compatibility.
• Authorization: SAP is replacing XSUAA scope-based authorization with AMS policy-based authorization for new applications. Existing role-collection patterns remain supported.

For the full migration guide, see references/xsuaa-to-ias-migration.md.

Trust Configuration

Trust between BTP subaccounts and IAS is established automatically when using the Identity service. For manual configurations:

• SAML 2.0: Upload SP metadata XML to the IAS application trust configuration
• OIDC: Configure redirect URIs, post-logout URIs, and client authentication

BTP Subaccount Trust

In the BTP cockpit, under Security > Trust Configuration, the IAS tenant appears after establishing the service binding. The Identity service creates the trust automatically.

For details, see references/troubleshooting.md and references/app-integration-patterns.md.

Common Errors and Solutions

Bundled Resources

1. references/identity-authentication.md — IAS app registration, OIDC/SAML configuration, corporate IdP federation, conditional authentication, user store 2. references/identity-provisioning.md — IPS source/target/proxy systems, jobs, transformations, real-time provisioning, troubleshooting 3. references/authorization-management.md — AMS policy language (DCL), policy lifecycle, CAP/BTP integration, instance-based authorization 4. references/xsuaa-to-ias-migration.md — XSUAA vs IAS decision guide, coexistence, migration steps, role-collection mapping 5. references/app-integration-patterns.md — Approuter + IAS, CAP + IAS/AMS, SAPUI5 frontends, mTLS/certificate auth for service-to-service 6. references/troubleshooting.md — Trust errors, token validation failures, audience/issuer mismatches, SAML vs OIDC pitfalls

Documentation Links

• SAP Cloud Identity Services — main documentation
• What Are Cloud Identity Services — service overview
• Operation Guide — administration console guide
• Configuring Authorization Policies — AMS administration
• Configuring Provisioning Systems — IPS setup
• Identity Service of SAP BTP — automatic IAS integration
• CAP IAS/XSUAA Guide — CAP framework integration
• SAP-docs GitHub Mirror — plain markdown documentation

SAP Cloud Identity Services — Keywords

Capability Index

Service Names

SAP Cloud Identity Services, Identity Authentication Service, IAS, Identity Provisioning Service, IPS, Identity Directory, Authorization Management Service, AMS

Protocols

OIDC, OpenID Connect, SAML 2.0, OAuth 2.0, SCIM 2.0

BTP Integration

XSUAA, Identity service, trust configuration, subaccount trust, role collections, approuter, principal propagation

AMS / Authorization

DCL, Data Control Language, authorization policies, policy-based authorization, instance-based authorization

Migration

XSUAA to IAS migration, XSUAA replacement, coexistence, Identity service adoption

Authentication

Corporate IdP federation, identity provider proxy, conditional authentication, risk-based authentication, MFA, multi-factor authentication, X.509 client certificates, SSO, single sign-on

Provisioning

User provisioning, group provisioning, identity lifecycle, source system, target system, proxy system, transformation, real-time provisioning, delta read, full read

Troubleshooting

Token validation, audience mismatch, issuer mismatch, redirect URI, trust error, 401 unauthorized, SAML assertion, OIDC token

Developer Scenarios

IAS app registration, CAP security, SAPUI5 authentication, mTLS, service-to-service authentication, approuter IAS, CAP IAS AMS

Application Integration Patterns — Complete Reference

Source: Integrating the Service with the Identity Service of SAP BTP, CAP IAS/XSUAA Guide, SAP-docs GitHub Mirror

---

Overview

This reference covers common patterns for integrating SAP Cloud Identity Services (IAS/AMS) with BTP applications, including SAPUI5 frontends, CAP backends, and service-to-service communication.

---

Pattern 1: Approuter + IAS

The SAP Application Router (approuter) handles authentication for SAPUI5/Fiori applications. With IAS, the approuter delegates authentication to IAS via the Identity service.

Architecture

Browser → Approuter → IAS (OIDC auth)
                     ↓
              Backend service (CAP/Java/Node.js)

Configuration

1. Create an Identity service instance:

   cf create-service identity application my-identity -c config.json

2. Bind to the approuter:

   cf bind-service my-approuter my-identity

3. The approuter automatically:

• Redirects unauthenticated users to IAS login
• Handles the OIDC callback
• Stores the JWT token in the session
• Propagates the user identity to backend services

xs-app.json (approuter configuration)

{
  "authenticationMethod": "route",
  "routes": [
    {
      "source": "^/api/(.*)$",
      "target": "$1",
      "destination": "backend-service",
      "authenticationType": "xsuaa"
    },
    {
      "source": "^(.*)$",
      "target": "$1",
      "authenticationType": "xsuaa"
    }
  ]
}

When using the Identity service, authenticationType: "xsuaa" works because the Identity service is backward-compatible with XSUAA token format in the approuter.

---

Pattern 2: CAP + IAS/AMS

CAP applications integrate with IAS through the Identity service binding. CAP automatically handles token validation and user context.

Node.js CAP Setup

1. Create an Identity service instance (see Pattern 1) 2. Bind it to the CAP application 3. CAP reads the binding and configures authentication

CAP uses the @restrict annotation for authorization:

using { cuid, managed } from '@sap/cds/common';

entity Books {
  key ID : Integer;
  title  : String;
  @restrict: [
    { grant: ['READ'], where: 'createdBy = $user' }
  ]
}

CAP with AMS Policies

When deploying with AMS support, CAP converts @restrict annotations to DCL policies:

1. The @restrict → DCL conversion happens at build time 2. DCL policies are deployed alongside the application 3. Policies appear in the IAS admin console for refinement 4. Administrators assign policies to users/groups

Java CAP Setup

For Java CAP applications, configure the Identity service in application.yaml:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://<tenant>.accounts.ondemand.com

Bind the Identity service instance to the Java application deployed on SAP BTP.

Source: [CAP IAS/XSUAA Guide](https://cap.cloud.sap/docs/guides/integration/platform/ias-xsuaa)

---

Pattern 3: SAPUI5 Frontend + IAS

SAPUI5 applications authenticate through the approuter, which handles the IAS OIDC flow. The SAPUI5 app receives the user context from the approuter session.

Key Considerations

• User info: Access via sap.ushell.Container.getService("UserInfo") in Fiori Launchpad
• CSRF token: Fetch from the backend service endpoint before POST/PUT/DELETE requests
• Token refresh: The approuter handles token refresh automatically
• Logout: Use the approuter's /do/logout endpoint

SAPUI5 Manifest Configuration

Ensure the app communicates through the approuter (relative paths), not directly to IAS:

{
  "sap.app": {
    "dataSources": {
      "mainService": {
        "uri": "/api/v2/catalog/",
        "type": "OData"
      }
    }
  }
}

---

Pattern 4: mTLS / Certificate-Based Service-to-Service

For service-to-service authentication where no user context is needed, use X.509 client certificates with the Identity service.

Creating a Certificate Binding

cf create-service-key my-identity my-key -c '{
  "certificate-type": "X.509",
  "key-length": 2048
}'

Or provide an existing certificate when binding:

cf bind-service myapp my-identity -c '{
  "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
  "key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----"
}'

Using Certificate Authentication

The binding provides:

• clientid — the OAuth client ID
• certificate — the X.509 certificate
• key — the private key
• url — the token endpoint (IAS)
• certurl — certificate-based token endpoint

Use the certificate to obtain an access token:

curl --cert client.crt --key client.key \
  -X POST "https://<tenant>.accounts.ondemand.com/oauth2/token" \
  -d "grant_type=client_credentials&client_id=<clientid>"

Use Cases

• Backend microservices calling other services
• Cron jobs accessing BTP services
• Automated pipelines deploying to BTP
• Service mesh authentication

---

Pattern 5: Principal Propagation with IAS

When a BTP application needs to call a backend system on behalf of the logged-in user:

1. The approuter provides the user's JWT token 2. The application exchanges the JWT token for a token accepted by the backend 3. Use the SAP Connectivity service for on-premise backends (via Cloud Connector)

The Identity service supports principal propagation through:

• OAuth2JWTBearer authentication in destination service
• OAuth2UserTokenExchange for token exchange flows
• The approuter handles user token propagation automatically

For detailed connectivity configuration, see the sap-btp-connectivity skill.

---

Pattern 6: Multi-Tenant SaaS with IAS

For multi-tenant SaaS applications on SAP BTP:

1. Each subscriber gets their own IAS tenant (or uses their existing corporate IdP) 2. The SaaS application uses the Identity service with tenant-aware bindings 3. Trust is established between the subscriber's IAS tenant and the provider subaccount 4. AMS policies can be customized per subscriber

Key configuration:

• Provider account: Identity service instance with application plan
• Subscriber account: IAS tenant linked to the provider's application
• User assignment: Via IAS admin console or SCIM API

Source: [SAP-samples BTP CAP Multitenant SaaS](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/docu/3-advanced/2-central-user-management-ias/README.md)

Authorization Management (AMS) — Complete Reference

Source: Configuring Authorization Policies, Data Control Language (DCL), Developing Authorizations

---

Overview

Authorization Management (AMS) enables policy-based, instance-level authorization for SAP BTP applications. Unlike traditional scope-based authorization (XSUAA), AMS uses policies defined in Data Control Language (DCL) — an SQL-like language — to express fine-grained access rules based on user attributes, business object attributes, and context.

---

Policy Lifecycle

---

Data Control Language (DCL)

DCL is an SQL-like language for defining authorization policies. Developers write DCL as part of the application and deploy it alongside the business logic.

Policy Structure

A DCL policy consists of:

• Policy name — unique identifier within the package
• Rules — USE rules define which operations are permitted
• Restrictions — WHERE clauses filter accessible data based on conditions
• Attributes — user attributes, business object attributes, or fixed values

DCL Syntax

DEFINE POLICY <policy-name>
  AS (SELECT FROM <entity>
      WHERE <condition>);

Example: Sales Order Access

DEFINE POLICY SalesOrderPolicy
  AS (SELECT FROM Sales.Orders
      WHERE buyer = CONTEXT('userIdentityLogonName'));

This policy restricts access to only the sales orders where the buyer matches the logged-in user.

Example: Regional Access with Role

DEFINE POLICY RegionalAccess
  AS (SELECT FROM Customers
      WHERE region = CONTEXT('userAttributes.region')
        AND CONTEXT('userGroups') HAS 'SalesTeam');

Context Functions

---

Policy Types

Base Authorization Policy

Delivered with the application by the developer. Cannot be modified or deleted by administrators. Administrators can copy it to create a custom policy.

Custom Authorization Policy

Created by administrators in the IAS admin console. Can be modified and deleted. Created by copying a base policy or combining multiple policies.

Package Naming

• Application-defined packages — named by the application, contain base policies
• Customer Package — customer-developed policies created in the admin console

---

Configuration Options

Administrators can:

• Combine policies — merge rules from multiple policies into a new one
• Add/delete rules — modify which operations a policy covers
• Restrict rules — add WHERE conditions to existing rules
• Manage attribute values — set fixed values or map to user attributes
• Assign policies to users — directly or via groups

Assigning Policies to Users

1. In IAS admin console, go to Authorization Policies 2. Select the policy 3. Choose Assign > Add Users or Add Groups 4. Search and select users/groups from the Identity Directory 5. Save

Alternatively, use the SCIM API of the Identity Directory to assign groups that have policies attached.

Source: [Assign Authorization Policies](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/assign-authorization-policies)

---

CAP Integration

CAP (Cloud Application Programming Model) supports AMS authorization policies. The integration flow:

1. Define Policies in CDS

CAP applications can define authorization requirements using @restrict annotations in CDS:

entity Orders {
  @restrict: [
    { grant: ['READ'], where: 'buyer = $user' }
  ]
  ...
}

CAP compiles these into DCL policies when deploying with AMS support.

2. Enable AMS in CAP

In cds-security.json or via the Identity service binding:

• Use the Identity service (IAS-based) instead of XSUAA
• Enable AMS policy deployment
• CAP automatically generates DCL from @restrict annotations

3. Deploy

CAP deploys the application with generated DCL policies to SAP BTP. The policies appear in the IAS admin console.

Source: [CAP IAS/XSUAA Guide](https://cap.cloud.sap/docs/guides/integration/platform/ias-xsuaa)

---

AMS vs XSUAA Authorization

---

Administration Console Navigation

Access authorization policies in the IAS admin console:

1. Sign in to https://<tenant>.accounts.ondemand.com/admin 2. Navigate to Applications & Resources > Authorization Policies 3. Filter by application or package 4. Select a policy to view rules, restrictions, and assignments

From this view, administrators can:

• Create custom policies (copy from base)
• Combine policies
• Edit restrictions and attribute values
• Assign/unassign users and groups
• Delete custom policies

Source: [Configuring Authorization Policies](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/configuring-authorization-policies)

Identity Authentication (IAS) — Complete Reference

Source: SAP Cloud Identity Services Operation Guide, SAP-docs GitHub Mirror

---

Overview

Identity Authentication (IAS) is the cloud-based identity provider for SAP BTP applications. It handles user authentication, single sign-on, corporate IdP federation, and user store management. IAS supports both OIDC and SAML 2.0 protocols.

---

Application Registration

Creating an Application

1. Sign in to the IAS administration console at https://<tenant>.accounts.ondemand.com/admin 2. Navigate to Applications & Resources > Applications 3. Choose Create Application 4. Enter a Display Name and optional description 5. Choose the Application Type:

• OIDC — for modern web/mobile apps, SAP BTP applications using the Identity service
• SAML 2.0 — for legacy integrations, SAP cloud solutions that use SAML assertions

6. Configure trust (see below) 7. Save

Source: [Configuring Applications](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/configuring-applications)

OIDC Application Configuration

For OIDC applications, configure:

SAML 2.0 Application Configuration

For SAML applications:

1. Upload SP metadata — the service provider's SAML metadata XML, or enter the entity ID and assertion consumer service URL manually 2. Configure Name ID Format — typically email or persistent 3. Set signing — choose whether IAS signs assertions 4. Configure user attributes — which attributes are sent in the assertion

Identity Service Auto-Registration

When using the SAP BTP Identity service (replacing XSUAA), no manual IAS registration is needed. The process:

1. Create an Identity service instance in BTP:

   cf create-service identity application my-identity-service

2. Bind it to the application:

   cf bind-service myapp my-identity-service

3. The Identity service automatically creates an OIDC application in the IAS tenant linked to the subaccount

Each Identity service instance gets its own OAuth client with unique credentials (client ID + secret or X.509 certificate).

Source: [Integrating the Service with the Identity Service of SAP BTP](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/integrating-service-with-identity-service-of-sap-btp)

---

Corporate Identity Provider Federation

IAS can delegate authentication to a corporate identity provider (IdP). IAS acts as a proxy between the application and the corporate IdP.

Supported IdP Types

• SAML 2.0 corporate IdPs (Azure AD, Okta, OneLogin, etc.)
• OIDC identity providers
• Social identity providers (Google, Facebook, LinkedIn, Apple)
• Custom IdPs via the IdP API

Configuring a SAML 2.0 Corporate IdP

1. In the IAS admin console, go to Applications & Resources > Corporate Identity Providers 2. Choose Add Corporate IdP > SAML 2.0 3. Upload the corporate IdP's SAML metadata XML 4. Configure the binding (HTTP Redirect, HTTP POST) 5. Set up name ID format and user attribute mappings 6. Optionally configure conditional authentication rules (see below)

Source: [Configure Trust with SAML 2.0 Corporate Identity Provider](https://github.com/SAP-docs/btp-cloud-identity-services/blob/main/docs/Operation-Guide/configure-trust-with-saml-2-0-corporate-identity-provider-33832e5.md)

Conditional Authentication

Conditional authentication routes users to different IdPs based on conditions:

Configure per-application: Application > Authentication > Conditional Authentication.

---

User Store

IAS supports multiple user store options:

• Identity Directory — the default user store, part of SAP Cloud Identity Services. Provides SCIM 2.0 API, custom schemas, and the Global User ID.
• Corporate user stores — via IdP federation, users from Azure AD, SAP SuccessFactors, etc.
• Local user store — users created directly in IAS (registration, invite, CSV import)

SCIM 2.0 API

The Identity Directory SCIM 2.0 API enables programmatic user management:

GET  /service/scim/Users              — List users
GET  /service/scim/Users/{id}         — Get user
POST /service/scim/Users              — Create user
PUT  /service/scim/Users/{id}         — Update user
DELETE /service/scim/Users/{id}       — Delete user
PATCH /service/scim/Users/{id}        — Partial update

Custom schemas can extend the user model with additional attributes.

---

Authentication Methods

IAS supports multiple authentication methods, configurable per application:

---

Tenant Model

IAS tenants are deployed on productive domains:

• accounts.ondemand.com
• accounts.cloud.sap

Tenants are obtained either:

• Bundled — with an SAP cloud solution (e.g., SAP SuccessFactors, SAP S/4HANA Cloud)
• Self-service — via SAP BTP cockpit, creating a Cloud Identity Services tenant

Regional availability spans AWS, Azure, Google Cloud, and Alibaba Cloud infrastructure.

Source: [What Are Cloud Identity Services](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/what-is-identity-authentication)

Identity Provisioning (IPS) — Complete Reference

Source: Configuring Provisioning Systems, SAP Cloud Identity Services Operation Guide

---

Overview

Identity Provisioning (IPS) synchronizes users and groups between SAP and non-SAP systems. It supports source, target, and proxy system types, with configurable transformations, scheduling, and real-time provisioning.

---

System Types

Source Systems

Source systems read entities (users, groups, roles) from an identity provider. Supported source systems include:

• SAP SuccessFactors
• SAP S/4HANA Cloud
• SAP Analytics Cloud
• SAP BTP (XSUAA/IAS)
• Microsoft Entra ID (Azure AD)
• Okta
• LDAP directories
• SAP Identity Management 8.0
• Custom SCIM systems

Target Systems

Target systems write entities to an identity consumer. Supported target systems include:

• SAP Cloud Identity Services (IAS tenant)
• SAP BTP XSUAA subaccounts
• SAP Analytics Cloud
• SAP SuccessFactors
• SAP S/4HANA Cloud
• Microsoft Entra ID
• Custom SCIM systems

Proxy Systems

Proxy systems enable hybrid scenarios where IPS reads from one system and writes through another. Use cases:

• On-premise system connectivity through Cloud Connector
• Multi-hop provisioning chains

---

Configuration

Adding a System

1. Sign in to the IAS administration console 2. Navigate to Identity Provisioning section 3. Choose Add System 4. Select system type (Source, Target, or Proxy) 5. Choose the connector (e.g., SAP SuccessFactors, Azure AD) 6. Configure properties (host URL, authentication, credentials) 7. Optionally configure transformations 8. Save

System Properties

Each system has key-value properties that control behavior:

Source: [Manage Properties](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/manage-properties)

Transformations

Transformations map attributes between source and target schemas. IPS provides a graphical editor and a JSON text editor.

Transformation example (simplified):

{
  "user": {
    "mappings": [
      {
        "sourcePath": "$.userName",
        "targetPath": "$.userName"
      },
      {
        "sourcePath": "$.name.givenName",
        "targetPath": "$.name.givenName"
      },
      {
        "sourcePath": "$.emails[0].value",
        "targetPath": "$.emails[0].value"
      },
      {
        "constant": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
        "targetPath": "$.schemas[1]"
      }
    ]
  }
}

Source: [Manage Transformations](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/manage-transformations)

---

Provisioning Jobs

Full Read

The default mode. Reads all entities from the source and syncs to the target. Prevents data loss but may be slow for large systems.

Delta Read

Reads only changed entities since the last run. Faster but requires source system support for change tracking.

Starting a Job

Jobs can be started:

• Manually — from the IPS admin console or via API
• Scheduled — configured as recurring jobs

API example:

POST /ips/rest/v1/tenants/{tenantId}/jobs/run
{
  "sourceSystemId": "source-id",
  "targetSystemId": "target-id",
  "readMode": "FULL"
}

Source: [Start and Stop Provisioning Jobs](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/start-and-stop-provisioning-jobs)

---

Real-Time Provisioning

Real-time provisioning immediately propagates entity changes from source to target without waiting for a scheduled job.

Enable per-source system in the IPS admin console under the system's real-time provisioning settings.

Requirements:

• Source system must support change notifications
• The Identity Directory must be configured as a target

Source: [Configuring Real-Time Provisioning](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/real-time-provisioning)

---

Deleted Entity Management

IPS handles entity deletion with configurable behavior:

• Delete in target — when an entity is deleted from the source, it is deleted from the target
• Deactivate in target — entity is deactivated rather than deleted
• Ignore — source deletions are not propagated

Configure via system properties or the Manage Deleted Entities option in the console.

---

Certificates

IPS supports certificate-based authentication for secure communication with provisioning systems. Manage certificates in the IPS admin console:

• Upload X.509 certificates for systems requiring mutual TLS
• Configure certificate rotation
• Monitor certificate expiration

Source: [Manage Certificates](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/manage-certificates)

---

Troubleshooting Provisioning

Source: [Handle Failed Operations](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/handle-failed-operations)

Troubleshooting — Complete Reference

Source: Monitoring and Troubleshooting, Getting Support, Configure Trust

---

Trust Configuration Errors

Error: "No trusted identity provider found"

Symptoms: Users see "No trusted identity provider found for the given request" when accessing an application.

Causes: 1. The application's trust configuration is missing or incomplete 2. The BTP subaccount has no trust to the IAS tenant 3. The IAS application doesn't have the correct SP metadata or redirect URIs

Solutions: 1. In IAS admin console, verify the application exists under Applications & Resources > Applications 2. Check the trust configuration:

• For SAML: Verify SP metadata is uploaded correctly
• For OIDC: Verify redirect URIs match the application callback URL exactly

3. In BTP cockpit, go to Security > Trust Configuration and verify the IAS tenant is listed 4. If using the Identity service, rebind the service instance:

   cf unbind-service myapp my-identity
   cf bind-service myapp my-identity
   cf restage myapp

Error: "SAML assertion validation failed"

Symptoms: SAML assertion rejected by the service provider.

Causes: 1. Clock drift between IAS and the service provider 2. Assertion expired (default lifetime is short) 3. Signing certificate mismatch

Solutions: 1. Verify system clocks are synchronized (NTP) 2. In IAS admin console, check assertion lifetime settings under the application's SAML configuration 3. Verify the IAS signing certificate matches what the SP expects:

• Download IAS signing certificate from Applications & Resources > Tenant Settings > SAML 2.0 Configuration
• Upload to the service provider's trusted IdP certificates

---

Token Validation Failures

Error: "Invalid token" or "401 Unauthorized"

Symptoms: Backend service rejects the JWT token.

Diagnosis steps: 1. Decode the JWT token (use jwt.io or base64 decode the payload) 2. Check the following claims:

Error: "Audience mismatch"

Symptoms: Token aud claim doesn't include the expected client ID.

Causes: 1. The application uses a different client ID than what's in the token 2. Migration from XSUAA to Identity service changed the client ID 3. The token was issued for a different IAS application

Solutions: 1. Verify the binding credentials:

   cf env myapp
   # Check the clientid in VCAP_SERVICES

2. Ensure the backend service validates against the correct audience 3. If using multiple IAS applications, ensure the correct one is configured

Error: "Issuer mismatch"

Symptoms: Token iss claim doesn't match the expected issuer URL.

Causes: 1. Migration from XSUAA to IAS changed the issuer URL 2. Wrong IAS tenant is configured 3. Custom domain configuration changes the issuer

Solutions: 1. Update the application's expected issuer to match IAS:

• XSUAA issuer: https://<subdomain>.authentication.<region>.hana.ondemand.com/oauth/token
• IAS issuer: https://<tenant>.accounts.ondemand.com

2. During migration, support both issuers during the transition period 3. Check the Identity service binding credentials for the correct issuer URL

---

Redirect URI Errors

Error: "Invalid redirect URI" or "redirect_uri_mismatch"

Symptoms: After authentication, users see an error instead of being redirected back to the application.

Causes: 1. The redirect URI in the IAS application doesn't match the callback URL 2. Missing trailing slash or different protocol (http vs https) 3. Port number mismatch

Solutions: 1. In IAS admin console, go to the application > Trust > Redirect URIs 2. Add all valid redirect URIs:

   https://myapp.cfapps.eu10.hana.ondemand.com/login/callback
   https://myapp.cfapps.eu10.hana.ondemand.com/

3. Ensure exact match including protocol, host, path, and trailing slashes 4. For the Identity service, configure redirect URIs in the service instance config

---

Missing Role Collections

Error: User has no access despite correct authentication

Symptoms: User authenticates successfully but gets 403 Forbidden on protected resources.

Causes: 1. Role collections not assigned to the user 2. Role templates not mapped correctly (XSUAA migration issue) 3. AMS policies not assigned to the user's group

Solutions: 1. In BTP cockpit, go to Security > Role Collections 2. Verify the user has the required role collection assigned 3. For AMS, check the IAS admin console > Authorization Policies for policy assignments 4. Check user group membership in the Identity Directory

---

SAML vs OIDC Pitfalls

SAML-Specific Issues

OIDC-Specific Issues

---

Provisioning Troubleshooting

Provisioning Job Stuck or Failed

1. Check job logs in IPS admin console 2. Verify source/target system connectivity 3. Check for rate limits (configure ips.max.retry.count) 4. Review transformation logs for mapping errors 5. Enable ips.trace.failed.entity.requests for detailed failure logging

Users Not Syncing

1. Verify the source system filter (ips.sql.condition) isn't too restrictive 2. Check transformation mappings for required attributes 3. Ensure the target system's SCIM endpoint is accessible 4. Verify delta read is supported by the source system

---

Diagnostic Tools

IAS Admin Console

• Monitoring > Audit Logs: Authentication events, configuration changes
• Monitoring > Usage Statistics: Login metrics, application usage
• Applications > [App] > Authentication: View authentication methods and logs

BTP Cockpit

• Security > Trust Configuration: Verify IdP trust
• Security > Role Collections: Verify role assignments
• Instances and Subscriptions: Verify service bindings

Token Inspection

Decode JWT tokens to verify claims:

# Decode token payload
echo "<token-payload>" | base64 -d | jq .

Key claims to verify:

• iss, aud, sub, exp, iat
• scope, xs.user.attributes (XSUAA), user_attributes (IAS)
• tenant (for multi-tenant apps)

Source: [Getting Support](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/getting-support)

XSUAA to IAS Migration — Complete Reference

Source: SAP Help Portal - Migration of Authentication from XSUAA to IAS, CAP IAS/XSUAA Guide, SAP Community - Cloud Identity Services

---

Overview

SAP is migrating SAP BTP authentication from XSUAA (SAP Authorization and Trust Management Service) to Cloud Identity Services (IAS). This is a strategic shift that enables new capabilities like Joule (SAP's AI assistant), centralized identity management, and policy-based authorization (AMS).

---

Current SAP Recommendation

For New Applications

• Use the Identity service of SAP BTP (not XSUAA)
• The Identity service automatically creates OIDC applications in IAS
• Use AMS for authorization (policy-based) instead of XSUAA scopes
• Configure via BTP cockpit: create an identity service instance instead of xsuaa

For Existing XSUAA Applications

• Coexistence is supported — XSUAA and IAS can work side by side
• Migration is incremental — not a big-bang switch
• SAP recommends migrating authentication to IAS while keeping XSUAA for backward compatibility during transition
• Existing xs-security.json role templates remain functional

Source: [SAP Community Q1 2026 Release Highlights](https://pages.community.sap.com/topics/cloud-identity-services), [adesso blog on SAP IAM strategy](https://blog.adesso-bc.com/saps-new-identity-and-access-management-strategy/)

---

Key Differences

---

Migration Steps

Phase 1: Establish IAS Tenant

1. Obtain an IAS tenant (bundled with SAP cloud solution or self-service via BTP cockpit) 2. Configure the IAS tenant:

• Set up corporate IdP federation if needed
• Configure conditional authentication
• Set up user store (Identity Directory)

Phase 2: Create Identity Service Instance

Replace the XSUAA service instance with an Identity service instance:

# Old (XSUAA)
cf create-service xsuaa application my-xsuaa -c xs-security.json

# New (Identity service)
cf create-service identity application my-identity -c identity-config.json

The identity-config.json:

{
  "display-name": "My Application",
  "redirect-uris": ["https://myapp.cfapps.eu10.hana.ondemand.com/login/callback"],
  "post-logout-redirect-uris": ["https://myapp.cfapps.eu10.hana.ondemand.com"]
}

Phase 3: Update Application Binding

# Unbind old XSUAA
cf unbind-service myapp my-xsuaa

# Bind new Identity service
cf bind-service myapp my-identity

# Restage
cf restage myapp

Phase 4: Update Application Code

Key changes in application code:

1. Token validation: Update expected issuer and audience from XSUAA to IAS 2. User attribute access: Map from UAA claims to OIDC standard claims 3. Role checking: Transition from XSUAA scopes to role collections or AMS policies 4. Approuter configuration: Update authentication configuration to use the Identity service

Phase 5: Migrate Authorization (if using AMS)

1. Define AMS policies in DCL based on existing @restrict annotations 2. Deploy policies with the application 3. Assign policies to users via IAS admin console 4. Verify authorization behavior matches XSUAA role collections

Phase 6: Validate and Cut Over

1. Test all authentication flows (login, SSO, SLO, token refresh) 2. Verify user attributes are correctly mapped 3. Confirm role/authorization assignments work 4. Monitor for token validation errors 5. Remove XSUAA service instance once stable

---

Coexistence

During migration, XSUAA and IAS can coexist:

• Applications can accept tokens from both XSUAA and IAS
• Role collections in BTP cockpit can include roles from both services
• Users can authenticate via either path
• Use the IAS trust configuration alongside the existing sap.default trust

---

Role Collection Mapping

XSUAA role templates map to IAS authorization policies:

---

Common Migration Issues

---

SAP BTP Samples

The SAP-samples repository provides a reference implementation for IAS integration in a CAP multitenant SaaS application:

• Central user management using SAP IAS

This sample demonstrates:

• Creating an IAS instance from BTP cockpit
• Configuring trust between BTP subaccount and IAS
• User onboarding via IPS
• Application authentication with IAS