When you create a user-defined role, you must define the match criteria that determines which identities will use the role. The match criteria is a group of identity attributes and the attribute values that must match identities to which this role is assigned. For example, the following command creates a role named US-Engr that matches employees whose title is Engineer and who work in United States:
create identity-management role US-Engr match-criteria "title contains Engineer; AND country == US;" priority 100
The match criteria are a series of attributes, operators, and attribute values, all of which are described in the ExtremeXOS 32.2 Command Reference Guide . Each role can define up to 16 attribute requirements, and there are additional operators such as not equal. Beginning in ExtremeXOS 15.3, the match criteria attributes are combined using the AND or OR operators, not a combination of both. When multiple roles are matched to an identity, the role with the highest priority (lowest numerical value) applies.
In the preceding example, identity manager must be configured to query an LDAP server because the identity attributes listed in the match criteria are not discovered locally.
The match criteria for a role establish the role as on of two types:
A local user-defined role uses only the following locally discovered attributes (which are listed in the following table) in the match criteria:
Because a local user-defined role does not require LDAP provided attributes, the role can be matched to identities when an LDAP server is unavailable, or when LDAP processing is disabled for network login authenticated identities. A local user-defined role can serve as a backup role to an LDAP user-defined role.
An LDAP user-defined role uses one or more of the LDAP attributes listed in Identity Attributes on an LDAP Server in the match criteria, and it can also use the attributes listed in Identity Information Capture. An LDAP user-defined role gives you more flexibility in selecting attributes for the match criteria. However, if no LDAP server is available, and the identity attributes do not match a local user-defined role, one of the two default roles is applied to the identity.
Previously, the policy or dynamic rule associated to the role occurred in the order of configuration. There was no way for you to change the order of the policy or dynamic rule associated with the role. ExtremeXOS 15.2 supported the ability to change the order of the policy or dynamic rule associated with the role. You can also change the order of the policy or dynamic rule during the run time. Even if the role is assigned to some identities, the policy or the dynamic rule associated to the role can be changed.
To make it easier to manage users, the role management feature supports hierarchical roles. Hierarchical roles can be defined to reflect different organizational and functional structures. To create a role hierarchy, one or more roles are defined as child roles of what becomes a parent role. Each role can have a maximum of eight child roles and only one parent role. This feature can support up to five levels of parent and child roles. With respect to role hierarchy and match criteria, there is no restriction across roles. Beginning in 15.3 release, a user can have the parent role with AND, and the child role with OR, or vice versa. The inheritance of match criteria to the child role from the parent role uses AND as in previous releases.
Child roles inherit the policies of the parent role and all roles above the parent in the hierarchy. When an identity is assigned to a role, the policies and rules defined by that role and all higher roles in the hierarchy are applied.
When the parent role is deleted or when the parent-child relationship is deleted, the child role no longer inherits the parent role's policies and the policies are immediately removed from all identities mapped to the child role.
Because the maximum role hierarchy depth allowed is five levels, the maximum number of policies and dynamic ACLs that can be applied to a role is 40 (five role levels x eight policies/rules per role). Hierarchical Role Management Example shows an example of hierarchical role management.
Beginning in release 15.2, the child role can inherit the match criteria of the parent role.
This means that the match criteria does not need to be duplicated in all levels of hierarchy.
For example, if you have roles called Employee, India employee, and India engineer in a hierarchy, previously the match criteria of the three roles would have been:
“company == Extreme” “company == Extreme; AND country == India” “company == Extreme; AND country == India; AND department = Engineering”
This can be simplified into the following since the child role automatically inherits the parent role‘s match criteria:
“company == Extreme” “country == India” “department = Engineering”
Once this support is enabled, user identity must satisfy not only the role‘s match criteria, but its parent and ancestors also. This support can be enabled/disabled using CLI or XML. You no longer have to repeat the match criteria configured in the parent role in the child roles also.
Note
For example, Role A and Role B have match criteria MC-A and MC-B, respectively. Role B is a child role of Role A. When match criteria inheritance is disabled, an identity matches Role B criteria, and then it is placed under Role B with no further check.
When match criteria inheritance is enabled, the same identity, after satisfying Role B‘s match criteria, is then checked against Role A‘s match criteria. Once the identity satisfies child and parent match criteria, it is placed under Role B.
Examples: create identity-management role "EniBuildservers" match-criteria match-criteria "userName contains enibuild; OR ip-address == 10.120.89.0/24;This example creates a role for enibuild servers, whose name contain enibuild or whose ip-addresses are in the range 10.120.89.1 - 10.120.89.255.
If the parent role has the match criteria as "company == Extreme" AND "Title == Manager;" And the child role has the match criteria as "country == India;" OR "country == USA" And the grandchild has the match criteria as "department == Engineering"
All the managers who belong to Extreme Engineering, from both India and the USA, will be placed in the grandchild role.
Context based roles apply additional rules or policies to a port based on context related attributes for an identity. For example, consider a campus environment where a student logs into the network through a PC and also through a smart phone. Suppose that a role named Student already exists and applies basic policies for a student. Also suppose that the administrator wants to apply additional policies for students accessing the network through smart phones.
To apply the additional policies, the administrator can create a role called Student_smartPhone as a child role of Student. The match criteria could include "title == Student; AND mac-oui == 00:1b:63:00:00:00/FF:FF:FF:00:00:00;", where the MAC address is the address of the smart phone. The additional policies can be added to the new child role. When the student logs in from the PC, the rules applicable to the Student role apply. When the student logs in from the smart phone, the policies for the Student_smartPhone role apply, in addition to those inherited from the Student role.
Note
A student logging on through a smart phone is placed under the Student_smartPhone role only if that role has a higher priority (lower numerical value) than the Student role.