3 Components of Cloud Authentication: Enterprise SSO, Zero Trust, Passwordless

In the past few years, we’ve seen a rapid expansion in remote and remote-hybrid workforces. Remote employees primarily use cloud-native services to manage their daily workloads from the comfort of their home (or public) internet. This has caused a great deal of stress for IT departments, especially those that rely heavily on their internal infrastructure.  

As organizations accelerate their cloud adoption, we can no longer rely on a “trusted internal network” to protect identities and endpoints. The cybersecurity community has popularized the concept of zero trust as the solution to this problem, effectively treating all networks as hostile. Unfortunately, during the COVID-19 pandemic many organizations took emergency measures to support a remote workforce and did not have the opportunity to vet their cloud readiness.  

The good news is that several components exist for strengthening your cloud presence: 

1. Enterprise SSO – Implement an enterprise identity provider to provide single sign-on (SSO) to your web applications. 

2. Zero Trust – Implement zero trust principles to adopt cloud services securely and reduce the attack surface on your IT systems. 

3. Passwordless Authentication – Adopt phishing-resistant passwordless authentication (e.g., FIDO2). 

ENTERPRISE SSO

Enterprise SSO is achieved at an organization when its employees’ identities are centralized into an identity and access management service that allows users to access multiple applications from a single credential. Many organizations have already implemented federated SSO to integrate with commercial-off-the-shelf (COTS) SaaS applications.  

One of the key security features of federated SSO is that your credentials (e.g., username and password) are verified by your own trusted identity provider. If an external application that a federated user is accessing becomes compromised, the user’s underlying credentials (e.g., password hashes) aren’t stored on the system—which limits the attacker’s ability to move laterally.  

Additionally, a fully integrated enterprise SSO solution should incorporate a variety of signals when verifying every attempt to access an application. Conditional Access in Entra ID (formerly Azure Active Directory), as shown in Figure 1, is a great example. If users, devices, and applications are fully integrated in AAD, an organization can make intelligent decisions when granting access to applications and data.  

ZERO TRUST 

Despite its somewhat philosophical origin almost 30 years ago, the concept of zero trust has gained widespread support from the cybersecurity community in the past 10 years. Globally, national governments and private corporations have published research and technical recommendations on how to implement a zero trust architecture. A good explanation of zero trust is available in the U.S. DoD’s “Embracing a Zero Trust Security Model”:  

“Zero Trust is a security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The Zero Trust security model eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information fed from multiple sources to determine access and other system responses.  

The Zero Trust security model assumes that a breach is inevitable or has likely already occurred, so it constantly limits access to only what is needed and looks for anomalous or malicious activity. Zero Trust embeds comprehensive security monitoring; granular risk-based access controls; and system security automation in a coordinated manner throughout all aspects of the infrastructure in order to focus on protecting critical assets (data) in real-time within a dynamic threat environment. This data-centric security model allows the concept of least-privileged access to be applied for every access decision, allowing or denying access to resources based on the combination of several contextual factors.” 

– U.S. Department of Defense

To work toward a zero trust security model, an organization would need to: 

• Centralize and strengthen authentication for identities and devices 
• Embrace cloud architecture and abandon traditional network perimeter security 

In the traditional VPN-based remote access model, which Figure 2 illustrates, the user must authenticate to their enterprise VPN to access their internal applications. As a result, many of the cloud services the user must access are also routed over VPN. Some applications (e.g., video/audio conferencing platforms such as Microsoft Teams, Slack, and Zoom) are designed to be cloud-native and discourage the use of full-tunnel VPNs due to the network performance impact. This is a clumsy and painful user experience that is inefficient for web applications. It relies on assumptions and assurances about the internal network perimeter that are antithetical to zero trust principles.   

In the zero trust remote access model, the user authenticates directly to their centralized enterprise SSO, which makes a contextual access decision before federating the user to their intended application. In this model, all systems are designed to be cloud-native. Another important detail is that the zero trust model relies on the trustworthiness of the endpoint (e.g., device compliance) when making an access decision. Figure 3 illustrates zero trust architecture. 

PASSWORDLESS AUTHENTICATION 

A foundation of zero trust is enforcing strong authentication for identities with a high degree of assurance that it was performed by the trusted individual. The broader cybersecurity community has rapidly adopted “passwordless authentication”—a strong, phishing-resistant multi-factor authentication (MFA) that is localized and protected within hardware. In general, this involves some sort of trusted device in a user’s physical possession (e.g., phone, laptop, physical security key, etc.) that behaves as a local authenticator and is uniquely registered to the authentication service. By design, passwordless authentication dramatically reduces the likelihood of an account being impersonated from common threat vectors, such as:  

1. Phishing and social engineering attempts  

2. Password leaks from server-side breaches 

3. Password strength and hygiene 

4. Replay attacks 

All the threat vectors listed above are a symptom of the symmetrical nature of online passwords, which are ultimately a “shared secret” between the user and the authentication service and can be stolen from either party.  

Passwordless authentication relies on asymmetric authentication. The user (client) is in physical possession of a trusted, local authenticator with a hardware-protected public/private key pair, and the authentication service (server) registers the user’s public key. In passwordless authentication, you use your localized PIN (or biometric gesture) to unlock your trusted authenticator—which does a cryptographic proof to the server with the private key. If it matches with the public key stored in the authentication service, it grants your authentication. This is one of the reasons PIN complexity recommendations tend to be much different (and frankly, more relaxed) than passwords—since PINs can’t be abused remotely without physical possession of the authenticator. A great example of this concept is the advent of “chip reader” credit cards that use a physical cryptographic chip to ensure it is the unique credit card issued from the bank. 

In addition to being significantly more secure than passwords, passwordless authentication is often much more convenient for end users. A great example of passwordless authentication being a consumer preference for convenience is the increased popularity of unlocking mobile devices with a form of biometric authentication, such as facial recognition or fingerprint. The technology behind Windows Hello (and subsequently Windows Hello for Business—WHfB) is offering comparable convenience and security benefits in Windows 10/11 that have already become largely mainstream for iPhone and Android users.  

Although many of us have been enjoying passwordless authentication on our smartphones for several years now, the idea of using passwordless (typically biometrics) in the workplace may feel uncomfortable. Although biometrics are very convenient, they are not a requirement for passwordless. This is similar to setting a PIN on a smartphone but not registering a fingerprint or facial recognition. You can deploy a passwordless solution, such as WHfB, using only a PIN. Figure 4 illustrates the security and convenience of passwordless authentication.  

There are a few common forms of passwordless authentication: 

1. Physical smart cards (old-school, primarily AD/Windows)  

2. Physical FIDO2 security keys (web-friendly, multi-platform) 

3. WHfB (modern and web-friendly, Windows 10/11) 

4. Passwordless app consent (modern and web-friendly, depends on identity provider) 

Historically, many highly regulated industries use physical smart cards to provide high assurance for their authentication. Smart cards typically rely on complex and brittle PKI configurations with significant shortcomings regarding revocation capabilities that have prevented them from becoming more successful for web authentication. The rapid adoption of FIDO2 across major platforms such as Microsoft, Amazon, and Google has indicated that web authentication will likely continue to favor FIDO2 over traditional smart cards. We typically wouldn’t recommend smart cards for most businesses, for a variety of reasons: cost, complexity, OS/platform limitations, web/mobile friendliness, etc.   

At Ravenswood, we currently recommend WHfB or FIDO2 security keys. WHfB really shines in hybrid AD/AAD environments, where it can provide MFA at the Windows 10/11 logon screen and web-friendly SSO into web applications.  

It’s worth mentioning that the new Microsoft Authenticator “number matching” has gained popularity and is being enforced in Azure Global on May 8, 2023. In this method, after you enter your AAD account you’re immediately asked to enter the number you see in AAD on your Microsoft Authenticator app (see Figure 5). This is highly phishing-resistant because each authentication request generates a different number—unlike one-time passwords (OTPs) or consent prompts, which could be abused remotely in a sophisticated phishing/social engineering attack.  

Entra ID FOR CLOUD AUTHENTICATION 

Leveraging AAD to strengthen your cloud authentication can be an excellent strategy—especially for organizations that are currently using AD and Windows 10 devices. AAD is an enterprise identity provider that incorporates zero trust principles and supports a variety of passwordless authentication options, including WHfB and FIDO2 security keys.  

In the following example, a hypothetical user can access their organization’s internal and external applications with a single AAD identity:  

1. A traditional on-premises AD user (John@TailspinToyCo.org) is synced to AAD. In this case, TailspinToyCo is using AAD as an enterprise SSO solution for centralized management of identities and applications.  

2. When attempting to access one of TailspinToyCo’s many web apps, the AAD account can: 
   • Authenticate directly to internal Microsoft 365 services (e.g., Teams, SharePoint Online, OneDrive, Exchange Online, Power BI)   
   • Federate to external third-party SaaS apps (e.g., ServiceNow, Salesforce, Expensify)  
   • Federate to on-premises apps (e.g., COTS software and internally developed apps)  

Figure 6 illustrates this example.

IN REVIEW 

Although it can be daunting at first, the journey to zero trust architecture and passwordless authentication is often easier than expected. If you have any questions or you’d like a second opinion on your identity architecture, please contact us. We’re here to help.