-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Overview
Currently, we do not have a mechanism to synchronize claim (identity_attributes) metadata between the Customer Data Service (CDS) and the Identity Server (IS)
Both synchronization directions IS → CDS and CDS → IS need to be supported.
For the initial phase, we can focus on IS → CDS synchronization.
At present, CDS supports an initial one-time sync when the service is enabled for an organization (i.e., when "cds_enabled": true).
However, subsequent metadata updates such as claim additions, updates, or deletions are not currently handled.
There is no periodic synchronization mechanism in place, so any future updates will need to be triggered per claim, immediately following the relevant operation (add, update, or delete) in IS.
Key Considerations
-
Schema Dependency
- Name updates in IS should trigger profile schema updates and profile updates in CDS.
- Deletions in IS should cascade to remove the relevant attribute from all profiles in CDS and update the profile schema
- Additions in IS should be reflected in CDS as new schema attributes.
-
Type Handling
- IS stores all claim values as strings and converts them to their actual type only during rendering.
- CDS, on the other hand, preserves and enforces the exact data type defined in its schema.
- Type changes in IS can cause incompatibility with CDS data validation and storage. Need to decide on this on how we are approaching this
-
Multivalued Attributes
- IS currently drops all existing values and retains only the last value when an attribute is updated from multivalued → single-valued.
- When switching from single-valued → multivalued, CDS must decide how to migrate or preserve existing data.
- A migration policy or reconciliation strategy should be defined for both directions.
-
Attribute Creation and Ownership
- It must be clarified whether CDS can create new identity attributes directly based on its schema.
- If allowed, updates must be bi-directional and reflective — meaning changes in CDS should propagate to IS and vice versa.
Subtasks
- IS → CDS Schema Update Handling
- Implement one-way synchronization for identity attributes from IS to CDS when enabling
- Update CDS schema when claim names change in IS.
- Type Synchronization
- Multivalued Attribute Handling
- Remove attributes from CDS profiles when claims are deleted in IS.
- Add new attributes in CDS when new claims are introduced in IS.
- Implement data update for affected profiles.