Manage User Permissions¶
The Frame Platform provides administrators with customizable ways to control user and administrative access to their accounts. Through the Frame Admin interface, administrators are able to assign roles which grant varying levels of access to their users. These same granular controls are available for all authentication types.
Customer and Organization administrators can manage users from the Admin page by clicking on the ellipsis next to the desired entity, selecting “Edit,” and clicking on the “Security” tab. Account administrators manage their users from the “Users” section of their Dashboard.
Roles allow administrators to easily manage the permissions and access levels of their users. Regardless of the authentication type, admins will need to specify the role they wish to grant to their users before they can authenticate.
|Customer Administrator||Highest level of access. Customer admins are able to create and manage multiple organizations and their child accounts. Customer administrators can also modify permissions for any of the user roles listed below.|
|Limited Customer Administrator||Limited Customer admins possess the same permissions as Customer admins for managing organizations and accounts, but do not have the ability to start sessions.|
|Organization Administrator||Organization admins have access to any organizations assigned to them by the Customer or Limited Customer admin, those organizations’ accounts, and any users listed under those accounts. Organization admins can only be created by Customer or Limited Customer admins.|
|Account Administrator||Account admins can access any accounts assigned to them by the Organization, Customer, or Limited Customer admin and any users associated with those accounts.|
|Launchpad User||End users or “Launchpad users” can only access Launchpads that are configured by the administrators. A Launchpad user can access multiple Launchpads from multiple accounts if configured this way by administrators.|
Administrators are able to grant permissions based on their own level of access. For instance, while a Customer admin can assign any role to any user, an Organization admin can only grant the Organization Admin role or below to another user.
You can read more about Xi Frame account hierarchy in the Platform Hierarchy section. Administrators must assign roles when inviting users. They may also modify roles for existing users at any time. If you have not yet invited any users, please refer to the Invite Users section of Xi Frame documentation.
Using Frame as your IdP¶
Admins can use Frame as their Identity Provider (IdP) by using the “Frame (built-in users)” tab and following the user invitation process. If you would like to assign roles through an established SAML2 provider on Frame, please move on to the “Specifying Permissions for SAML2 Users” section.
Administrators can edit user roles at any time from the by clicking on the ellipsis listed next to a user and selecting “Edit.”
Using Google (OAuth2) as your IdP¶
If you have decided to use the G Suite OAuth2 integration through Frame, it’s easy to manage users by domain/email.
First, click on the ellipsis next to the desired entity, select “Edit,” and click on the “Security” tab. From there, click on the “Google” tab and then click “Add.”
A new window will appear prompting you to enter either an email address or a domain. For this example, we will add a domain and give anyone associated with that domain a “Launchpad User” role on the “Applications 2” Launchpad.
When specifying a G Suite domain, you must prefix the domain with the
@ symbol, as shown above.
Admins can also add multiple domains and email addresses under the same role set. For example, using the “Add” button, we have added a single email address along with our domain. The user associated with that email address will be given the same Launchpad User role with access to the “Applications 2” Launchpad.
To add another level of granularity, our domain and single email address can be given additional roles by clicking “Add” below the “Roles” section.
Now, once we click “Add” at the bottom of the window, the domain and single email address will be given “Launchpad User” access on the “Applications 2” Launchpad, and “Account Admin” access on the “Persistent Desktops” account. Administrators can add many Google authorization role sets for multiple domains/email addresses.
Specifying Permissions for SAML2 Users¶
Once you have set up your SAML2 provider integration with Frame, you will need to designate permissions for your users. You can do this by clicking on the “SAML2 Permissions” tab to the right of the “SAML2 Providers” tab. Click “Add Permission.”
- For provider: Select the SAML2 Provider you are designating permissions for.
- Allow access:
- Always: Once the user is authenticated, they have access to the role you specify below – no conditions required.
- When all conditions are satisfied: The user must meet all conditions specified by the Admin to be granted access to the role specified.
- When any condition is satisfied: The user can meet any conditions specified by the Admin to be granted access to the role specified.
- Conditions: Specify your assertion claims and their values which will correspond with the roles you wish to grant. Reference the table below for our accepted assertion claims.
- Grant roles: Select the desired roles you wish to grant to your users. You can add multiple role sets by using the “Add” button. Reference the roles section above for more information.
Click “Save” when you are done. Administrators can add multiple permission sets under the “SAML2 Permissions” section.
When qualifying users by domain, it is best practice to use “em ends with @yourcompany.com.”
|Assertion Claim||Claim Value||Example|
During the IdP setup, you may have used “mail” to define the email attribute. While this is fine for the IdP, you must use “em” to reference the email attribute when configuring SAML2 permissions on Frame.
Use any Attribute with SAML2 on Frame¶
When creating SAML2 permissions on Frame, admins may use custom attributes from their IdP by setting specific permissions settings. For this example, we will use a very common custom attribute – “groups.” Most IdPs provide ways to “group” users and these groups can be passed to Frame via custom attribute mappings. Using additional attribute maps, you can build conditions for varying roles and access privileges.
Here is an example of where you would set group statements in Okta:
Here is an example of a list of groups in Okta:
This is how we would pass one of the groups (“Okta-Contractors”) over to Frame, allowing administrators to create rules and roles to meet their needs.
With the configuration above, any users from the “Okta-Contractors” group signing into Frame will be given Account Administrator access to the “Contractor Account.”
All identity providers use different methods to manage user groups, please consult your IdP’s documentation for more information about groups and group management.