Country / Region
- Products and Solutions
- Industry Solutions
- Services
- Support
- Training & Certification
- Partners
- About Us
- Contact Sales
- Become a Partner
-
Login
Country / Region
RBAC Technology White Paper
Copyright © 2018 New H3C Technologies Co., Ltd. All rights reserved. No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd. The information in this document is subject to change without notice. |
|
Overview
Role-based access control (RBAC) controls user access to items and system resources based on user roles. In this document, items include commands, Web pages, XML elements, and MIB nodes, and system resources include interfaces, VLANs, VPN instances, and security zones. This document describes the RBAC basic idea and its implementation.
Technical background
The data centers and virtualization in large networks require more granular and flexible user access control. The traditional user-based access control cannot meet the requirements. RBAC is used to improve user access control efficiency and reduce permission management and maintenance costs.
RBAC assigns access permissions to user roles that are created for different job functions. Users are given permission to access a set of items and resources based on the users' user roles.
Benefits
RBAC introduces the concept of user roles. Because user roles are persistent, in contrast to users, separating permissions from users enables easy permission authorization management. You only need to change the user role permissions, remove user roles, or assign new user roles in case of user changes. In addition, RBAC employs resources access policies to specify which interfaces, VLANs, VPNs, and security zones are accessible to user roles.
RBAC implementation
Concepts
Account
To implement authentication and authorization, Comware allows creating accounts and account attributes for users. User accounts include the following types:
Device management account—Users use the account to log in to the device for device management. RBAC controls access to devices by managing accounts of this type.
Network access account—Users use this account to access network resources through the device.
Action
An operation performed by a user to the system. For example, the user configures functions at the CLI or in the Web interface, or display device running status in the GUI.
Command type
Controls access to the system by the following action types:
Read—Commands that display configuration and running information.
Write—Commands that configure the system.
Execute—Commands that execute specific functions. Examples include the ping command and the ftp command. Such commands do not affect system running status.
Feature
A set of commands related to a function. For example, OSPF feature contains all OSPF configuration, displaying, and debugging commands.
Feature group
A set of features. Use feature groups to bulk assign command access permissions to sets of features.
Role
A user role with permission assigned includes a set of rules and resource access policies. The rules specify commands, Web pages, XML elements, and MIB nodes accessible or inaccessible to the role. The policies specify which interfaces, VLANs, VPNs, and security zones are accessible to the role.
Rule
User role rules permit or deny access to commands, Web pages, XML elements, and MIB nodes. You can define the following types of rules for different access control granularities:
Command rule
Feature rule
Feature group rule
Web menu rule
XML element rule
OID rule
For more information, see "Access control granularities."
A user role can have multiple rules uniquely identified by rule numbers. The set of permitted commands, Web pages, XML elements, and MIB nodes in these rules are accessible to the user role.
The following guidelines apply to non-OID rules:
If two user-defined rules of the same type conflict, the rule with the higher ID takes effect. For example, a user role can use the tracert command but not the ping command if the user role contains rules configured by using the following commands:
rule 1 permit command pingrule 2 permit command tracertrule 3 deny command pingIf a predefined user role rule and a user-defined user role rule conflict, the user-defined user role rule takes effect.
The following guidelines apply to OID rules:
The system compares an OID with the OIDs specified in user role rules, and it uses the longest match principle to select a rule for the OID. For example, a user role cannot access the MIB node with OID 1.3.6.1.4.1.25506.141.3.0.1 if the user role contains rules configured by using the following commands:
rule 1 permit read write oid 1.3.6rule 2 deny read write oid 1.3.6.1.4.1rule 3 permit read write oid 1.3.6.1.4If the same OID is specified in multiple rules, the rule with the higher ID takes effect. For example, a user role can access the MIB node with OID 1.3.6.1.4.1.25506.141.3.0.1 if the user role contains rules configured by using the following commands:
rule 1 permit read write oid 1.3.6rule 2 deny read write oid 1.3.6.1.4.1Resource access policy
Resource access policies control access of user roles to system resources and include the following types:
Interface policy—Controls access to interfaces.
VLAN policy—Controls access to VLANs.
VPN instance policy—Controls access to VPNs.
Security zone policy—Controls access to security zones.
Mechanism
User role assignment
You assign access rights to a user by assigning a minimum of one user role.
Depending on the authentication method, user role assignment has the following methods:
AAA authorization—If scheme authentication is used, the AAA module handles user role assignment.
If the user passes local authorization, the device assigns the user roles specified in the local user account.If the user passes remote authorization, the remote AAA server assigns the user roles specified on the server.Non-AAA authorization—When the user accesses the device without authentication or by passing password authentication on a user line, the device assigns user roles specified on the user line.
Permission assignment
The users can use the collection of items and resources accessible to all user roles assigned to the user. The system obtains the system configuration based on the user role, and forms a user role rule table and a resource access policy table.
A user role rule includes rule ID, permission (permit or deny), rule type (CLI, Web, XML, or SNMP), command type (read, write, or execute), and rule content.
A resource access policy includes resource type (VLAN, interface, VPN, or security zone), permission (permit or deny), resource identification (VLAN ID, interface name, VPN name, or security zone name).
A user that logs in with a user role has the two tables, and the collection of items and resources are accessible to the role assigned to the user.
To use a command related to a specific interface, VLAN, VPN, or security zone, a user role must have access to both the command and the interface, VLAN, VPN, or security zone. For example, a user role has access to the qos apply policy command and access only to interface Ethernet 1/1. When the user role is assigned, you can enter the interface view and use the qos apply policy command on the interface. However, you cannot enter the view of any other interface or use the command on any other interface. If the user role has access to any interface but does not have access to the qos apply policy command, you cannot use the command on any interface.
Role-based access control
When a user operates at the CLI or through other tools, the system looks up the user role rule table for the permissions assigned to the user. Both the user role rule table and the resource access policy table define the permissions to specific resources. The following describes the process:
1. The system detects that the user entered a command, for example, vlan 1.
2. The system performs a rule table lookup.
a. The lookup starts from the rule with the highest ID. The system does not stop searching until it finds a command rule.
b. The system compares vlan 1 with the regular expression of the rule content. If it matches, the system returns the permission to the user. If it does not match, it continues searching the next rule.
3. If the return permission is operation permitted, the system looks up the resource access policy table.
The command vlan 1 is to operate the VLAN resources, so the system checks the resource control entry of the VLAN type.
If VLAN 1 is permitted, the command vlan 1 is permitted.If VLAN 1 is denied, the system denies executing the command vlan 1, and it returns the message "Permission denied."4. If the return permission is operation denied, a message appears, telling the user "Permission denied."
Comware implementation of RBAC
Pre-defined user roles
The system provides multiple predefined user roles. All these user roles have access to all system resources (interfaces, VLANs, VPNs, and security zones). However, their access permissions differ, as shown in Table 1.
Table 1 Predefined roles and permissions matrix
User role name | Permissions |
network-admin | Accesses all features and resources in the system, except for the display security-logfile summary, info-center security-logfile directory, and security-logfile save commands. |
network-operator | Accesses the display commands for all features and resources in the system. To display all accessible commands of the user role, use the display role command. Changes between MDC views. Enables local authentication login users to change their own passwords. Accesses the command used for entering XML view. Accesses all read-type Web menu items. Accesses all read-type XML elements. Accesses all read-type MIB nodes. |
mdc-admin | Accesses all the features and resources in the administered MDC, except for the display security-logfile summary, info-center security-logfile directory, and security-logfile save commands. |
mdc-operator | Accesses the display commands for all features and resources available in the administered MDC. To display all accessible commands of the user role, use the display role command. Enables local authentication login users to change their own passwords. Accesses the command used for entering XML view. Accesses all read-type Web menu items. Accesses all read-type XML elements. Accesses all read-type MIB nodes. |
level-n (n = 0 to 15) | level-0—Has access to diagnostic commands, including ping, tracert, ssh2, telnet, and super. Level-0 access rights are configurable. level-1—Has access to the display commands of all features and resources in the system except display history-command all. The level-1 user role also has access rights of the user role level-0. Level-1 access rights are configurable. level-2 to level-8, and level-10 to level-14—Have no access rights by default. Access rights are configurable. level-9—Has access to all features and resources except those in the following list. If you are logged in with a local user account that has a level-9 user role, you can change the password in the local user account. Level-9 access rights are configurable. RBAC non-debugging commands. Local users. MDCs. File management. Device management. The display history-command all command. level-15—Has the same rights as network-admin on a device that does not support MDC or context. level-15—Has the same rights as network-admin on the default MDC, and has the same rights as mdc-admin on non-default MDCs. level-15—Has the same rights as network-admin on the default context, and has the same rights as context-admin on non-default contexts. |
security-audit | Security log manager. The user role has the following access rights to security log files: Accesses to the commands for managing security log files and security log file system (for example, the info-center security-logfile directory, mkdir, and security-logfile save commands). Accesses to the commands for displaying and maintaining security log files (for example, the dir, display security-logfile summary, and more commands).
Only the security-audit user role has access to security log files. You cannot assign the security-audit user role to non-AAA authentication users. |
Accesses all features and resources in the context, except for the display security-logfile summary, info-center security-logfile directory, and security-logfile save commands. | |
Accesses the display commands for features and resources available in the context. To display all accessible commands of the user role, use the display role command. Enables local authentication login users to change their own passwords. Accesses the command used for entering XML view. Accesses all read-type Web menu items. Accesses all read-type XML elements. Accesses all read-type MIB nodes. |
IMPORTANT:Flexible access control
Access control granularities
Command rule
A command rule controls access to a command or a set of commands that match a regular expression.
The permit or deny keyword specifies the access permission and the command-string argument specifies a command or a set of commands.
Feature rule
A feature rule controls access to the commands of a feature by command type.
The permit or deny keyword specifies the access permission. The feature-name argument specifies a feature. The execute, read, or write keyword specifies the execute, read, or write command of a feature. If no feature is specified, you specify all the features in the system.
Feature group rule
A feature group rule controls access to commands of a group of features by command type.
The permit or deny keyword specifies the access permission. The feature-group-name argument specifies a feature group. The execute, read, or write keyword specifies the execute, read, or write command of a feature group.
Use feature groups to bulk assign command access permissions to sets of features.
Web menu rule
A Web menu rule controls access to the Web pages used for configuring the device. These Web pages are called Web menus.
The permit or deny keyword specifies the access permission. The web-menu argument specifies the ID path of the Web menu. The execute, read, or write keyword specifies the execute, read, or write operation of the menu. If no Web menu is specified, you specify all Web menus in the system.
XML element rule
An XML element rule controls access to the XML elements used for configuring the device.
The permit or deny keyword specifies the access permission. The xml-path argument specifies the Xpath of an XML element. The execute, read, or write keyword specifies the execute, read, or write operation of an XML element. If no path is specified, you specify all XML elements in the system.
OID rule
An OID rule controls SNMP access to a MIB node and its child nodes.
The permit or deny keyword specifies the access permission. The oid-string argument represents the OID. The execute, read, or write keyword specifies the execute, read, or write operation of a MIB node.
Access control to file system
You can configure a feature rule with the filesystem keyword to control access to the file system at the CLI.
Access to the file system commands is controlled by both the file system command rules and the system feature rules.
Access control of read and write to the file system affects the upload and download operation permission for FTP users.
A command with output redirection to the file system is permitted only when the command type write is assigned to the file system feature.
User role assignment methods
Assigning user roles to remote AAA authentication users
An AAA authentication user must have a minimum of one user role to log in to the device.
The default user role feature enables a remote AAA authenticated user that has not been assigned any user role to log in with a default user role.
For login to the device that does not support MDC, the default user role is network-operator.
For login to the default MDC, the default user role is network-operator.
For login to a non-default MDC, the default user role is mdc-operator.
For login to the default context, the default user role is network-operator.
For login to a non-default context, the default user role is context-operator.
User roles are configured on the authentication server. For information about configuring user roles for RADIUS users, see the RADIUS server documentation. For HWTACACS users, the role configuration must use the roles="role-1 role-2 … role-n" format, where user roles are space separated. For example, configure roles="level-0 level-1 level-2" to assign level-0, level-1, and level-2 to an HWTACACS user.
Assigning user roles to local AAA authentication users
Configure user roles for local AAA authentication users in their local user accounts. Every local user has a default user role. If this default user role is not suitable, delete it.
Assigning user roles to non-AAA authentication users on user lines
Specify user roles for the following types of login users on the user lines:
Users that use password authentication or no authentication.
SSH clients that use publickey or password-publickey authentication. User roles assigned to these SSH clients are specified in their local management user accounts.
Temporary user role authorization
Temporary user role authorization allows you to obtain a temporary user role without reconnecting to the device. This feature is useful when you want to use a user role temporarily to configure a feature.
Temporary user role authorization is effective only on the current login. It does not change the user role settings in the user account that you have been logged in with. The next time you are logged in with the user account, the original user role settings take effect.
Application scenarios
Network requirements
The core switch in Figure 1 uses the FreeRADIUS server to provide AAA service for login users. Department A and Department B are in different VLANs, and the department network administrators can deploy QoS polices for traffic control on the core device.
Configure RBAC to control access of the network administrators to meet the following requirements:
The network administrator user role depart-admin can configure traffic control policies on the core device.
Resource control user role departA-resource of Department A can configure VLAN 100 to VLAN 199.
Resource control user role departB-resource of Department B can configure VLAN 200 to VLAN 299.
Configuration procedure
1. Configure the core device:
# Create the user role depart-admin.
<Core> system-view
[Core] role name depart-admin
# Add rule 1 to permit the user role to access the read, write, and execute commands of the QoS feature.
[Core-role-depart-admin] rule 1 permit read write execute feature qos
# Add rule 2 to permit to permit the user role to read, write, and execute Web menus of the QoS feature.
[Core-role-depart-admin] rule 2 permit read write execute web-menu qos
# Add rule 3 to permit to permit the user role to read, write, and execute XML elements of the QoS feature.
[Core-role-depart-admin] rule 3 permit read write execute xml-element xml-root/qos
# Deny the access of the user role to any VLAN, VPN, and interface.
[Core-role-depart-admin] vlan policy deny
[Core-role-depart-admin-vlanpolicy] quit
[Core-role-depart-admin] interface policy deny
[Core-role-depart-admin-ifpolicy] quit
[Core-role-depart-admin] vpn-instance policy deny
[Core-role-depart-admin-vpnpolicy] quit
[Core-role-depart-admin] quit
# Create the user role departA-resource.
[Core] role name departA-resource
# Configure rule 1 to permit the user role to create VLANs and use all commands available in VLAN view.
[Core-role-departA-resource] rule 1 permit command system-view ; vlan *
# Configure rule 2 to permit the user role to enter interface view and use all commands available in interface view.
[Core-role-departA-resource] rule 2 permit command system-view ; interface *
# Permit the user role to access VLANs 100 to 199, enter VLAN interface views.
[Core-role-departA-resource] vlan policy deny
[Core-role-departA-resource-vlanpolicy] permit vlan 100 to 199
[Core-role-departA-resource-vlanpolicy] quit
[Core-role-departA-resource] interface policy deny
[Core-role-departA-resource-ifpolicy] permit interface vlan-interface 100 to vlan-interface 199
[Core-role-departA-resource-ifpolicy] quit
[Core-role-departA-resource] quit
# Create the user role departB-resource.
[Core] role name departB-resource
# Configure rule 1 to permit the user role to create VLANs and use all commands available in VLAN view.
[Core-role-departB-resource] rule 1 permit command system-view ; vlan *
# Configure rule 2 to permit the user role to enter interface view and use all commands available in interface view.
[Core-role-departB-resource] rule 2 permit command system-view ; interface *
# Permit the user role to access VLANs 200 to 299, enter VLAN interface views.
[Core-role-departB-resource] vlan policy deny
[Core-role-departB-resource-vlanpolicy] permit vlan 200 to 299
[Core-role-departB-resource-vlanpolicy] quit
[Core-role-departB-resource] interface policy deny
[Core-role-departB-resource-ifpolicy] permit interface vlan-interface 200 to vlan-interface 299
[Core-role-departB-resource-ifpolicy] quit
2. Configure the AAA server:
# Configure the account admin-departA for the administrator of Department A.
admin-departA
Cleartext-Password := "admin-departA"
Service-Type = Login-User,
Login-Service = Telnet,
Cisco-AVPair = "shell:roles=\"depart-admin\" \"departA-resource\""
# Configure the account admin-departB for the administrator of Department B.
admin-departB
admin-departB
Cleartext-Password := "admin-departB"
Service-Type = Login-User,
Login-Service = Telnet,
Cisco-AVPair = "shell:roles=\"depart-admin\" \"departB-resource\""
