Skip to main content

Role-based Access Control and User Authorization in Nutanix Frame

· 7 min read
William Wong

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.

Platform hierarchy: customer, organization and account

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 group Frame accounts logically together 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 associate the client's cloud infrastructure and identity provider to that Organization entity and then create the client's Frame accounts using that client-specific infrastructure.

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 Platform Hierarchy documentation.


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. A SAML2 groups attribute allows you to specify one or more groups a user belongs to and then write authorization rules using the groups attribute and associated 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.

Platform hierarchy: customer, organization, account, IdP

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 administrators only using your SAML2 IdP ensures administrators will not be double counted as two unique users in a monthly billing cycle.

For further details on how Frame supports user authentication, visit our Authentication Overview.

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.

For further information on the different user roles supported by Frame, visit our Authorization Management documentation.

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).

SAML2 Permission configuration window

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., 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.


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 Wong

More content created by

William Wong
William Wong is the VP of Service Delivery for Dizzion, responsible for service delivery (professional and managed services), solutions architecture, and support. He works actively with customers to transform their business and operations leveraging DaaS in a hybrid and multi-cloud world. Before joining Dizzion as part of the Frame spinout from Nutanix, William was Head of Enterprise Solutions at Frame and following Nutanix's acquisition of Frame in 2018, Director of Solutions Architecture (Frame) at Nutanix. Prior to his work in DaaS, William led the development and adoption of innovative Internet software solutions and services, including Internet-based credit card and check processing and eCommerce platforms. William spent over 30 years at Cancer Commons, NetDeposit, Hewlett-Packard, VeriFone, and multiple Internet, payment, and eCommerce startups in executive management, program management, engineering management, and executive advisory positions. William received his B.S., M.S., and Ph.D. in Electrical Engineering from Stanford University.

© 2024 Dizzion, Inc. All rights reserved. Frame, the Frame logo and all Dizzio product, feature and service names mentioned herein are registered trademarks of Dizzion, Inc. in the United States and other countries. All 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 Dizzion. Dizzion 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. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.