Setting Up GitHub SSO

You might be interested in this article if you are a SaaS application owner using SSO to secure your application.

Our Elanco GitHub organisation is currently secured with GitHub’s own native multi-factor authentication (MFA). We wanted to use GitHub as a test case for setting up SSO using our new Azure Active Directory tenant.

User Experience

From a user’s perspective, there are only a couple of actions they need to take to ensure they can login with SSO. First users need to associate their GitHub account with their Elanco.com email address. Then we can then email them an invitation to join Elanco’s GitHub

When they click the invitation, they can link their account to the Elanco GitHub Organisation.

Once set up, this makes the log in experience much like any other SSO process, only instead of the familiar Lilly SSO login screen:

Users are redirected to the new Elanco Login:

How did we do it?

These are the steps we followed to get things set up:
 

1. First, we created an Active Directory (AD) Group in Elanco Azure for all the users we wanted to allow access to GitHub. We called this GitHub_Users. We had to create this manually, but in future this will be managed via a Service Request.
2. We created an app registration within Azure AD. This registration acts as the gatekeeper between AD and GitHub.
3. This app registration produces the connection details we need to provide to GitHub, including the:
   1. Redirection URL
   2. Certificate / Security Keys etc
4. We entered the above in the GitHub SSO set up page, and tested to make sure it worked.

We’ve not switched SSO on for everyone yet (we’re using MFA), as we have such a small number of users at the moment,

Advantages?

Aside from the obvious advantages for our users - not needing to remember yet another password - there are a few advantages for administrators of the platform.

• Once we do switch SSO on, anyone without an Elanco.com email, will be removed from our GitHub Organisation.
• Once we know that everyone in our GitHub organisation has an elanco.com email attached to their account, we can begin to control users centrally from AD instead of through GitHub administration.  We can begin to specify attributes in AD itself before people have a GitHub account, which will allow people to be added to the correct groups if they do join the Elanco GitHub organisation in future.
• This would also enable us to do ‘short life’ groups, where users can be provisioned access to specific repos/projects for a limited amount of time. Whilst not available for day one, this could reduce the need for the manual access roster reviews in GitHub if users have the correct attributes applied in AD.

We’re excited to have taken this next step towards using the new Elanco infrastructure and we hope you found the update helpful. If this post has triggered further questions for you, please reach out to us on the ETS – Ask Us Anything Channel.