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 to all in scope Syway system 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 will 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 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.

Interfaces and Connectors

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 

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 

JML (Joiner, Movers & Leavers)

HR Triggers (Design):
The SAP Cloud Identity Access Governance (IAG) solution will be integrated with the HR system (SAP SuccessFactors/SAP HCM). Changes in employee status will generate HR triggers in SuccessFactors that will automatically initiate SAP IAG Access Request workflows. The Access Request service will convert each HR trigger into a change request, which will be provisioned to the connected target applications.

When integrated, HR Triggers will capture personnel events—new hire, termination, transfer, promotion, and leave of absence—and will automatically execute the corresponding access actions in SAP IAG, including creation, modification, disabling, or deletion of user accounts across 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:

Recertification

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 

Network Architecture

NA

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

Work Zone

All user access to SyWay systems will have one central landing zone in the form of SAP WorkZone. 

System Access User Flow

Application Security

Authentication Approach (SP‑Initiated SSO)

SyWay standardizes Single Sign-On (SSO) across the SAP Business Technology Platform (BTP) using region-specific SAP Identity Authentication Service (IAS) tenants federated with Microsoft Entra ID. Each BTP subaccount designates its respective IAS tenant as the trusted identity provider, ensuring consistent and secure user authentication.

All interactive user logins are Service Provider (SP)–initiated:

• Authentication between BTP subaccounts or services and IAS uses OpenID Connect (OIDC).

• Federation from IAS to Microsoft Entra ID is established via SAML 2.0.

For non-interactive authentication and system-to-system communication, SyWay adopts modern standards based on the target system’s capability:

• OAuth 2.0 (including Client Credentials Grant)

• OAuth2 SAML Bearer Assertion

• Mutual TLS (mTLS)

Basic authentication is permitted only as an exception where modern protocols are not supported; such cases must be formally documented and approved. Principal Propagation is enabled wherever supported to maintain user context across connected systems.

Human, SP‑Initiated SSO

Non‑Interactive / Service‑to‑Service & Destinations

Authorisations

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 modelling 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

The below table shows the in scope systems for Syway and the encryption protocols used to secure communication between each system.

Data Security

Data security in our landscape is about enforcing least privilege so that only authorized users can perform approved actions on the specific data they’re entitled to see. I will implement a layered access‑control model that combines RBAC, ABAC, and Groups. RBAC will define business roles and the precise permissions each role grants (the what a user can do). ABAC will add fine‑grained, context‑aware rules that filter data by attributes such as Nationality, location, company code, region, business unit, asset, or document owner (the which records a role can act on and under what conditions). Groups—managed centrally in the IdP—will streamline assignment and lifecycle (the who gets which roles), support separation of duties, and simplify provisioning and reviews. Together, this model delivers defence‑in‑depth: roles gate capabilities, attributes constrain data scope, and groups keep access manageable, auditable, and adaptable as the organization changes.

Other Controls

Operation Architecture

Change and Configuration Management

Monitoring

Sizing

High Availability & Disaster Recovery

Backup/Restore

Maintenance Plan

Exceptions

See also

NA

Terminology

Change log