Cisco Systems OL-4344-01 manual Role-Based Access Control Rbac

Chapter 1 About Cisco IP Solution Center

Overview of ISC

•VRF configuration (export map, import map, maximum number of routes, VRF and RD override, and so forth)

•Choice of joining the VPN as hub or spoke

•Choice of interfaces on the PE, CE, and intermediate network devices

All the provisioning parameters can be made editable for a service operator who will deploy the service. A service policy is defined by a network operator and used by a service operator.

A service policy defines the parameters that will be used during provisioning.

Each of these parameters can be made editable or not to the inexperienced service operator. The fact that a service can be profiled greatly simplifies the service operator’s tasks and has now only limited number of parameters to enter during the provisioning process to deploy and activate a MPLS VPN service.

Role-Based Access Control (RBAC)

The central notion of role-based access control (RBAC) is that permissions are associated with roles, and users are made members of appropriate roles. Access control policy is embodied in various components of RBAC, such as role-permission, user-role, and role-role relationships. These components determine whether a particular user will be allowed to access a particular piece of data in the system.

The Role object specifies a set of occupants and the privileges or permissions granted to those occupants. There are several ways for constructing a role.

A role can represent competency to do specific tasks, such as a technician or a support engineer. A technician can collect edge device and interface information and import them into the ISC Repository. A support engineer (service operator) can create policies, submit service requests and deploy them.

A role can reflect specific duty assignments, for example, an engineer can be assigned to provision customer Acme’s VPN. The operator may not be allowed to provision the competitor customer Widget’s VPN.

A role can have distinct authority, for example, VPN customer AcmeInc should be allowed only to view or make minor change on Acme’s VPN data. The customer should not be allowed to access any other customer’s VPN data.

There can be a role hierarchy in which a super user has all the permissions allowed to two different roles.

The service provider can define a role for each VPN customer, for example Acme and Widgets. The acme_customers role and the Widgets_customers role are mutually exclusive roles. The same user can be assigned to no more than one role in a mutually exclusive set. Role constraint supports separation of duties.

ISC supports full Role-Based Access Control to the system resources. Each Role defines limited access to the resources with a set of permissions: view, create, update, delete, and execute. This same access mechanism is also given to a group. When a user is part of a group, he inherits the group’s access privileges.

Each user can be assigned one or many roles. Each user will be shown only the resources and services that he or she is allowed to create view, modify, or delete. Using the access privileges that the user has been allocated, the display and action allowed are adjusted accordingly.

Cisco IP Solution Center, 3.0: MPLS VPN Management User Guide, 3.0

OL-4344-01 1-7