One of the two biggest ways to improve an organization’s security posture is through good account management and password hygiene.* As the old saying goes, it’s easier said than done. Good account management seems simple enough, but with hundreds of systems and devices in the average organization it’s easy to miss one.
As for passwords, they’re just not secure anymore. We can make passwords complicated, check them against databases of compromised passwords, and rotate them periodically. What happens then? We write them down. If we avoid that, passwords are still very vulnerable to keystroke loggers, malicious web sites, cameras, malware, and even other people “shoulder-surfing” and watching you type.
Multifactor Authentication
Authentication is often described with the term “factors.” Factors are usually three things: something you have, something you are, or something you know. For example, a password is something you know. A fingerprint is something you are. A one-time password token is something you have. Combine these and you get multifactor authentication, or MFA. Combine two of them and you get two-factor authentication, or 2FA.
Multifactor authentication (MFA) is a huge leap forward for account security. With MFA, even if a bad actor knows your password they won’t know the one-time code that shows up on your phone, for instance. Since that code changes every minute it isn’t likely they’ll be able to guess it. Same for a fingerprint — I certainly hope a bad actor doesn’t have your finger!
Multifactor authentication seems like a good idea, right? Even if it wasn’t such a good idea on its own it is mandated in most compliance frameworks. For example, PCI DSS 3.2 added it as a requirement in control 8.3, and NIST 800-53 revision 4 has it listed in the IA set of controls, such as IA-2. While compliance frameworks often allow for “compensating controls” – alternate ways of achieving the same security goal – those can get complicated. It’s easiest for everyone if a software solution addresses the requirement directly. One of our goals with vSphere is to make it easy to be secure.
This is why vSphere 7 has Identity Federation. Identity Federation allows us to attach vCenter Server to enterprise identity providers like Active Directory Federation Services (ADFS). This means that vCenter Server participates in the same centralized corporate processes, such as onboarding and termination. It also means that users can use the same methods to log into vCenter Server as they do their desktops and the cloud. This includes MFA & 2FA solutions as well.
How Identity Federation Works
Once attached to the identity provider (in this case it’s ADFS — more on that below), the vSphere Client will redirect logins to the provider’s login page. The user or admin logs in using their corporate credentials, including any multifactor authentication that is configured as part of the system. Once they’re authenticated, the identity provider redirects them back to the vSphere Client with a cryptographic token that authorizes them. If you’ve ever logged into a web site using your Google, Twitter, or Facebook credentials this will seem very familiar.
Standard Protocols
Identity Federation uses the standard protocols OAUTH2 and OIDC to exchange information. Even with standards, one of the complications is that all authentication systems have different “schemas” for communicating. At VMworld 2019 US fellow technical marketer Mike Foley summarized this well by comparing it to making a phone call. OAUTH2 is the telephone system, but we still might call someone that doesn’t speak our language. As such, vSphere 7 initially supports ADFS because it represents what a large portion of our customers have and can easily use. More options to come as we teach vSphere more authentication “languages.”
If you enable Identity Federation it takes the place of traditional Active Directory, Integrated Windows Authentication, and LDAP/LDAPS authentication methods in vCenter Server. However, it does NOT replace the traditional vSphere Single Sign-on, which is still present for administration & troubleshooting access. Those traditional login methods still exist for now, though some are deprecated (check the release notes).
Conclusion
vSphere Identity Federation is going to be a great step forward for security, a reduction in work for compliance audits, less process duplication in an organization, less work for vSphere Admins, and a better experience for users.
* = the other big way to increase security in an organization is timely & comprehensive patching, and vSphere 7’s new Lifecycle Manager makes that easier, too.
We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.