High-Level Specification

Functional Overview

This specification outlines the detailed design for the integration between iCertis and SAP Identity Access Governance (IAG). The goal of this integration is to automate the provisioning, updating, and deprovisioning of user accounts, groups, and authorizations in iCertis through IAG. This ensures that access is consistently controlled, compliant, and properly aligned with organizational policies.

In this model, SAP IAG serves as the central system for user and role provisioning as well as Access Risk Analysis, while iCertis continues to manages the entire contract lifecycle, from creation and negotiation to execution and renewal. User accounts and group assignments will be provisioned from IAG to iCertis through SCIM-based connectivity, removing the dependency on manual user administration within iCertis.

Scope and Objectives

Automate and govern iCertis 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 utilized by SAP IAG & IPS to provision users and groups to iCertis. 

Dependencies

1. Send email to SSO iCertis operation team to get the Cient ID,Scret and OAuth token URL for iCertis system.
2. Get the Scope and token URL for the iCertis endpoint.
3. Request the iCertis team to publish the groups under the /groups SCIM endpoint to achieve SCIM compliance.

Security, Integrity and Controls

Access Control & Segregation of Duties

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

• No iCertis 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

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

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

• All traffic between IAG and iCertis 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 iCertis Portal are protected by the API Gateway and OAuth.

• The Gateway validates the token associated with the registered client. Only requests with a valid token are accepted.

• Each API request must include a valid OAuth 2.0 access token issued to the client application.

Configuration Requirements

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

Register an iCertis application and share the Client Id and secret.

Create the iCertis Proxy system in Cloud Identity Service as per the configuration details listed below.

Refer to the link https://help.sap.com/docs/identity-provisioning/identity-provisioning/proxy-scim-system to set up the iCertis system in Identity Provisioning system.

Create an application type for the SCIM API in the IAG system, and subsequently create the application under this application type. Refer to the link https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/e12d8683adfa4471ac4edd40809b9038/37e4c466f8294eed88d284650d0c7070.html?state=DRAFT&version=2205

Run the repository sync job in IAG to read the users and groups from iCertis system.

Design Rationale

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

Integrating iCertis 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?

• iCertis supports SCIM 2.0 APIs for user provisioning.

• 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 Email will be used as the iCertis User ID in the IAG system.

Username normalization

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

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 iCertis.

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

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 >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 iCertis/IAS.
  
  
  

Test Conditions and Expected Results

Test Considerations/Dependencies

Not Applicable

Change log