Blog

Role-based Access Control and User Authorization in Nutanix Frame

by William Wong (Director, Frame Solutions Architecture), william.wong@nutanix.com

Introduction

The Nutanix Frame™ desktop-as-a-service platform enables customers to implement proper user authentication and authorization security practices with Role-Based Access Control (RBAC) through a set of security roles defined within the Frame platform. In this blog, we’ll explain how RBAC works in Frame and discuss the best practices for using third-party SAML2 identity providers and authorization rules to implement RBAC. The Frame-defined security roles specify the level of access to Frame entity types (customer, organization, account) and what can be done in those entity types. Using these Frame roles, you can configure one or more SAML2 or OAuth2 identity providers (IdPs) and then define authorization rules that grant authenticated users one or more of the Frame roles on specific Frame entities.

Frame Platform Hierarchy

The use of Frame’s authentication and authorization capabilities requires an understanding of Frame’s 3-tiered platform hierarchy as you must determine at which level(s) of Frame’s 3-tiered platform hierarchy should your organization’s IdP and authorization rules be defined. The Frame platform hierarchy is depicted in Figure 1.

Figure 1

Customer Entity

At the top of the Frame hierarchy is the “Customer” entity. When you create a 30-day Frame free trial or activate your paid Frame subscription, Nutanix automatically creates the Customer entity. Once you create the free trial subscription or activate your paid subscription, you can then login to My Nutanix and access your Frame Customer entity. As the first user, you will be assigned the Customer Administrator role, you can then register your public or private cloud infrastructure and configure an identity provider for your other administrators and end users. 

Implementation Best Practices: As a general rule, associate your public or private cloud infrastructure and identity provider(s) to your Customer entity. This enables you to create Frame accounts and define authorization rules leveraging your identity provider(s) across all organizations and accounts.

Organization Entity

You also can create one or more “Organization” entities in Frame. This second-level entity type is used to logically group Frame accounts based on customer requirements. Organization entities are being used to separate Frame accounts by company departments or divisions, for a service development lifecycle (development/test/production), by subsidiaries, or for different geographic regions. Managed service providers can create an Organization entity for each client to logically group the client’s Frame accounts and associate the client’s cloud infrastructure and identity provider to that organization entity.

Frame Account

At the third “Account” level of the hierarchy, the Frame Account contains the Sandbox used to build and maintain the OS and applications, the pools of non-persistent or persistent VMs for users, utility server(s), and configuration settings that define the end user experience. The infrastructure resources associated with the Frame Account are created using the public or private cloud infrastructure you registered earlier.

For more details on the Frame platform hierarchy, consult with the Frame Documenation at https://docs.frame.nutanix.com/account-management/platform-hierarchy.html.

Authentication

You will want to have at least one identity provider configured in your Frame Customer entity so you and your users have a way to access Frame. For enterprise use cases, the most common type of identity provider is a third-party SAML2 identity provider such as Azure Active Directory or Okta. Third-party SAML2 IdPs enable you to satisfy multi-factor as well as user-, endpoint-, and network-context authentication requirements.

With SAML2 identity providers, user credentials are never received by the Frame Platform. The user authenticates directly to the IdP and the IdP returns the SAML2 Authentication Response message to the Frame Platform via the user’s browser following a successful user authentication event.

Implementation Best Practices: In addition to the standard SAML2 attributes for email address, first name (given name), and last name (surname), configure your SAML2 IdP to include a SAML2 groups attribute. The groups attribute allows you to specify one or more groups a user belongs to and then write authorization rules using the groups attribute and associate values, rather than individual user identities. This simplifies the number of authorization rules in Frame and keeps user authorization policies within your identity provider. For most enterprises, the groups attribute value would come from the list of Windows Active Directory groups a user is assigned.

If you are a managed service provider in the Nutanix Elevate Service Provider Program  delivering a service to your clients, configure your SAML2 IdP at the Customer entity level. If you offer your clients the ability for them to bring their own SAML2 IdP, configure each of your client’s IdP on their respective Organization entity.

Figure 2

Implementation Best Practices: Once you have configured a third-party SAML2 provider at the Customer entity level and have verified the SAML2 authorization rules for your Frame administrators, have your administrators use your SAML2 provider, rather than My Nutanix to access Frame. For customers who have subscribed to named user subscriptions, having your users only using your SAML2 IdP ensures administrators will not be double counted as two unique users in a monthly billing cycle.

Refer to the Frame Documentation for further details on how Frame supports user authentication.

Frame User Roles

In order for you to be able to grant your users the minimum level of privileges they need, Nutanix Frame has defined over 20 Frame-specific administrator, support and user roles. These roles provide assigned users with administrator, security administrator, read-only administrator, and/or analyst (reporting) privileges at each of the three levels of the platform hierarchy or support/help desk or restricted administrator at the account level. Lastly, for end users, there is a Launchpad role for granting these users access to one or more Launchpads to start virtualized application or desktop sessions in one or more Frame accounts.

Implementation Best Practices: Initially, you will start with administrative users and end users who will be assigned the Customer Administrator and Launchpad User roles, respectively. Enterprises with support/help desks will want to use the Account Support role.

Refer to the Frame Documentation for further details on the different user roles.

Configuring RBAC for Users

Once you have configured your SAML2 identity provider at the customer or organization entity level, you are now able to create authorization rules (“SAML2 Permissions”) at the same entity level or at a lower level in the hierarchy.

A Frame SAML2 Permission definition consists of:

  • SAML2 IdP Integration Name
  • Conditions evaluation (always, Boolean AND, Boolean OR)
  • One or more conditions
  • One or more roles, with each role defined on a Frame entity (customer, organization, account, Launchpad).

In the below illustration, the SAML2 IdP Integration Name is “nutanix-demo-ahv” and the Conditions evaluation will be a Boolean AND (if there are two or more Conditions defined).

Figure 3

In the above example, when the user’s SAML2 IdP provides a SAML2 Authentication Response message to Frame containing the SAML2 attribute “groups” with a value “Sales Engineering”, then Frame will grant the authenticated user the “Launchpad User” role on the Launchpad “Desktop” defined in the Frame account “William Wong 7.23.X”. The user will be able to then access a virtual desktop within the specified account.

Depending on the SAML2 IdP, the “groups” attribute name may be a URL (e.g., http://schemas.microsoft.com/ws/2008/06/identity/claims/groups for Azure AD or a simple string for Okta).

Implementation Best Practices: In general, use the “contains” operator when specifying a Condition, rather than “equals”, especially if the SAML2 IdP will return a list of values for the SAML2 attribute.

For further information on SAML2 Permissions, visit our SAML2 Permissions documentation.

Conclusion

Nutanix Frame enables you to enforce role-based access control across your Frame customer tenant and down to your Frame accounts. You can create fine-grained authorization rules with your SAML2 identity provider providing the SAML2 response to Frame that includes a SAML2 groups attribute. Within Frame as part of the SAML2 Permission definitions, the SAML2 groups attribute and associate value(s) can then determine the assignment of the user to specific Frame role(s) the desired customer, organization, account, and/or Launchpad entities.

William is Director, Solutions Architecture for Nutanix Frame, working with global enterprises and software companies to leverage Frame DaaS in a multi-cloud world. William spent over twenty five years at Cancer Commons, NetDeposit, Hewlett-Packard, VeriFone, and multiple Internet, payment, and eCommerce startups in executive management, program management, engineering, and executive advisory positions. William received his B.S., M.S., and Ph.D. in Electrical Engineering from Stanford University.

© 2021 Nutanix, Inc.  All rights reserved. Nutanix, the Nutanix logo and all Nutanix product, feature and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. This post may contain express and implied forward-looking statements, which are not historical facts and are instead based on our current expectations, estimates and beliefs. The accuracy of such statements involves risks and uncertainties and depends upon future events, including those that may be beyond our control, and actual results may differ materially and adversely from those anticipated or implied by such statements. Any forward-looking statements included herein speak only as of the date hereof and, except as required by law, we assume no obligation to update or otherwise revise any of such forward-looking statements to reflect subsequent events or circumstances.