Skip to content

Partial updates to IdP sync settings #15939

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Emyrk opened this issue Dec 19, 2024 · 1 comment · Fixed by #16351
Closed

Partial updates to IdP sync settings #15939

Emyrk opened this issue Dec 19, 2024 · 1 comment · Fixed by #16351
Assignees
Labels
api Area: HTTP API customer-requested Features requested by enterprise customers. Only humans may set this. multi-org temporary label for multiple organizations related work

Comments

@Emyrk
Copy link
Member

Emyrk commented Dec 19, 2024

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.

@coder-labeler coder-labeler bot added api Area: HTTP API needs-triage Issue that require triage labels Dec 19, 2024
@Emyrk Emyrk removed the needs-triage Issue that require triage label Dec 19, 2024
@Emyrk Emyrk added the multi-org temporary label for multiple organizations related work label Jan 6, 2025
@Emyrk Emyrk added the customer-requested Features requested by enterprise customers. Only humans may set this. label Jan 6, 2025
@Emyrk
Copy link
Member Author

Emyrk commented Jan 24, 2025

Related: coder/terraform-provider-coderd#150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Area: HTTP API customer-requested Features requested by enterprise customers. Only humans may set this. multi-org temporary label for multiple organizations related work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants