Authorization: Tenant and Role Mapping Examples
Remote Auth requires assignment of roles and tenants for every user login via the authorization mapping rules. Authorization is assessed on every login and the user record is updated. Upon successful user login via an external authentication server, all mapping rules are evaluated; tenant and role pairs are added to user access list.
Examples in this article assume the Avi Controller has been set up for remote authentication. By default, a Controller will have only local authentication established, as shown below.
Tenant and role mapping is only available when Authentication/Authorization is configured with a “Remote” server as opposed to the default “Local”. Clicking the pencil icon causes the below dialog box to appear.
Clicking Remote enables you to either select a pre-existing remote auth profile from the pulldown, or — as in the below case — define a new profile.
Clicking Create above causes the New Auth Profile editor to pop up:
Once the LDAP or TACACS+ remote auth profile has been established, navigating to Administration > Settings > Authentication/Authorization yields a window from which tenant and role mappings may be viewed and/or created.
When the remote server is LDAP, the mapping table can be edited and the options allow us to select Group or Attribute based mapping. When the remote server is TACACS+, the allowed mapping is only based on user Attribute.
Any Group/Any Attribute Rule
A rule with any group or any attribute applies to all users and can be used as a default option. The rule below assigns every user to a least privileged role and tenant (Note, the role and tenant need to configured to only allow least privileges). If the user is not assigned any more role/tenant pairs, the least privileged access will take effect after login.
Super User Rule
A rule can be configured to assign “super user” privileges to a user. This user will have access to all tenants with the most privileged role. Once a user is super user, no other tenant/role mapping assignments will make a difference to the user’s access.
Attribute and Group Match
A mapping rule can be required to match both an attribute and group requirement. This will ensure a more specific assignment of role(s) and tenant(s).
Assign Matching Attribute Values
LDAP/TACACS+ attribute “vantageRole” for a user can have one or more values. For each value, if there is a configured role with the same name, the role is assigned to the user with access to all tenants. A user session can end up with multiple roles and the most privileged role will take effect.
Assign Matching Group Names
A user can be a member of multiple LDAP/AD groups. For each group, if there is a configured tenant, the user will be given access to the tenant, along with any other tenants the user may already have obtained access via matching rules.
Multiple Groups Mapping to Different Roles
This example illustrates the case of an IT team with three user groups — super-admins, app-admins, operations — where the following applies:
- Super Admins:
- may access all tenants, all settings, hence, they are super users.
- Application Admins:
- may only create, read, update and delete virtual services and other profiles.
- may not create clouds.
- Application Operators:
- have read-only access.
Separate mapping rules are required to map users from each group to different role/tenant assignments.
Multiple Groups Mapping to Different Tenants
This example illustrates settings for an IT team that expects tenant isolation except for a few super users.
- can access all tenants, all settings, hence, they are super users.
Tenant Application Admins
- have access to a few tenants — app owner for few tenants
Tenant Application Operators
- have access to a few tenants — cannot modify anything
Tenant Application Admins/Operators
- have access to a few tenants as app owners and other tenants as app operator folks.
In this example, members of group “Service Admins E” have read/write access (Application-Admin role) in tenants Tenant AE and Tenant SE, while they have read only access (Application-Operator role) in a few other tenants. “Service Operators” have only read-only access in their respective tenants.
Multiple Authorizations for a Single User
In this example, login of user John Doe results in the user gaining access via multiple authorization mapping rules.
Multiple mapping rules are configured based on various group and attribute criteria.
The LDAP server is configured with user John Doe.
The LDAP server is configured with John Doe as a member of the groups Enterprise Admins and Service Operators.
After user John Doe logs in and all authorization rules are applied on the user session. Multiple role/tenant combinations are used to determine user privileges during user login. The user record shows the user successfully matched all 4 rules and role/tenant pairs were appropriately applied.
Multiple Authorizations Resulting in a Super User
In this example, login of user John Doe results in the user becoming super user.
Mapping rules make a member of the group “Service Operators” a super user.
Due to the super user access, user John Doe gets access to all tenants with every role.
No Authorizations for a Single User
In this example, login of user John Doe results in the user not getting any roles or tenants.
Mapping rules are updated to keep user John Doe from having any privileges.
When user John Doe logs in, the user interface reports no privileges to login.
User record does not have any access entries.