Overview
In a recent post, I explored how serverless functions can power security automation on OCI — and I’ve since come across another compelling use case worth sharing.
Many organizations need to keep users and groups synchronized across multiple OCI Identity Domains, whether for governance, access consistency, or operational efficiency. This is particularly relevant in scenarios such as a Hub and Spoke IAM domain setup, syncing users and groups between multiple Identity Domains within the same tenancy, or replicating identities across Identity Domains spanning a parent-child tenancy relationship. Rather than managing any of these manually, we can automate it end-to-end using native OCI services.
Here’s how it works: every operation on an OCI service — create, update, or delete — is automatically captured in OCI Audit logs. The OCI Events service monitors these logs in real time and can be configured to detect changes originating from a specific source Identity Domain. When a relevant event is detected, it triggers a serverless function that replicates the change — provisioning or updating the corresponding user or group in the target Identity Domain via SCIM.
The result is a lightweight, event-driven pipeline that keeps Identity Domains in sync without any scheduled jobs, manual intervention, or custom middleware — regardless of whether those domains sit within the same tenancy or span across organizational boundaries.
OCI Events Configuration
I will not go into details steps to configure Events. You can find them in the public docs.
Deploy OCI Function
To get started, create and deploy an OCI function by following the steps outlined in the OCI documentation. Once the Fn CLI is set up, create a Python function and replace the default code with the files from my GitHub repository — specifically func.py and requirements.txt.
There are five functions in total, each corresponding to a specific group or membership operation: CreateGroup, UpdateGroup, DeleteGroup, AddUserToGroup, and RemoveUserFromGroup. All five should be deployed.
Each function reads the source and target Identity Domain details — including OAuth client credentials — from the function configuration, as shown in the screenshot below. For production environments, it is strongly recommended to store client credentials in OCI Vault Secrets and retrieve them programmatically within the function code, rather than storing them in plain text configuration.
On the permissions side, the OAuth client in the target Identity Domain requires the User Administrator app role in order to provision users and groups. In the source Identity Domain, only read access is needed — either the User Administrator or Audit Administrator app role will satisfy this requirement.
https://github.com/kiranthakkar/ocifunctions/tree/main
Conclusion
By combining OCI Audit logs, the Events service, and serverless functions, we have a fully automated, event-driven solution for keeping users and groups in sync across Identity Domains — with no scheduled jobs, no manual intervention, and no custom middleware to maintain. Whether you are managing a Hub and Spoke IAM setup, synchronizing identities within a single tenancy, or replicating users across a parent-child tenancy boundary, this pattern offers a scalable and secure approach that grows with your organization. As always, ensure that OAuth credentials are stored in OCI Vault in production environments and that each function is granted only the minimum permissions it needs. I hope this gives you a solid foundation to build on — and as with any architecture, feel free to adapt it to fit your specific identity management requirements.