• Introduction
• GitHub
  • Requirements
• Okta
• Okta Workflows
  • Requirements
  • What are we doing
  • Photo Flow
  • Flow Diagram

Introduction

Previously, I wrote about using Okta to track GitHub Usernames across the entire org and further tracking that could be done from that using SIEM or Okta Workflows & Google Sheets. You can find that blog post here.

Today however, I am wanting to introduce a different flow of workflow (similar to SCIM) that automatically checks if the username exists in GitHub (isn’t some bogus/fake username) and then automatically checks to see if a team exists under their Department / Team Name and if not, creates the Parent and Child team relationship in it’s place.

GitHub

GitHub provides a SCIM based way to manage teams effectively, which is outlined here. However, there are some drawbacks to that.

• If SCIM based, you cannot manage the GitHub team outside of the IDP
• Parent teams cannot be syncronized using IDP Groups

The benefit of this Okta Workflow is that,

1. Teams do not become SCIM based, so if management needs to happen to the team, it is still flexible.
2. Teams can still be audited through the use of Workflows to validate if membership is correct or if there are pending members elsewhere.
3. Parent Teams can still be syncronized using the API.

Requirements

• GitHub Enterprise Cloud (maybe)

It is honestly unclear to me when looking through GitHub’s API Documents, if GitHub Enterprise Cloud is actually required to use the API endpoint. They make note of the licensing level, but, they are talking about a feature not the API itself. In any case, we do have GitHub Enterprise Cloud at the time that I wrote this workflow.

• API Access to the following
  • Add or update team membership for a user
  • Get a team by name
  • Create a team

Okta

This will use the existing group rule and group setup that is described in the afore mentioned blog post linked in the introduction.

Okta Workflows

Requirements

• Process Name Flow
• GitHub Folder Flows

We utilize these two flows to:

• Run the actual flow
• Sanitize names

Also, the Process Names flow was actually written by someone (I can’t find who, otherwise I would credit them, and will do so once I find the post) in #okta-workflows on MacAdmins.

What are we doing

1. Due to membership of iam-github-sso, and subsequently being assigned GitHub, this kicks off the flow.
2. We read the GitHub Username from the member’s profile.
3. We search for the GitHub Username.
   1. If it error’s out:
      1. We compose a card with variables and text.
      2. Remove the user from the Group (which should automatically remove them from the Application).
      3. We attempt to remove them from the application just in case (wrapped in a try card to prevent issues with errors).
      4. We clear out the GitHub Username value in the attribute.
      5. Subsequently alert two channels that we have removed an employee’s information and to follow up with them.
   2. If it returns back as valid, we continue on to step 4.
4. We start the process for the Parent Team in GitHub
   1. We process the name of the Department so we create it’s slug.
   2. Replace any spaces with -.
   3. Search for the Slug on GitHub in your org Note: GitHub returns all results that would have a match. So tech could also include marketingtechnology and tech.
   4. We run a Find card to do an exact match of the team name. We get the team ID
   5. Do an If / Else:
      1. If the team value is empty:
         1. Create the Team Description
         2. Construct the body of the GitHub Team for the API call
         3. Use a custom API Call (because for whatever reason Okta Workflows won’t let us create a Team)
         4. Get the output of the Body and return multiple results
      2. If the team value is not empty
         1. Cool the team exists and we can utilize the existing ID that was found during the search.
   6. From there, we can add the user to the parent team, using a Try Card
      1. Initial Try:
         1. We construct the URL of the slug and the username we want to add.
         2. We utilize a Custom API card because the default “Add User to Team” card has to be hardcoded for the team value. :sadness:
      2. If that fails:
         1. We compose a construct card and output to Slack saying that we couldn’t add the user to the team.

For the child flow, we basically repeat step 4 through 6. However, we add the following to the Constructed Body: "parent_team_id":$Parent Team ID}

This allows us to create the sub team.

Photo Flow

Flow Diagram

There are definitely some more validation checking and error checking that could be done, but this should get you on the right track to automate team memberships in the same way that SCIM does it while not having to adhere to some of the limitations of SCIM.

If anyone has some ideas on improvements or opinions, feel free to share below in the comments. :)