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

Page 7

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

 

 

 

Image 7
Contents About Cisco IP Solution Center ISC Network Management Subnet Overview of ISCISC Features Service Provider Network for Vlan ID Management Resource Pools Access Domain AssignedVPN Service Profile-Based Provisioning Features and Functions Provided in Provisioning with ISCRole-Based Access Control Rbac CPE Customer’s View of the Network Customer’s and Provider’s View of the NetworkAbout Multi-VRF CEs About Provider Edge Routers PEsA Multi-VRF CE Providing Layer 3 Aggregation Mapping IPsec Tunnels to Mpls VPNs Using Templates to Customize Configuration FilesUses for the Template Function Auditing Service RequestsVPNs Sharing Sites About Mpls VPNsIntranets and Extranets Characteristics of Mpls VPNsVPN Routing and Forwarding Tables VRFs Ip vrf site2 rd VRF Implementation ConsiderationsRoute Distinguishers and Route Targets Creating a VRF InstanceCE Routing Communities Route Target CommunitiesHub and Spoke Considerations Routing Separation Security Requirements for Mpls VPNsAddress Space and Routing Separation Address Space SeparationHiding the Mpls Core Structure Securing the Routing Protocol Resistance to AttacksLabel Spoofing PE-CE Interface Routing AuthenticationSecuring the Mpls Core Trusted DevicesSeparation of CE-PE Links LDP AuthenticationConnectivity Between VPNs Security Through IP Address Resolution MP-BGP Security FeaturesEnsuring VPN Isolation North Bound Interface NBIAPI Functionality Supported NBI Benefits Distributed Load BalancingAPI Approach 11 Simple Flat-Based Server Load Balancing Configuration Client tier Four-Tier System ArchitectureControl tier