[DIR-128] Group Create resource action

[VVill-ga]

Okta allows defining custom schemas, sometimes including required fields, so we fetch and parse those at registration time. Plan to expand this for more frequent refreshing of the schema.

The following fields can be added, but they are each additional API calls:

• Members (+1 api call per user)
• Owners (+1 api call per user) - also requires OIG
• Membership Rule
• Application access assignment

After discussion, we decided to support Members and Applications with limits on each.

[linear]

DIR-128 Add group management support to Okta connector

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch willgarrison/create-group-rs-action

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[phoebesimon]

@VVill-ga I think I'd lean toward including the ability to set members/owners/applications, but just limit how many can be set as part of the initial request here to something kinda small, like 25 (?). I'm a little more ambivalent on Rules, at least on this first pass, since they feel harder to present nicely in our UI/validate

[ggreer]

I don't think custom actions should be doing multiple grants as part of a create. Due to GRPC message limits, we have to restrict the number of users & apps that can be added. Also each request can fail (and doesn't seem to retry if we hit a retryable error), but we can't retry the whole operation since the group already exists and some users are already members. It makes much more sense to me to have an automation that creates the group, then makes grant tasks to add each user. That way if adding one user fails, the other users will still get added and the failed grants can be retried or at least shown on the ticket. If making lots of grants is too slow or inefficient, we should fix that problem instead of trying to work around it.

[VVill-ga]

Fair point on the erroring, if handling it is too complicated we can remove the fields, they are just nice to have for the action with the group template / creation flow.