High-Level Specification

Functional Overview

This specification defines the detailed design for the integration between SAP Ariba Sourcing and SAP Identity Access Governance (IAG). The purpose of this integration is to automate the provisioning, update, and deprovisioning of user accounts and authorizations in Ariba via IAG, ensuring that access remains controlled, compliant, and aligned.

In this model, SAP IAG serves as the central system for user and role provisioning as well as Access Risk Analysis, while SAP Ariba continues to function as the operational platform for procurement activities. User accounts and group assignments will be provisioned from IAG to Ariba through SCIM-based connectivity, removing the dependency on manual user administration within Ariba.

As part of Release 2, the integration between Ariba and IAG is being established. During this phase, user provisioning is handled manually via the IAG Access Request Service.

In Release 4, user provisioning will be automated. Additionally, IAG will provision the Manager and Responsibility fields to the Ariba system.

Scope and Objectives

Automate and govern SAP Ariba user access via IAG to reduce manual effort. Also to populate user to group mapping to facilitate the SOD process for Risk Analysis.

Technical Architecture Diagram

Process Flow Diagram

Design Assumptions

iCertis tenant exposes a SCIM 2.0 endpoint for Users & Groups that is reachable from SAP IAG and supports the required ops (GET/POST/PUT/PATCH for delta updates), with a unique, immutable identifier available for mapping. This SCIM connector will be utilised by SAP IAG & IPS to provision users and groups to Ariba. 

Dependencies

1. Ariba app registration & credentials: Register the application in the SAP Ariba Developer Portal, obtain the OAuth Client ID/Secret, API Key, Oauth Token URL and configure these in SAP Cloud Identity Services – Identity Provisioning (IPS) for the Ariba target.
   
2. Username case-insensitivity: The SAP Ariba SCIM API treats usernames as case-insensitive (e.g., johndoe = JohnDoe). Enforce pre-provisioning normalization (e.g., lowercase) and uniqueness to prevent collisions.
   

Security, Integrity and Controls

Access Control & Segregation of Duties

• Security personnel must not manually create, modify, or delete users directly in SAP Ariba. All identity changes are executed exclusively via SAP IAG through the SCIM connector to preserve clear control boundaries and auditability.

• No Ariba end-user accounts are granted user-admin capabilities.

• If emergency manual intervention is unavoidable, a break-glass procedure applies: raise a ticket, obtain a documented exception, perform the minimum required action, and ensure full post-event review.

Service Account for System-to-System Calls

• Ariba–IAG integration uses a dedicated technical (service) account with the least privileges required to create and update users/groups in Ariba.

• The service account authenticates using a securely stored client secret; Basic authentication is not used.

• All traffic between IAG and Ariba is over HTTPS/TLS to ensure confidentiality and integrity in transit.

API Authentication & Gateway Enforcement

• All SCIM API calls are authenticated via OAuth 2.0 Client Credentials (two-legged OAuth).

• APIs published on the SAP Ariba Developer Portal are protected by the API Gateway and OAuth.

• The Gateway validates the application key (apikey) associated with the registered client. Only requests with a valid apikey are accepted.

• Each API request must include both:

  1. a valid application key, and

  2. a valid OAuth 2.0 access token issued to the client application.

Configuration Requirements

To build the integration of SAP IAG to Ariba application below steps needs to be performed

Register an application in SAP AribaDeveloper Portal below steps need to be followed:

• Log on to Developer Portal
• Choose . Add Application
• Fill in the application name and its description.
• Press Request API access and select Ariba Tenants and SCIM API
• Once approval email is received, browse the Application list to confirm the status

Note: There is an automatic 12 hour delay until the app is approved by Ariba. 

Once  registration is completed build the proxy system in Identity Provisioning system CIS, refer to the link https://help.sap.com/docs/identity-provisioning/identity-provisioning/proxy-sap-ariba-applications

Design Rationale

Manual user provisioning in Ariba is error-prone, non-scalable, and cannot enforce real-time workflow approvals or cross-system SoD checks. 

Integrating Ariba with SAP IAG and IPS enables centralized, workflow-driven, role-based provisioning, ensuring only approved users receive access immediately. 

This approach provides secure, auditable, and compliant cloud-to-cloud integration, reduces maintenance overhead, and supports enterprise-wide access governance.

Why use SCIM via IPS?

• Ariba supports SCIM 2.0 APIs for user provisioning.

• Its a standard out of the box connector provided by SAP. Its supported by SAP and if any issues occur, SAP are responsible for fixing it.

• SCIM is an industry standard for managing users, groups, and entitlements across systems.

Data Structure

The following fields will be used to provide the required data structure of the interface:

Identifier choice

In the provisioning process, the SAMAccountName will be used as the Ariba User ID in the IAG system.

Username normalization

All Ariba UserID's will be provisioned in lowercase to eliminate case collisions and to align with the hard requirement for user formatting in Ariba.

Delta or Full Load Requirements

The initial synchronization performs a full data load, after which the repository sync job operates in delta mode, processing only incremental changes. In the event of a job failure, system logs automatically generate alerts to notify administrators. Administrators can manually re-run the sync job at any time, and the recovery process is quick and straightforward.

Monitoring

Volumetrics

Performance Consideration

Data transfer volumes are optimized by leveraging incremental synchronization, where only delta changes (new, modified, or deleted user records) are processed instead of full data loads. This approach reduces network usage and processing time while maintaining data accuracy and consistency between systems.

Batch sizes, job frequency(Every 3 hours), and retry intervals are configured based on the expected data volume and system load capacity to ensure timely provisioning without overloading the network or connected systems. IPS job scheduling is carefully aligned with system maintenance windows to avoid conflicts with other integrations or background jobs running in SAP IAG or Ariba.

Delta vs Full loads

To mitigate possible performance issues, we will only trigger full loads when necessary. A full load consume a whole lot of resources in IAG, so this is ran at the beginning only, then delta reads thereafter to reduce payloads and runtime. We aim to ensure small time‑window overlap in deltas to handle clock skew without duplicating work

Pagination & batch sizing

A rule of thumb will always be to page SCIM reads. We aim to avoid very large group calls as it increases runtime. Ariba has a hardcoded limit on the member returned per request for SCIM resources, thus this will be taken in consideration when paging., ie: not fetching ALL in one go. Default value: 50. This is believed to be a reasonable choice given the limited number of users in Ariba. As of October 2025, Syensqo is licensed for 102 users of Ariba Sourcing. 

Attribute minimization & transformations

IPS will only read the attributes that are needed. Within the transformation we will drop / filter any unused fields to maintain performance.

Rate Limits

Identity Provisioning APIs implement rate limits to control the number of incoming requests for a given time.

Identity Provisioning Rate Limits

The Identity Provisioning rate limits are enforced at tenant level to the total number of incoming requests (that is, incoming calls for real-time provisioning and proxy systems).

Error Handling

To help support Error Handling, the below table can be reviewed to help with the typical error codes that may be experienced if a SCIM connector fails.

Typically these errors will only be viewable to the IPS admin who has access to the job log in BTP.

Please refer to the below link to get more details on error.

https://help.sap.com/docs/CENTRAL_INVOICE_MANAGEMENT/da931cb8aae0453584e3a3765a6fbd4b/854cedd8e5f245109c1f04919069d172.html

Testing

How to Test

• Create a job in the Job Scheduler tile > SCI User Group Sync Job > Schedule Job
  
  

• Check the Job has finished in the "Job History List"
  
  
  An example of a negative test can be seen below. If the job fails, there will be an error code visible in the list: - Below shows Error 401, when referenced about you can see this is related to Bad/expired credentials or wrong OAuth/token setup to Ariba/IAS.
  
  
  

Test Conditions and Expected Results

Test Considerations/Dependencies

Not Applicable

Change log