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 operation team to get the Cient ID,Scret and OAuth token URL for Azure.
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(IAG Manual request under PAM for SAAS application request type), 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

SSO Team registers and share the client id and secret for configurations to IAG

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 within iCertis introduces operational risks, lacks scalability, and is unable to enforce real-time approval workflows or segregation-of-duties (SoD) checks across systems.

Integrating iCertis with SAP IAG and IPS enables centralized and automated role-based provisioning, ensuring that access is granted only after the required approvals.

This integration further enhances security and auditability through compliant cloud-to-cloud communication, minimizes administrative overhead, and supports consistent access governance across the enterprise.

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

Not Applicable

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.

The specific rate limit for Icertis SCIM 2.0 is 5 API calls per minute, which is a default setting within their API Management service

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