Syensqo Identity Architecture — SAP Tooling Overview

1) Purpose

Provide a clear architectural overview of the SAP tools that enable identity and access management (IAM) across Syensqo’s cloud and on‑premise applications.

2) Scope

• SAP identity governance and provisioning across cloud and on‑premise systems

• Standard joiner/mover/leaver (JML) processes and access request governance

• Risk and Segregation of Duties (SoD) control framework

• Periodic access certifications

• Connectivity, security, and operations considerations for the above

3) Guiding Principles

• Cloud‑first: Prefer SAP SaaS services on SAP Business Technology Platform (BTP).

• Single source of identity: SuccessFactors as the workforce truth; Cloud Identity Services as the identity broker.

• Business‑role model: Assign access through business roles; avoid direct technical role assignment.

• Least privilege with controls: SoD, risk analysis, and periodic certifications are built‑in gates.

• Standards‑based integration: Use SCIM and established SAP connectors wherever possible.

• Environment isolation: Strict separation (DEV/TEST/PROD) for predictable promotion and auditability.

4) Landscape Overview

At the center is SAP Cloud Identity Access Governance (IAG), delivered as a SaaS tenant on SAP BTP. IAG integrates with SAP Cloud Identity Services (CIS)—notably Identity Authentication Service (IAS), Identity Provisioning Service (IPS), and Identity Directory—to authenticate users, propagate identity data, and orchestrate provisioning to target applications.

5) Core Services (Responsibilities)

5.1 SAP Cloud Identity Access Governance (IAG)

• Access Request & Workflow: Central entry point for requesting and approving access for R2 Release. For future releases this will change to automated triggers from SuccessFactors for business roles.

• Access Risk Analysis: Built‑in SoD and critical‑access checks before and after assignment.

• Role Design: Business‑role centric design aligned to functions and processes.

• Privileged Access: Controlled elevation for critical activities (emergency access).

• Access Certification: Campaign‑based periodic reviews for ongoing entitlement validation.

• Audit & Reporting: End‑to‑end traceability of requests, approvals, and provisioning events.

5.2 SAP Cloud Identity Services (CIS)

• Identity Authentication Service (IAS): SSO and authentication. Federates to Microsoft Entra ID; supports risk‑based and MFA policies.

• Identity Provisioning Service (IPS): Orchestrates identity and role provisioning between sources (e.g., SuccessFactors) and targets (e.g., IAG, Ariba, SAC).

• Identity Directory: Central store for user and group objects used by IAS/IPS and downstream systems.

5.3 SAP BTP Connectivity & Cloud Connector (SCC)

• Connectivity Service (BTP): Managed egress from IAG to enterprise networks.

• SAP Cloud Connector (SCC): Secure reverse tunnel from on‑premise to BTP so IAG can reach S/4HANA APIs without opening inbound firewall ports

Key Decisions and Requirements

Provisioning Architecture

Overview

SyWay’s SAP IAG landscape is delivered as a SaaS tenant on SAP Business Technology Platform, with the ability to connect to both cloud and on-premise systems. Environment alignment (DEV, INT, UAT, TRG, PRD) is achieved via dedicated IAG tenants in matching landscapes, ensuring consistent SoD enforcement and predictable deployments across stages. The architecture is cloud-first and region-agnostic, maintaining strict isolation of access-governance activities per environment while using SAP-delivered SCIM connectors for supported cloud apps (e.g., Ariba, SuccessFactors, iCertis, Work Zone). Integration with SAP Cloud Identity Services (IAS/IPS) standardizes provisioning flows.

IAG Subaccount Model

Runtime: SAP IAG is delivered as a SaaS service on SAP Business Technology Platform (multi-tenant, no direct runtime selection).

Naming: syw-<area>-<env>-<region> (e.g., syw-iag-dev-eu10)

Environment codes: dev, int, uat, trg, prd

Application Architecture Components

Global User ID integration:

As Syensqo continues to modernize its operations and expand its digital ecosystem, SAP solutions are playing an increasingly central role across multiple business domains. With the organisation’s landscape becoming more cloud-based and  integrated, maintaining a consistent identity framework across systems is essential.

• Accurate User Identification: Ensuring that the same individual is recognized seamlessly across SAP applications is fundamental to delivering secure authentication, appropriate authorization, and a unified user experience.
• Unique attribute with character length considered as some systems have a shorter character length for the user ID field (e.g. SAP S/4 HANA).
• Future Proofing for AI-Driven Capabilities: Consistency in user identity is also critical for AI-driven tools such as SAP Joule (the digital assistant) and SAP Task Center, both of which rely on harmonized user identities to operate effectively.
• A single user ID ensures cross system Segregation of Duties analysis is possible without any manual intervention and complex user mapping logic.

By using the field Person ID from Success Factors to map to the Global ID field in IAS/IdDS via IPS, we will be able to maintain the unique user identifier across all downstream applications without the need to maintain complex local user mapping routines.

As a minimum, the below user attributes should be mapped from Success Factors and transformed to IAS/IdDS.

The transformation will also need to consider other attributes such as group association and other user attributes as these can be used for filtering, conditional authentication and other security policies.

 The Global ID concept is not to be confused with SSO as the email address still being used as the unique user attribute used in the SAML Assertion for SSO.

The Global ID represents a single unique user identifier across all systems and platforms for the user.

The transformation logic in IPS is crucial for creating and maintaining the global user ID. By mapping attributes consistently, IPS ensures that the correct global user ID is assigned and used, linking user identities and attributes across different systems, even if the user's username or email differs in each system.

SAP Cloud Connector

SAP IAG runs as a SaaS service on SAP BTP (public cloud) and S/4Hana on-prem systems are usually inside the corporate network(Firewall protected).

The Cloud Connector(SCC) creates a secure reverse tunnel from On-prem to SAP BTP so that IAG can call S/4HANA APIs without opening inbound firewall ports.

Flow Overview:

• IAG Tenant (on BTP) → sends provisioning requests to S/4HANA.
• Requests go via the SAP Connectivity Service (on BTP)
• The Connectivity Service talks to the Cloud Connector (SCC) running inside your corporate network.
• SCC routes the request securely to the S/4HANA On-Prem system (using HTTP/S, RFC depending on the scenario).
• Responses (success/failure of provisioning) are sent back the same way.

    SAP IAG → Cloud Connector → S/4HANA On-Prem

SAP IAG to SuccessFactors Interface

Integrate SAP Identity Access Governance (IAG) with SAP SuccessFactors to:

• Automate access provisioning and de-provisioning based on employee lifecycle events (Hire, Transfer, Termination).

• Perform access risk analysis (SoD checks) for SF roles and permissions.

• Manage access requests for SuccessFactors roles via IAG workflows.

Please refer to FS ERP-202 Read Employee Master Data from SuccessFactors into Identity Access Governance for more details on IAG to SuccessFactors Integration 

Access Request Management

HR Triggers: We can integrate the SAP Cloud identity & access governance solution with HR systems. This enables changes in employee status(HR triggers) in the the SuccessFactors to initiate the access requests. The access request service converts the HR triggers to change requests, which are then provisioned to target applications.

When integrated with HR systems such as SAP SuccessFactors or SAP HCM, HR Triggers capture key personnel events—such as new hires, terminations, transfers, promotions, or leaves of absence—and automatically initiate the appropriate access management workflows within SAP IAG. These workflows can include creating, modifying, disabling, or deleting user accounts in connected target systems.

Process flow diagram of HR trigger

To automate identity and access management based on HR changes, we configure business rules in IAG that use conditional logic to decide what action to take for which type of data or event.

Prerequisite: All Master data should be in place like business roles build, ruleset and workflow configuration.

JML(Joiner, Mover, Leaver) approval flow:

SAP IAG to Ariba Interface

The main purpose of integrating SAP Identity Access Governance (IAG) with SAP Ariba is to govern, automate, and control user access to Ariba applications (like Ariba Network, Ariba Sourcing, Ariba Buying and Invoicing) from a centralized, compliant platform.

Please refer to FS ERP-287 Provision users in Ariba Sourcing based on IAG for more details on IAG to SuccessFactors Integration 

User Access Review(Access certification process)

Access certification service is used for periodically reviewing and certifying access to business applications in the cloud and on-premises area. It ensures that users have optimized access based on their designation.

The Managers and designated reviewers validate access to business applications. Periodic review process can be carried out for single roles, composite roles, business roles, profiles.

Responsibilities of Campaign Administrators, Coordinators and Reviewers:

Administrator – is responsible for creating and editing campaigns.

Coordinator – is responsible for coordinating campaign activities, for example, reassign items, remind reviewers, escalating to the reviewer's manager etc.

Reviewer – is responsible for approving/rejecting user access during review stage.

Process flow of Access Certification:

Process to review user Access in SAP IAG

1.Define the review cycle: Before starting,

• Determine how often access reviews will happen (quarterly, semi-annually, annually) 
• Identify which systems and which user groups are in scope (e.g., SAP ECC, S/4HANA, SuccessFactors)

2.Launch Access Review (Access Certification):In IAG Create a campaign and select the users in scope(choose users based on business area, department or system).

3. Notify Reviewers: Once the campaign is launched, Notification emails are automatically sent to reviewers, Each reviewers gets a review work item in their work inbox.

4.Perform Access Review: Reviewers log in and review each user's access:

       Validate if access is still required or should be removed 

        Approve: If access is still required 

        Reject: If access is no longer needed(In this case IAG will create requests for access deprovisioning from )

Data Provisioning Agent

SAP Analytics Cloud (SAC) Agent

OpenText Connector

Network Architecture

System Landscape

SAP IAG  will have 3 landscape: Development, Test and Production. Each landscape will connect to below applications.

The SAP IAG development environment will be integrated with the respective development target systems, including S/4HANA Dev, Ariba Development Tenant, and other applicable applications.

Upstream Sources (into IAG)

Connected Applications (via IPS)

Correlation: All targets must match on externalId = globalUserId. Where externalId is not supported, use a stable custom attribute (documented per connector).

System Access

Application Security

Authentication

SyWay standardises Single Sign-On on SAP BTP using region-specific SAP Identity Authentication Service (IAS) tenants federated to Microsoft Entra ID. Each BTP subaccount trusts its regional IAS tenant as the default identity provider; interactive sign-in between BTP subaccounts/services and IAS uses OIDC, while federation from IAS to Entra ID uses SAML 2.0. Conditional Access in Entra (including MFA and session controls) governs user access to BTP applications. Developer tooling (e.g., BAS/Build Code/CLI) follows the same IAS ↔ Entra flow—no separate SAP ID service identities. For service-to-service calls and Destinations, SyWay adopts standards supported by each target: OAuth 2.0 (including client credentials), OAuth2 SAML Bearer Assertion, or mutual TLS; Basic authentication is permitted only where a service does not support modern methods, and such exceptions are documented. Principal propagation is used where supported by the back-end/service pair. 

Authorisation

Business roles represent a high-level grouping of access aligned to specific job functions or responsibilities within the organization. Instead of assigning individual permissions or technical roles directly to users, business roles provide a simplified and standardized way to manage access. Each business role will bundle the necessary access components required to perform a particular role, supporting consistency, ease of provisioning, and alignment with governance and compliance requirements.

Business Roles should be defined to act as process driven components that deviate from HR job titles.

Key benefits:

• Supports modeling of business roles that aggregate technical roles or permissions from multiple systems
• Roles can be built to reflect job functions, departments, or business processes
• The service performs real-time SoD checks during role creation or modification
• Designed roles can go through workflow approvals before activation.

Communication Security

Data Security

Other Controls

Operation Architecture

Change and Configuration Management

Monitoring

Sizing

High Availability & Disaster Recovery

Backup/Restore

Maintenance Plan

Exceptions

See also

Terminology

Change log