Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams

The content below is taken from the original ( Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams), to continue reading please visit the site. Remember to respect the Author & Copyright.

Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams

Cloudflare Access secures internal applications without the hassle, slowness or user headache of a corporate VPN. Access brings the experience we all cherish, of being able to access web sites anywhere, any time from any device, to the sometimes dreary world of corporate applications. Teams can integrate the single sign-on (SSO) option, like Okta or AzureAD, that they’ve chosen to use and in doing so make on-premise or self-managed cloud applications feel like SaaS apps.

However, teams consist of more than just the internal employees that share an identity provider. Organizations work with partners, freelancers, and contractors. Extending access to external users becomes a constant chore for IT and security departments and is a source of security problems.

Cloudflare Access removes that friction by simultaneously integrating with multiple identity providers, including popular services like Gmail or GitHub that do not require corporate subscriptions. External users login with these accounts and still benefit from the same ease-of-use available to internal employees. Meanwhile, administrators avoid the burden in legacy deployments that require onboarding and offboarding new accounts for each project.

We are excited to announce two new integrations that make it even easier for organizations to work securely with third parties. Starting today, customers can now add LinkedIn and GitHub Teams as login methods alongside their corporate SSO.

The challenge of sharing identity

If your team has an application that you need to share with partners or contractors, both parties need to agree on a source of identity.

Some teams opt to solve that challenge by onboarding external users to their own identity provider. When contractors join a project, the IT department receives help desk tickets to create new user accounts in the organization directory. Contractors receive instructions on how to sign-up, they spend time creating passwords and learning the new tool, and then use those credentials to login.

Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams

This option gives an organization control of identity, but adds overhead in terms of time and cost. The project owner also needs to pay for new SSO seat licenses, even if those seats are temporary. The IT department must spend time onboarding, helping, and then offboarding those user accounts. And the users themselves need to learn a new system and manage yet another password – this one with permission to your internal resources.

Alternatively, other groups decide to “federate” identity. In this flow, an organization will connect their own directory service to their partner’s equivalent service. External users login with their own credentials, but administrators do the work to merge the two services to trust one another.

While this method avoids introducing new passwords, both organizations need to agree to dedicate time to integrate their identity providers – assuming that those providers can integrate. Businesses then need to configure this setup with each contractor or partner group. This model also requires that external users be part of a larger organization, making it unavailable to single users or freelancers.

Both options must also address scoping. If a contractor joins a project, they probably only need access to a handful of applications – not the entire portfolio of internal tools. Administrators need to invest additional time building rules that limit the scope of user permission.

Additionally, teams need to help guide external users to find the applications they need to do their work. This typically ends up becoming a one-off email that the IT staff has to send to each new user.

Multi-SSO with Cloudflare Access

Cloudflare Access replaces corporate VPNs with Cloudflare’s network. Instead of placing internal tools on a private network, teams deploy them in any environment, including hybrid or multi-cloud models, and secure them consistently with Cloudflare’s network.

Administrators build rules to decide who should be able to reach the tools protected by Access. In turn, when users need to connect to those tools, they are prompted to authenticate with their team’s identity provider. Cloudflare Access checks their login against the list of allowed users and, if permitted, allows the request to proceed.

Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams

With Multi-SSO, this model works the same way but extends that login flow to other sign-in options. When users visit a protected application, they are presented with the identity provider options your team configures. They select their SSO, authenticate, and are redirected to the resource if they are allowed to reach it.

Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams

Cloudflare Access can also help standardize identity across multiple providers. When users login, from any provider, Cloudflare Access generates a signed JSON Web Token that contains that user’s identity. That token can then be used to authorize the user to the application itself. Cloudflare has open sourced an example of using this token for authorization with our Atlassian SSO plugin.

Whether the identity providers use SAML, OIDC, or another protocol for sending identity to Cloudflare, Cloudflare Access generates standardized and consistent JWTs for each user from any provider. The token can then be used as a common source of identity for applications without additional layers of SSO configuration.

Onboard contractors seamlessly

With the Multi-SSO feature in Cloudflare Access, teams can onboard contractors in less than a minute without paying for additional identity provider licenses.

Organizations can integrate LinkedIn, GitHub, or Google accounts like Gmail alongside their own corporate identity provider. As new partners join a project, administrators can add single users or groups of users to their Access policy. Contractors and partners can then login with their own accounts while internal employees continue to use the SSO provider already in place.

Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams

With the Access App Launch, administrators can also skip sending custom emails or lists of links to new contractors and replace them with a single URL. When external users login with LinkedIn, GitHub, or any other provider, the Access App Launch will display only the applications they can reach. In a single view, users can find and launch the tools that they need.

The Access App Launch automatically generates this view for each user without any additional configuration from administrators. The list of apps also updates as permissions are added or removed.

Multi-SSO and Cloudflare Access: Adding LinkedIn and GitHub Teams

Integrate mergers and acquisitions without friction

Integrating a new business after a merger or acquisition is a painful slog. McKinsey estimates that reorganizations like these take 41% longer than planned. IT systems are a frequent, and expensive, reason. According to data from Ernst and Young, IT work represents the third largest one-time integration cost after a merger or acquisition – only beat by real estate and payroll severance.

Cloudflare Access can help cut down on that time. Customers can integrate their existing SSO provider and the provider from the new entity simultaneously, even if both organizations share the same identity provider. For example, users from both groups can continue to login with separate identity services without disruption.

IT departments can then start merging applications or deprecating redundant systems from day one without worrying about breaking the login flow for new users.

Zero downtime SSO migrations

If your organization does not need to share applications with external partners, you can still use Multi-SSO to reduce the friction of migrating between identity providers.

Organizations can integrate both the current and the new provider with Cloudflare Access. As groups within the organization move to the new system, they can select that SSO option in the Cloudflare Access prompt when they connect. Users still on the legacy system can continue to use the provider being replaced until the entire team has completed the cutover.

Regardless of which option users select, Cloudflare Access will continue to capture comprehensive and standard audit logs so that administrators do not lose any visibility into authentication events during the migration.

Getting started

Cloudflare Access’ Multi-SSO feature is available today for more than a dozen different identity providers, including the options for LinkedIn and GitHub Teams announced today. You can follow the instructions here to start securing applications with Cloudflare Access. The first five users are free on all plans, and there is no additional cost to add multiple identity providers.