When building an external authentication connection to GitHub Enterprise, your options are CAS, LDAP, and SAML.
Active Directory (AD) (specifically Active Directory Federation Services (ADFS)) support both access via LDAP as well as SAML. Those should be the two primary integration solutions, reserving CAS only for a very unique usecase that you more-or-less need to custom code.
The key points to know when deciding on LDAP are:
- GitHub's LDAP authentication requires username and password to authenticate (password stored in the userPassword field)
- While this allows for a
single accountto be used amongst tools, it does require you to login to GitHub Enterprise even if your user has already been authenticated in other tools. - LDAP does allow for easy mapping of user roles/groups to GitHub teams.
- LDAP allows for roles/groups membership to be required for access to the system.
LDAP is best if it is satisfactory to use username/password to login, and you already have a very structure-rich directory, and TOTP is acceptable as the only multi-factor option.
What I typically see choosen by customers is instead SAML. With SAML via ADFS, you will automatically be logged in if another application has already authenticated you, any number of identification methods/accounts and variety of two-factor options are available, and when using claim rule templates in your AD Federation Services system, you can restrict access to GitHub Enterprise to only a subset of users.
Unfortunately, Active Directory uses a default claim-based authorization scheme that permits all users. This means that it returns everyone, and includes a description of what resources (typically backed by groups and roles) the service provider should support for that user.
This is incompatible with GitHub Enterprise as it attempts to return everyone, and rely on GitHub Enterprise to make the decision on whether or not to allow the user access. GitHub Enterprise is not configurable to make this determination.
Active Directory has a built-in solution that can solve this conflict between GitHub Enterprise and itself: Claims Templates.
Similar to GitHub Enterprise’s integration with LDAP, or how Azure Active Directory works, you can provision a user with a specific role (or group membership) that you use to enable or disable users access to GitHub Enterprise.
Through the use of Claim Templates, you can create conditional checks that stop the user from being returned if they don’t possess the right permissions (roles or groups in this case).
This way you can create a role or group that you apply to active directory users who you wish to have access to GitHub Enterprise, and then create a claim template to enforce these roles before allowing the full claims to be returned to GitHub (if you filter out the username, GitHub authentication will fail).
The claims template filters claims. I am currently unsure if you can filter an entire record from being returned. However, you could filter a claim (such as email address or username) that GitHub Enterprise requires for authentication that would meet the goal of this workflow.