Managing User Authentication in the Cloud

How do you manage user identities and permissions in your organization?

If you’re like 95 percent of enterprise companies, you’re using Microsoft’s Active Directory Domain Services, otherwise known as Active Directory or simply AD. This is the system that allows your employees to use the same username and password to access any domain-bound internal system, and allows your administrators to manage user identities, rights and permissions at scale. Since its introduction in the late ‘90s, AD has become the most robust, dominant and ubiquitous directory service utility in the technology world.

Before the advent of the cloud, AD was all most companies needed for identity management and authentication. AD managed the services, tools and data stores employees needed on-premises. To access these services with their AD credentials, employees needed direct local network access via an on-site device or a virtual private network.

Today, cloud-based Software as a Service (SaaS) solutions are replacing on-premises solutions of all kinds, including tools for collaboration and data sharing, office productivity, creative production work and data security.

As companies transition their data security to the cloud, identity management and authentication architectures have to transition, too. It can be difficult to keep track of where their AD data lives as it moves between clouds, data centers and endpoints. It can be hard to answer “who, what, when, where and how” data moved, so determining “why” can feel next to impossible.

As a long-time data security solutions provider, we’ve worked with hundreds of organizations as they make this journey. From those experiences, we’ve developed a set of recommendations to help you navigate this change to identity management and authentication systems while maintaining your data security and minimizing user hassle.

“ We’ve developed a set of recommendations to help you navigate this change to identity management and authentication systems while maintaining your data security and minimizing user hassle. ”

Identity management in the cloud

There are many benefits to using cloud-based SaaS services, including reduced costs for platform management and increased scalability. Of course, there are also challenges. One of the biggest problems to solve is integrating an existing on-premises AD identity management structure with these external tools. How can you leverage that existing structure so that users can access new SaaS tools with the same login credentials they’re accustomed to?

Single Sign-On

For security reasons, exposing your local AD server to the internet is not recommended. You could set up a lightweight AD server in a network DMZ that syncs with the internal AD domain controller and thus provides authentication for external requests. However, many cloud-based SaaS services don’t support querying AD, so this method could limit the services you can integrate into such a setup.

Enter single sign-on (SSO). Essentially, SSO is an authentication system that allows users to access multiple unrelated systems after just one login, because that initial login gives them an authentication token that’s trusted by those systems. For example, your company may use separate SaaS solutions in the cloud for human resources, training, CRM and project management. SSO allows users to log in to each of these systems through one central portal, because they all trust the SSO identity provider.

SSO solutions are widespread and compatible with the vast majority of cloud-based SaaS technologies because of the near-universal adoption of the Security Assertion Markup Language (SAML). SaaS technologies that use SAML 2.0 can seamlessly integrate with most SSO providers, as the majority “speak the language” of SAML 2.0.

SSO and AD: a bridge to cloud authentication

All of the major SSO identity platforms, such as Okta Identity Cloud, Google Identity Platform, Azure Active Directory and Ping Identity, have a variation on the concept of the “AD Connector” — a tool that synchronizes your AD user data with the SSO Identity provider. With such a tool, your employees use their AD username and password to log into a cloud-based SaaS tool via your SSO provider. AD makes a secure connection to your SSO identity provider but is otherwise safely walled off from the outside world. All your SaaS applications are able to leverage authentication via SSO because of the ubiquity of the SAML 2.0 standard.

Provisioning users

By utilizing a SAML 2.0-compliant SSO identity provider, you can easily solve the “login question.” The next step is to address provisioning. How do you make SaaS tools aware of those users in the first place? How can you organize the users so the permissions and organizational structure you’ve carefully set up in AD is mirrored in your SaaS tools? Finally, how can you automatically deactivate users in a SaaS tool when you deactivate them in AD?

This is where the System for Cross-domain Identity Management (SCIM) comes in. SCIM is an open standard for communicating user attributes, such as group membership, org membership and permissions, between distinct services. For example, SCIM shares user attributes between AD and an SSO identity provider, or between an SSO provider and a SaaS tool.

SCIM 2.0 is a much newer standard than SAML 2.0 and isn’t quite as ubiquitous. Some SSO providers, such as Okta and Google, use SCIM integrations to make provisioning users a snap. However, Google does not have an interface for setting up provisioning rules in a custom app (for example, a SAML 2.0 SaaS tool that you configured yourself without an official Google app). Some SAML 2.0 identity providers, such as Microsoft’s Active Directory Federation Services, do not support SCIM 2.0 at all.

To solve the “SCIM 2.0 isn’t always available” problem, some cloud-based SaaS applications have developed synchronization tools. For example, Code42’s User Directory Sync synchronizes AD user information via direct one-way communication from the customer’s AD server to the SaaS provider. In this example, Code42 still leverages SSO for user authentication, but user provisioning is made possible via a secure one-way sync.

Embrace the cloud era

The SSO market is fairly crowded, with behemoths like Microsoft and Google going head to head with startups like Okta that focus exclusively on SSO. The fact that these services all speak the same language and endeavor to solve the same problem — leveraging your existing identity management system for cloud authentication — means that tackling this problem has never been easier. The plethora of secure, robust SSO providers makes it easy to transition from your on-prem past to a future in the cloud. With this problem solved, you’ll have time to focus on the other complexities of digital transformation to the cloud, like gaining visibility into where your all of your data is created, stored and shared.

Facebook Twitter Google LinkedIn YouTube