Description
At present, all IdP sync settings (org, group, and role sync) require full policy updates. The API only supports the entire policy as an input, meaning the caller requires the full policy context to make updates.
Originally this was intentional to allow storing any such policy as a version controlled file.
In reality, this limits the ability to dynamically interact with the policy. A use case has risen for organization sync that new organization sync mappings are created from some external event. This event has a trigger to create a new org sync mapping row, or append to an existing row. With the current policy API, the event has to recreate the entire policy.
To support a dynamic approach to IdP sync setting updates, a granular API should be created.
Implementation details
All 3 syncs should support this to keep things consistent. All 3 support the Mapping
field.
- RoleSync:
Mapping map[string][]string
- Org Sync:
Mapping map[string][]uuid.UUID
- Group Sync
Mapping map[string][]uuid.UUID
Proposed API requires each change to be an explicit addition or deletion of a singular value on the right hand side of the mapping. This makes changes explicit, and not inferred.
type Diff[T] struct {
Key string
Value T
}
type DiffSet[T string | uuid.UUID] struct {
Adds []Diff `json:"create"`
Remove []Diff `json:"delete"`
}
Ambiguous additions example from race condition
Given 2 updates:
State: developers --> []
Update A: engineering --> ["developers", "employees"]
Update B: engineering --> ["developers", "employees", "QA"]
Designed to run as [A,B], the outcome should be ["developers", "employees", "QA"]
.
You could imagine the race condition [B,A], it would be interpreted "QA" is to be removed, rather than added.
If run as:
Update A: add("engineering", "developers") add("engineering", "employees")
Update B: add("engineering", "QA")
The updates in any order would result in the correct output.
Validation?
There is an argument to make sure deletions are always correct. Meaning if using delete
, and the value to be deleted does not exist, an error should be thrown.
If so, we can add a Force bool
field. If this is done, I feel force
might be used more often than not. And it might be better to add a Strict bool
field to opt into the behavior.
Other fields
It might be worth to add partial updates to the remaining fields in the IdP sync as well.