vRealize Automation 7 – Part 5, Identity Management

Moving right along with the next spotlight feature in vRealize Automation 7 — a totally revamped access control and authentication system brought to you by VMware Identity Manager (vIDM). What may appear as an insignificant move from 6.x’s standalone Identity Appliance (IDVA aka vCenter SSO/PSC) is actually one of the most important additions to the new platform. Allow me to elaborate…

vIDM is the result of VMware’s acquisition of TriCipher about 5 years ago (August 2010), which has gone through several iterations and has become — or will become — the de facto policy-based identity platform across VMware broader portfolio (beyond vCenter, of course). Today, it is most notably leveraged by the Horizon suite and, more recently, as a stand-alone Identity Management solution available as an on-prem or SaaS offering. Out of the gate, vIDM brings scalability, performance, and policy-based management and access controls to whichever solution it is natively integrated with. This is especially true (re: performance/scaleability) when access into said solution is extended to the entire enterprise. And with that, it was almost a no-brainer that VMware’s Cloud Management BU has chosen vIDM as it’s standard for the next-gen CMP solution, starting with vRA 7.0.

The Identity Problem

To get a better understanding of why this was a critical move for vRA, we need to understand some of current limitations and restrictions brought on by the IDVA. vRA 6.x leverages vCenter SSO for identity management and has done so since vCAC 6.0. This is delivered as a stand-alone virtual appliance that is deployed alongside vRA. Or, alternatively, customers can use and existing vCenter SSO instance, which is a requirement for distributed/HA implementations. While vCenter SSO is great and delivers what it needs to do for the vCenter access profile, the vRA access profile is quite different. SSO was designed to support authentication and identity management for dozens — maybe hundreds (eek!) — of administrators performing very specific vAdmin tasks. In contrast, vRA is designed to deliver a slew of applications and services to the entire enterprise, across heterogeneous platforms and hybrid clouds….potentially by hundreds of thousands of users with unique usage patterns. Access is also requested by headless controls — the API calls, CloudClient, vRO workflows, 3rd party callers, and so on. Such a profile can quickly scale beyond manageability and create a strain on the identity provider(s) and, ultimately, impact overall performance and usability of vRA. SSO is simply not designed for this. vIDM simply is.

Beyond scale, there’s also the [3rd party] integration factor. Many customers today require additional authentication and access controls that often require 3rd party auth provider (e.g. 2FA / MFA). Again, vCenter SSO is simply not designed for these use cases (yet). This is a significant pain point for customers delivering vRA in highly-compliant or regulated environments. Coming from Public Sector myself, I could not agree more with that sentiment. This is significant move and in many cases can be the difference between vRA in a POC and vRA in production. Then there’s the issue of scalability — vIDM is tested to scale at millions of objects, syncs all desired users and groups to the local DB, and allows for granular controls over what to sync (e.g. sync everything or just the users of a specific OU nested deep inside AD). It also allows you to create sync filters (e.g. “entire directory except any user that contains admin”).

The Identity Solution

Starting with vRA 7.0, vIDM takes on the onus of managing user/consumer authentication, roles/permissions, and overall access into vRA by means of federated identity brokering. vIDM has been embedded directly into vRA 7’s codebase and is now the primary identity provider, adding OOTB support for Two-Factor / Multi-Factor authentication providers, SAML 2.0, OAuth2 token support, policy-based access controls and several additional enhancements.This is also true for headless (API) and, by extension, CloudClient access into the platform. Additionally, vRO 7 and vRB 7 will now support OAuth2 access tokens for native SSO integration with vRA’s policies.

Authentication providers supported OOTB with vIDM+vRA 7:

• Local – local UN/PW fully supported
• Password – standard, single factor password auth with basic AD configuration
• Kerberos – ticketing for passing credentials across sessions (e.g. Desktop login -> vRA login)
• Certificate – cert authentication, smartcard integrations, X.509 support
• RSA SecurID – agent for SecurID, token-based auth
• RADIUS – 2FA with RADIUS backend
• RSA Adaptive Authentication – leverage RSA Policy Management for risk assessment-based auth
• SAML 2.0* – other SAML providers

*In addition to this list, incorporating vIDM into vRA adds a huge library of SAML 2.0 providers as potential auth sources.

vIDM Policy Management

vIDM is policy-driven and adds a significant amount capability over the IDVA. vRA 7 customers will gain many of the OOTB capabilities of the stand-alone vIDM product and be able to configure and manage these features directly with the vRA UI. For anyone who has used vIDM as a stand-alone solution or as part of another product (e.g. Horizon Workspace), configuring vIDM will be just as straight forward. But even if you’ve never configured it before, it is intuitive and walks you through the logical steps of setting up auth sources and advanced policies…

For Active Directory integration, vIDM Directories (local) are configured to sync with one (single domain) or more (multi-domain, multi-forest) architectures. AD can be configured as the exclusive provider, a backup (e.g. when 2FA fails), or as part of a more complex authentication policy. Several AD-specific policies are available to fit most use cases (current limitation in vRA 6.x). vRA itself does not query AD directly. Instead, only the vIDM Connector communicates with the configured AD providers and performs a database sync (AD -> Local vPostgresDB) based on the configured sync policy.

The Sync Frequency determines how often a sync is invoked. This will vary depending on environmental factors (e.g. # of objects, rate of change, etc).

Once a directory is configured, the available Active Directory Domains are listed and can be selected for inclusion.

Mapped Attributes provide a way of adding provider-specific attributes into vRA’s logic. For example, mapping the “Manager” attribute from Active Directory will expose the associated field/data to vRA’s approval engine, allowing the listed manager to be notified during the governance workflow. Attributes can be added or changed in the User Attributes section.

One or more Group DN’s can be added in the Groups tab. You select all the groups within that DN or select a subset. Several disparate directory groups (and subsets) can get added into a single policy. The groups are then adding to vIDM’s sync schedule.

Similar to Groups, Users are adding using one or more directory DN’s. You can also create filters based on a number of attributes to ensure non-user (e.g. service) or admin accounts aren’t synced with the directory.

Policies are configured to define a set of rules for accessing vRA. For example, you can create a policy based on access location (e.g. network subnet, range, etc) or device type and trigger an authentication mechanism based on a policy match. This can be handy when providing external access into vRA — a policy can be created to enforce 2FA (e.g. SmartCard or Cert) when accessing vRA from non-corp networks or from any user connecting from a Windows 10 machine (because, you know…Windows).

Network Ranges are a prerequisite for defining a subnet for use by a Policy (above).

Branding

Finally, vIDM adds per-tenant branding capabilities to the login screen…point and click configuration for branding vRA’s login wallpaper and logo. Customizing the look and feel of the overall UI (color scheme, naming, branding logos, footer and header, etc) is also still supported.

Final Thoughts

While vCenter SSO has taken a back seat in favor for vIDM, customers can still choose to leverage it. Configuration is performed in the VAMI after installation, just as it is with 6.x. Note that vRA 7 will not ship with a stand-alone IDVA, but instead you’ll integrate into an existing vCenter SSO/PSC instance or a new one dedicated to vRA. Also keep in mind that there is no hybrid mode — it’s an either/or configuration. My advice: stick to vIDM!

As mentioned in Parts 2 and 3 in this series, the vIDM components are embedded into the vRA VA and are automatically deployed and clustered by the wizard in an HA deployment. Customers moving to vRA 7 get vIDM fully integrated and at no additional cost (i.e. no need to license the vIDM solution separately). Existing vRA 6.2.x environment leveraging IDVA or vCenter SSO can migrate their Identity Stores to vIDM Directories using the included Identity Stores Migration Tool.

Incorporating vIDM into vRA was a critical move and one that will certainly prove to drive adoption of the platform. Considering the additional use cases possible by adding 2FA/MFA and SAML 2.0 support to any vRA Endpoint (e.g. AWS, Openstack), you can imaging the business value this will deliver. I’ll be posting something on that exact topic very soon.

 

+++++

virtualjad