GitHub SAML SSO Guides for GitHub Enterprise Cloud, 18 Oct 2022

Previous Meeting

⏯

youtube image

►

From YouTube: SAML SSO Guide Part III: Enterprise vs. Organization Level Implementation

Description

—Summary—
00:00 Intro
00:33 Prerequisites
00:58 SAML SSO enterprise level implementation
01:24 SAML SSO organization level implementation
01:52 Differences between enterprise and organization level implementations
03:41 SAML SSO enablement DEMO
04:41 Features availability for organization and enterprise level implementations
05:19 Team Synchronisation DEMO
05:54 User provisioning and deprovisioning with SCIM overview

—Documentation—
Managing team synchronization for your organization - GitHub Enterprise Cloud Docs: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/managing-team-synchronization-for-your-organization)
About SCIM for organizations - GitHub Enterprise Cloud Docs: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations

--
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

A

Solutions engineer in this video we are going to talk about if you should Implement some SSO at Enterprise level or at the organization lab. This is one of the commonly asked questions that we get as Solutions engineers, I hope by the end of this video, you are in a better position to choose. What's the best for your Enterprise, let's get started.

A

The prerequisites for this guide are GitHub Enterprise Cloud platform. So you must be on this one, no Enterprise Manager users, so we are also talking about here, SEMO 2.0 standard. So that's the standard that integrates with GitHub Enterprise Cloud, the one that's supported and you need Enterprise and organic access because we're covering both Enterprise and organization Administration accounts.

A

When talking about Enterprise level and implementation, you can find the some SSO settings at your Enterprise account it's located under settings and authentication security, so some SSO at Enterprise level is considered the most secure option compared to the organization, because it's virtually going to apply the same SSO across the whole organizations inside this Enterprise account as the organization levels, some Osso configuration can be found under organization settings. If you go to authentication Security in your left sidebar, this is the most flexible implementation of some SSO.

A

It's especially useful if your company is undergoing is low row out of some SSO. It's also important to highlight that semident providers can build some features on top of some SSO. If you have it enabled at organization lab, let's Jump Right In, to highlight some important differences if your company has multiple subsidiaries with different identity providers, an organization lab implementation is the most helpful.

A

For example, subsidiary a is using OCTA, while subsidiary B is using Azure ID in this case organization, lab implementation provides the most flexibility.

A

Asmss implementation at the Enterprise level, however, provides a unified setup for all the organizations and your Enterprise account.

A

Another differentiator between these two levels of implementation is enforcement. Enforcement means that users must be logged in against your identity provider before they have access to your organization resources. When you implement SEMO at the Enterprise account level. This is automatically enforce it, for you, users that have not been authenticated against your Advanced provider are going to be removed. Any users that are removed during this process.

A

They can be restarted with the same rights that they had before within a three months time frame, so that's important step to communicate across your organization across an Enterprise and make sure that everybody is aware of this change. On the flip side, if you're, enabling some SSO at the organization level, you will still have the option to enforce it. This option appears under organizational settings as well. We are going to see this checkbox there and you don't need to enforce it until you're ready to eat.

A

Unauthenticated users will not be removed until you check this box. So that's the difference between enabling and enforcing it. You can set a deadline for everyone inside your organization. You can communicate, and this is an option that we we have for you to do it on your own pace. We Face low rollout of some SSO within your companies that needs to be once you have enforced assemble. You can switch on Enterprise implementation too. Now, let's go Hands-On, let's assume in a GitHub administrator and I.

A

Have the mission of enabling some SSO, so I could do that at the organization level and for that I would go to settings and under settings authentication security, so here I would click on enable some authentication and I would have to fill these fields. Taking a look of how my ident provider implements some SSO I would test that some configuration and that I will have put that in place if you'd like to enforce it across all the organizations inside my Enterprise account I would have to go to the Enterprise account level.

A

So let me go back to the organization and then I click on the Enterprise account at the Enterprise account level. I would go down to settings authentication security here. The difference that I'm going to require some SSO, so the same Fields apply, but at the end the result is going to be an enforcement of submissive. So the last differentiator I'd like to talk about is about feature availability.

A

There are more features available. If do the implementation at the organization level, then if you do that at the Enterprise level, for example, team synchronization, so thin synchronization is a feature that allows you to synchronize up to five identity provider groups, with a GitHub team check out in the description box for more details on how this feature works. It's currently available on Azure ID at the Enterprise and organization level and for OCTA it's available only at the organization level.

A

Now, let's take a look on how desynchronization work Hands-On on my right side, I have a hrid instance with some groups predefined on my left side, I have or an organization at GitHub that has thin synchronization enabled with these ident provider.

A

So if I go here to teams and what's to create a new team I'm going to see that I have the option to sync with ident provider groups, when I click on select groups, groups from ident provider are going to be loaded and team membership is going to be established as soon as I create a new team. Other important feature to talk about is skin. Skin is going to allow you to provision all the provision users through your identity provider.

A

If a skin provision is implemented in your organization, any changes in organization membership, your identity provider is going to be reflected in GitHub if you're some SSO without implementing skin. You won't have access to user provision and the provision for more information about how skin Works check out the description box below so I hope. This video is helpful for you to identify, based on your needs and based on your identity provider. What you have available today, if you get help and how you can secure further your intellectual property thanks so much for tuning in foreign.