Setting Up SAP Joule With IAS — What You Need To Know

Why Identity Matters for Joule

SAP Joule is not a standalone assistant — it reaches across S/4HANA, SuccessFactors, and other SAP solutions to fetch data and execute actions on your behalf. That cross-application nature makes identity management the most critical prerequisite to get right before going live. Get it wrong, and Joule either fails silently or returns the wrong data for the wrong user.

The Non-Negotiables

Before any Joule configuration begins, five prerequisites are mandatory:

SAP Joule must be integrated with SAP Identity Authentication Service (IAS). Joule relies on the existing IAS setup for user login — it cannot operate with a direct corporate IdP connection bypassing IAS.
Joule and all SAP products integrated with Joule must use the same SAP Cloud Identity Services tenant. Mixing tenants breaks cross-system user resolution entirely.
Both the Joule application and every SAP Solution application in IAS must have the same user store set in conditional authentication. A mismatch here causes inconsistent identity resolution between Joule and the back-end systems it calls.
All solutions embedding Joule must use the same IAS tenant domain — either cloud.sap or ondemand.com. Mixing domains across integrated products is not supported.
Across all integrated applications, users must be represented consistently using the Global User ID. This is the only identity Joule can reliably use to link a user across S/4HANA, SuccessFactors, BTP, and Work Zone.

Note: IAS cannot be used in proxy mode for Joule. All users must be fully replicated into the IAS Identity Directory. A proxy-only setup will not work.

The Global User ID — The Linchpin

In a typical enterprise landscape, the same person may exist as john.doe in S/4HANA, jdoe@company.com in SuccessFactors, and JD-001 in a legacy system. Without a common identifier, Joule has no way to link these together and determine what the user is authorised to access.

The Global User ID is a persistent UUID automatically generated when a user is created in SAP Cloud Identity Services — Identity Directory. It is the single identifier that ties one person across all SAP applications.

What breaks without it: Joule's token exchange with back-end systems fails — the BTP Destination Service cannot map the Joule user to the correct back-end identity. Role-based content visibility in SAP Build Work Zone also breaks — Joule Functions only appear for users whose identity can be fully resolved.

Once created in Identity Directory, the Global User ID is provisioned to all connected systems via the Identity Provisioning Service (IPS) using SCIM 2.0, keeping every user store in sync automatically.

Universal IAS Application Settings

The following Subject Name Identifier (SNI) configurations must be set regardless of your identity provider setup. These are configured under:

Cloud Identity Services → Applications → Bundled Applications

Joule Application (das-ias <subaccount name>) — SNI Configuration
Navigate to the Joule bundled application in IAS and set the Subject Name Identifier as follows:

Source:Identity Directory | Value:Global User ID

This ensures every token issued to Joule carries the Global User ID as the user's identifier — not an email address or login name from the corporate IdP.

SAP Build Work Zone Application — SNI Configuration
The same SNI setting must be applied to the Work Zone application in IAS:

Source:Identity Directory | Value:Global User ID

Work Zone uses this identifier to validate which Joule Functions a user is authorised to see. If the SNI here differs from Joule's, the user's role assignments cannot be resolved and Joule content will not appear.

Why both applications must be aligned: Joule and Work Zone work together to resolve what a user can access. If their SNI configurations differ — for example, Joule uses Global User ID but Work Zone uses email — the Navigation Service cannot match the identities and the Joule session breaks. Both must point to Global User ID from Identity Directory.

How Your Identity Provider Setup Determines What Comes Next

The configuration steps from this point depend on how your organization authenticates users into SAP applications. There are two common setups:

In the first, SAP IAS is your primary identity provider — users log in directly through IAS, with no external corporate IdP involved. Authentication begins and ends within IAS, and the configuration is relatively straightforward.

In the second, a corporate IdP such as Azure AD or Okta is your primary identity provider. IAS does not authenticate the user directly but acts as a broker — receiving the assertion from your corporate IdP, looking up the user in Identity Directory, and issuing a token enriched with SAP-specific attributes including the Global User ID.

Both paths lead to the same outcome: a Joule session backed by a correctly resolved Global User ID. The steps to get there differ, which is why they are covered separately below.

Scenario 1

SAP IAS is Your Primary Identity Provider

This is the simpler of the two scenarios. Users authenticate directly against SAP IAS — no external corporate IdP is involved. Authentication begins and ends within IAS, making it the authoritative source for all user attributes including the Global User ID.

The IAS application for Joule (das-ias <subaccount name>) governs all Joule-specific settings, and each BTP subaccount can maintain its own independent Joule configuration.

Conditional Authentication

This is the most critical alignment requirement in this scenario. The conditional authentication setting — which defines where users are directed to log in — must be set to Identity Authentication for both:

The Joule application (das-ias <subaccount name>) in IAS
Every connected SAP solution (e.g. S/4HANA, SuccessFactors) in IAS

Why alignment matters: If Joule and a connected solution point to different user stores or authentication sources in conditional authentication, the user identities they see will differ. This breaks Joule's ability to call back-end systems on behalf of the user.

Identity Federation

Not applicable in this scenario: Identity Federation settings are only relevant when a corporate IdP is involved. Since IAS is the primary and only identity provider here, there is no federation layer to configure. This section does not appear in the IAS application settings for this scenario.

Subject Name Identifier for Connected Solutions

While the Joule and Work Zone applications must use Global User ID as the SNI (configured in the Universal Settings section above), the SNI for connected SAP solutions such as S/4HANA or SuccessFactors should be set as per the guidance from the respective Line of Business (LOB) product documentation.

Check with the product team: Each SAP solution may have specific requirements for the SNI value it expects. Always refer to the setup guide for that solution (e.g. SAP S/4HANA integration guide for Joule) to confirm the correct SNI configuration before going live.

Other Key Settings to Verify

Ensure the Global User ID is enabled and populated for all users in Identity Directory.
Identity Provisioning must sync users — including the Global User ID — to all connected SAP solutions via SCIM 2.0.

Scenario 2

A Corporate IdP (Azure AD, Okta, etc.) is Your Primary Identity Provider

This is the more common enterprise scenario. IAS acts as a broker between your corporate IdP and SAP applications — it does not authenticate the user directly but orchestrates the flow.

User → SAP Joule → IAS → Corporate IdP → back to IAS → token issued to Joule

Conditional Authentication

The conditional authentication setting must be set to the same corporate IdP (e.g. Azure AD) for both:

The Joule application (das-ias <subaccount name>) in IAS
Every connected SAP solution (e.g. S/4HANA, SuccessFactors) in IAS

Critical — must be the same corporate IdP across all applications: If Joule uses Azure AD but a connected solution uses a different IdP or falls back to IAS directly, the authentication context will not match. This will cause the token exchange between Joule and the back-end system to fail. All applications in scope must point to the identical corporate IdP entry in IAS.

Identity Federation — Application Level

Identity Federation settings can be configured at the application level (custom per application) or set to inherit from the corporate IdP level. For most customers, inheriting from the corporate IdP level is the recommended approach — it reduces duplication and ensures consistent behaviour across all applications. Set this to “Corporate IdP” at the application level unless you have a specific per-application requirement.

If you choose to configure custom application-level Identity Federation, the following settings apply:

Use Identity Authentication User Store — Must be enabled.
After the corporate IdP authenticates the user, it sends an assertion back to IAS with a Subject Name Identifier (SNI). IAS uses this SNI to look up the user in Identity Directory. Enabling this ensures the token issued to Joule carries IAS attributes — including the Global User ID — rather than raw corporate IdP attributes. Without this, the Global User ID does not reach Joule.
Allow Identity Authentication Users Only — Should be enabled.
If the SNI from the corporate IdP cannot be matched to a user in IAS, this setting determines the outcome. If disabled, login may succeed but the token carries corporate IdP attributes only — no Global User ID — causing silent failures when Joule calls back-end systems. Enabling this forces an explicit login failure, which is far easier to diagnose and resolve.
Apply Application Configurations — Joule has no specific requirement.
Enable only if your organisation requires Risk-Based Authentication, Terms of Use, Privacy Policy enforcement, or custom registration forms for this application.

Prerequisite before enabling these settings: Ensure all users are fully synced from the corporate IdP to IAS Identity Directory via Identity Provisioning before Joule goes live. With all user records in place, enabling both Use IAS User Store and Allow IAS Users Only is safe and correct.

Identity Federation — Corporate IdP Level

Settings configured at the corporate IdP level in IAS apply to all applications that reference that IdP, unless overridden at the application level. The same three settings exist here:

Use Identity Authentication User Store — Should be enabled at the IdP level so all applications consistently look up users in IAS Identity Directory.
Allow Identity Authentication Users Only — Should be enabled at the IdP level to enforce consistent behaviour across all applications without requiring per-app configuration.
Forward All SSO Requests to Corporate IdP — Joule does not require this. Leave it disabled unless there is a specific policy reason. Enabling it forces IAS to redirect every request to the corporate IdP regardless of existing sessions, adding latency and potential redirect loops.

Subject Name Identifier at the Corporate IdP Level

The corporate IdP must issue an SNI in its assertion that uniquely identifies the user in IAS — matching the user's Email, Login Name, or User ID in the IAS user store. This is what allows IAS to look up the correct user record and attach the Global User ID to the token.

For connected solutions (S/4HANA, SuccessFactors, etc.), the SNI should be set as per guidance from the respective LOB product documentation — just as in Scenario 1.

Silent failure scenario to avoidIf the SNI mapping is misconfigured and Allow IAS Users Only is disabled, authentication succeeds silently — but Joule receives the corporate IdP's email as the identifier instead of the Global User ID. Everything appears to work until Joule calls a back-end system and the token exchange fails.

Summary Comparison

The Bottom Line

Whether your organization uses SAP IAS directly or federates through a corporate IdP, the Global User ID is the non-negotiable foundation for Joule. Every configuration decision in IAS — from Identity Federation to SNI mapping — ultimately exists to ensure that one UUID travels correctly from the user's identity all the way to the back-end system Joule is calling.

Get the Global User ID flowing consistently, and the rest of the Joule setup falls into place.

Source link