Hi,
I’m currently working on an integration between Okta and Github so that we can control the Github teams by connecting them to Okta groups. The Okta groups are synchronized from the company’s AD, so we only configure the Github teams to be linked to Okta groups using Terraform and members are managed at the organization.
This configuration is giving us trouble as any reorganization of the company just leaves our groups empty. Modifications are done in one go and can modify many different groups. There is no notification system, so whenever this happens, we need to hurry to create the new Github teams, assign them the new groups and, the worst part, assign repositories to the teams so developers don’t lose their ability to work.
We want to decouple the AD from Okta in a way that our team manages the migrations. Our idea is to synchronize only new teams and their members but keep removed ones so that we can handle the migration of the repositories gracefully. Once the migration is finished, we would synchronize the removed ones so that they are deleted automatically from Okta.
I was reading the documentation but I don’t see a feature like this. I only see the notion of import safeguards but that works on a set threshold. That’s not good enough for us.
Is there any other feature we can use or another approach to handle this situations?
Thanks.
I’m not sure I’m fully following your use case, but it sounds at least to me like you want to not directly correlate the Github groups with the AD groups.
Would something like Group Rules help in your set-up? That way you can have a rule that handles adding AD users to new groups within Okta and then you can use these new groups for the application assignment instead of using the AD groups directly
Not really I’m afraid. From what I understand, with groups we can assign people to groups automatically based on attributes. That’s not enough for us. The structure at the company currently forces applications to create their own AD groups for each application (in our case Github) and assign people to them manually. We’ve tried automatic assignment of people based on AD groups but these are managed (or at least the people that goes in each group) by HR without any communication with the teams that configure the applications that rely on it. The new groups sometimes end up empty as the team that manages the AD don’t know where to put the people from the parent team into the children ones. As a result, any reorganization from HR that splits existing AD groups, creates new subgroups, removing the parent one and leaving some people orphaned. In our case, once this happens, we have 2 problems.
-
People see themselves without a team, losing access to Github repos
-
Repositories are not associated to the new teams as that’s not a concern of the team that handles the AD group and Okta
That’s why we needed some kind of buffer for deletions, so people still belong to a group with Github access while we give the tools to them (managers and developers) to reassign people and repositories to the right teams before deleting the old ones.
Probably this problem is more of the organization than of Okta itself. But, given all the applications that can rely on Okta groups, we would need some way to break down into steps any reorganization that happens, so the AD and Okta team doesn’t need to get information from all integrated applications to do a one go change to reassign resources to the new teams (e.g. new groups → list of people + Github repositories)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.