This document describes the steps required in order to authenticate Cisco Security Manager (CSM) Versions 4.3/4.4 with Access Control Server (ACS) Version 5.x. In this configuration, user authentication is managed by ACS while authorization is managed on CSM with the local Role Based Access Control (RBAC) feature.
Cisco recommends that you have knowledge of these topics:
- Basic Knowledge of Authentication, Authorization, and Accounting (AAA)
- CSM Server and Device Administration
- Authentication and Authorization Policies Configuration on ACS Version 5.x
The information in this document is based on these software and hardware versions:
- CSM Version 4.4
- ACS Version 5.4
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
In previous versions of CSM, external authentication and authorization services were possible with ACS Version 4.x only. The use of ACS Version 5.x was not officially tested or supported. The ACS Version 4.x integration was often difficult to scale because it required manual synchronization of the ACS and CSM network device configurations. In order to overcome this administrative burden, local RBAC capabilities are integrated directly into CSM Version 4.3 and later. In production deployments where both CSM Versions 4.3/4.4 and ACS Version 5.x are deployed, it is now possible to integrate the two in order to service user authentication externally and maintain granular authorization policies locally on CSM.
Configure ACS Server
Complete these steps in order to configure the ACS server:
- From the ACS Version 5.x administrative GUI, navigate to Network Resources > Network Devices and AAA Clients > Create, and add the CSM server as a Network Access Device (NAD). Although TACACS+ is more commonly used for network device authentication, both ACS and CSM can be configured in order to use RADIUS if required.
- Navigate to Users and Identity Stores > Internal Identity Stores > Users, and create a new local user for CSM access. Associate the user account with an Identity Group as required, such as CSM_Admins. Alternatively, an external identity store, such as Active Directory, can be used.
- Navigate to Access Policies > Access Services > Default Device Admin > Identity, and associate the Identity Source to be used for user authentication. In this example, the Internal Users identity source is chosen because the CSM user accounts are locally defined on ACS. An external identity source can be selected when you integrate it with Active Directory.
- Navigate to Access Policies > Access Services > Default Device Admin > Authorization, and configure an authorization policy that permits access to the user Identity Group defined previously (CSM_Admins). This is required for ACS order-of-operations processing even though the actual authorization policy is defined/enforced locally on the CSM server.
Configure CSM CiscoWorks Common Services
Complete these steps in order to configure CSM CiscoWorks Common Services:
- Double-click the Cisco Security Manager icon on the CSM server desktop. Alternatively, navigate to Tools > Security Manager Administration > Server Security with the CSM Configuration Manager client in order to cross launch the Server Security Tools within the CSM Common Services backend.
- Enter the CSM administrative user credentials, and click Login. Choose the Server Administration option from the Cisco Security Management Suite launch page.
- Navigate to Server > Security > AAA Mode Setup, and choose Local RBAC and either TACACS+ or RADIUS. Click Change in order to edit the login server settings.
- Enter the login server IP or Fully Qualified Domain Name (FQDN), ports, and pre-shared key. Under normal operations, do not change the Login fallback options settings in order to allow fallback access to CSM in the event that the ACS server is unreachable. By default, the local CSM administrative user account is defined for fallback access. If change is necessary, care should be taken in order to prevent accidental lockout of the CSM server.
- Navigate to Server > Single-Server Management > Local User Setup, and click Add in order to create local user accounts that match the internal or external user accounts defined in ACS. The usernames are case-sensitive and should match ACS exactly. These locally-defined accounts are then mapped to the CSM local RBAC authorization roles. Specific roles such as System Administrator can be chosen for Task Authorization separation or the user can be provided either full or restricted access to a subset of devices. Refer to the CiscoWorks Common Services Default Roles section of the CSM 4.4 Installation Guide for more details about Task Authorization and Roles.
Configure Default Authorization Roles for Undefined Users (Optional)
Complete these steps in order to configure default authorization roles for undefined users:
- In some CSM deployments, it is not convenient to maintain a one-for-one user mapping between CSM and ACS. An alternative approach is to assign a default set of authorization roles in CSM for users not present in the local CSM database.
- In order to configure the default authorization roles, double-click the Cisco Security Manager icon on the CSM server desktop and select the Server Administration option from the launch page.
- Navigate to Server > Single-Server Management > Role Management Setup. By default, the Help Desk role is assigned the Default Role designation. In order to change this designation, check one or more roles, and click the Set as default button.
- In order to enable this feature, navigate to Tools > Security Manager Administration > Server Security with the Configuration Manager client, and check the check box labeled Allow logon for user ids not available in Local User Database. Click Save in order to save the configuration.
Use this section in order to confirm that your configuration works properly.
- Review the TACACS+ or RADIUS authentication logs on the ACS server in order to identify whether the CSM user is able to authenticate against the configured identity store.
- Verify that the CSM user is able to perform an available task within the Task Authorization role defined. For example, log in as a user with the System Administrator role and try to add a new device to the CSM inventory.
This section provides information you can use in order to troubleshoot your configuration.
- Errors such these indicate that you attempted to perform a task that you are not authorized to perform as per the local RBAC policy.
- Log in to the CSM Server Administration interface as an administrative user and navigate to Server > Single-Server Management > Local User Setup. Edit the user account in question and review the Task Authorization policy defined for the user. When you use the CSM-defined roles, ensure that you review the CiscoWorks Common Services Default Roles section of the CSM 4.4 Installation Guide in order to better understand the permissions for each role. For example, the System Administrator role provides complete access to all CSM client functions while Super Admin only provides access to the backend CiscoWorks operations.
- If desired, new roles can be defined and default roles edited in order to provide more granular authorization policy control. In order to add/edit, log in to the CSM server manager inteface and navigate to Server > Single-Server Management > Role Management Setup.
In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees, and can implement mandatory access control (MAC) or discretionary access control (DAC). RBAC is sometimes referred to as role-based security.
Role-based-access-control (RBAC) is a policy neutral access control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role and role-role relationships make it simple to perform user assignments. A study by NIST has demonstrated that RBAC addresses many needs of commercial and government organizations. RBAC can be used to facilitate administration of security in large organizations with hundreds of users and thousands of permissions. Although RBAC is different from MAC and DAC access control frameworks, it can enforce these policies without any complication. Its popularity is evident from the fact that many products and businesses are using it directly or indirectly.
Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members or staff (or other system users) are assigned particular roles, and through those role assignments acquire the computer permissions to perform particular computer-system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user's account; this simplifies common operations, such as adding a user, or changing a user's department.
Three primary rules are defined for RBAC:
- Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
- Role authorization: A subject's active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
- Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject's active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.
Additional constraints may be applied as well, and roles can be combined in a hierarchy where higher-level roles subsume permissions owned by sub-roles.
With the concepts of role hierarchy and constraints, one can control RBAC to create or simulate lattice-based access control (LBAC). Thus RBAC can be considered to be a superset of LBAC.
When defining an RBAC model, the following conventions are useful:
- S = Subject = A person or automated agent
- R = Role = Job function or title which defines an authority level
- P = Permissions = An approval of a mode of access to a resource
- SE = Session = A mapping involving S, R and/or P
- SA = Subject Assignment
- PA = Permission Assignment
- RH = Partially ordered Role Hierarchy. RH can also be written: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
- A subject can have multiple roles.
- A role can have multiple subjects.
- A role can have many permissions.
- A permission can be assigned to many roles.
- An operation can be assigned many permissions.
- A permission can be assigned to many operations.
A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate separation of duties. For example, the same person should not be allowed to both create a login account and to authorize the account creation.
Thus, using set theorynotation:
- and is a many to many permission to role assignment relation.
- and is a many to many subject to role assignment relation.
A subject may have multiple simultaneous sessions with/in different roles.
See also: NIST RBAC model
The NIST/ANSI/INCITS RBAC standard (2004) recognizes three levels of RBAC:
- core RBAC
- hierarchical RBAC, which adds support for inheritance between roles
- constrained RBAC, which adds separation of duties
Relation to other models
RBAC is a flexible access control technology whose flexibility allows it to implement DAC or MAC.DAC with groups (e.g., as implemented in POSIX file systems) can emulate RBAC.MAC can simulate RBAC if the role graph is restricted to a tree rather than a partially ordered set.
Prior to the development of RBAC, the Bell-LaPadula (BLP) model was synonymous with MAC and file system permissions were synonymous with DAC. These were considered to be the only known models for access control: if a model was not BLP, it was considered to be a DAC model, and vice versa. Research in the late 1990s demonstrated that RBAC falls in neither category. Unlike context-based access control (CBAC), RBAC does not look at the message context (such as a connection's source). RBAC has also been criticized for leading to role explosion, a problem in large enterprise systems which require access control of finer granularity than what RBAC can provide as roles are inherently assigned to operations and data types. In resemblance to CBAC, an Entity-Relationship Based Access Control (ERBAC, although the same acronym is also used for modified RBAC systems, such as Extended Role-Based Access Control) system is able to secure instances of data by considering their association to the executing subject.
Comparing with ACL
RBAC differs from access control lists (ACLs), used in traditional discretionary access-control systems, in that it assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. For example, an access control list could be used to grant or deny write access to a particular system file, but it would not dictate how that file could be changed. In an RBAC-based system, an operation might be to 'create a credit account' transaction in a financial application or to 'populate a blood sugar level test' record in a medical application. The assignment of permission to perform a particular operation is meaningful, because the operations are granular with meaning within the application. RBAC has been shown to be particularly well suited to separation of duties (SoD) requirements, which ensure that two or more people must be involved in authorizing critical operations. Necessary and sufficient conditions for safety of SoD in RBAC have been analyzed. An underlying principle of SoD is that no individual should be able to effect a breach of security through dual privilege. By extension, no person may hold a role that exercises audit, control or review authority over another, concurrently held role.
Then again, a "minimal RBAC Model", RBACm, can be compared with an ACL mechanism, ACLg, where only groups are permitted as entries in the ACL. Barkley (1997) showed that RBACm and ACLg are equivalent.
In modern SQL implementations, like ACL of theCakePHP framework, ACL also manage groups and inheritance in a hierarchy of groups. Under this aspect, specific "modern ACL" implementations can be compared with specific "modern RBAC" implementations, better than "old (file system) implementations".
For data interchange, and for "high level comparisons", ACL data can be translated to XACML.
Attribute based access control
Attribute-based access control or ABAC is a model which evolves from RBAC to consider additional attributes in addition to roles and groups. In ABAC, it is possible to use attributes of:
- the user e.g. citizenship, clearance,
- the resource e.g. classification, department, owner,
- the action, and
- the context e.g. time, location, IP.
ABAC is policy-based in the sense that it uses policies rather than static permissions to define what is allowed or what is not allowed.
Use and availability
The use of RBAC to manage user privileges (computer permissions) within a single system or application is widely accepted as a best practice. A 2010 report prepared for NIST by the Research Triangle Institute analyzed the economic value of RBAC for enterprises, and estimated benefits per employee from reduced employee downtime, more efficient provisioning, and more efficient access control policy administration.
In an organization with a heterogeneous IT infrastructure and requirements that span dozens or hundreds of systems and applications, using RBAC to manage sufficient roles and assign adequate role memberships becomes extremely complex without hierarchical creation of roles and privilege assignments. Newer systems extend the older NIST RBAC model to address the limitations of RBAC for enterprise-wide deployments. The NIST model was adopted as a standard by INCITS as ANSI/INCITS 359-2004. A discussion of some of the design choices for the NIST model has also been published.
RBAC and employees' responsibilities alignment
In Aligning Access Rights to Governance Needs with the Responsibility MetaModel (ReMMo) in the Frame of Enterprise Architecture an expressive Responsibility metamodel has been defined and allows representing the existing responsibilities at the business layer and, thereby, allows engineering the access rights required to perform these responsibilities, at the application layer. A method has been proposed to define the access rights more accurately, considering the alignment of the responsibility and RBAC.
- ^Ferraiolo, D.F. & Kuhn, D.R. (October 1992). "Role-Based Access Control"(PDF). 15th National Computer Security Conference: 554–563.
- ^Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (August 1996). "Role-Based Access Control Models"(PDF). IEEE Computer. IEEE Press. 29 (2): 38–47. doi:10.1109/2.485845.
- ^ abA.C. O'Connor & R.J. Loomis (March 2002). Economic Analysis of Role-Based Access Control(PDF). Research Triangle Institute.
- ^Alberto Belussi; Barbara Catania; Eliseo Clementini; Elena Ferrari (2007). Spatial Data on the Web: Modeling and Management. Springer. p. 194. ISBN 978-3-540-69878-4.
- ^Ravi Sandhu; Qamar Munawer (October 1998). "How to do discretionary access control using roles". 3rd ACM Workshop on Role-Based Access Control: 47–54.
- ^Sylvia Osborn; Ravi Sandhu & Qamar Munawer (2000). "Configuring role-based access control to enforce mandatory and discretionary access control policies". ACM Transactions on Information and System Security: 85–106.
- ^Brucker, Achim D.; Wolff, Burkhart (2005). "A Verification Approach for Applied System Security". International Journal on Software Tools for Technology (STTT). doi:10.1007/s10009-004-0176-3.
- ^D.R. Kuhn (1998). "Role Based Access Control on MLS Systems Without Kernel Changes"(PDF). Third ACM Workshop on Role Based Access Control: 25–32.
- ^National Institute of Standards and Technology FAQ on RBAC models and standards
- ^David Ferraiolo and Richard Kuhn
- ^A. A. Elliott & G. S. Knight (2010). "Role Explosion: Acknowledging the Problem"(PDF). Proceedings of the 2010 International Conference on Software Engineering Research & Practice.
- ^Dr. Bhavani Thuraisingham and Srinivasan Iyer (PPT)
- ^Kalle Korhonen: tapestry-security-jpa, a JPA/Tapestry 5 specific implementation of the ERBAC concept
- ^D.R. Kuhn (1997). "Mutual Exclusion of Roles as a Means of Implementing Separation of Duty in Role-Based Access Control Systems"(PDF). 2nd ACM Workshop Role-Based Access Control: 23–30.
- ^Ninghui Li, Ziad Bizri, and Mahesh V. Tripunitara . Tripunitara (2004). "On mutually exclusive roles and separation-of-duty,"(PDF). 11th ACM conference on Computer and Communications Security: 42–51.
- ^J. Barkley (1997) "Comparing simple role based access control models and access control lists", In "Proceedings of the second ACM workshop on Role-based access control", pages 127-132.
- ^Beyond Roles: A Practical Approach to Enterprise User Provisioning
- ^Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). "The NIST Model for Role-Based Access Control: Toward a Unified Standard"(PDF). 5th ACM Workshop Role-Based Access Control: 47–63.
- ^Ferraiolo, D.F., Kuhn, D.R., and Sandhu, R. (Nov–Dec 2007). "RBAC Standard Rationale: comments on a Critique of the ANSI Standard on Role-Based Access Control"(PDF). IEEE Security & Privacy. IEEE Press. 5 (6): 51–53. doi:10.1109/MSP.2007.173.
- ^Feltus C. (2014). Aligning Access Rights to Governance Needs with the Responsibility MetaModel (ReMMo) in the Frame of Enterprise Architecture(PDF).
- ^Feltus, c., Petit, M., Sloman, M. (2010). "Enhancement of Business IT Alignment by Including Responsibility Components in RBAC"(PDF). CEUR-WS. 599.
- David F. Ferraiolo; D. Richard Kuhn; Ramaswamy Chandramouli (2007). Role-based Access Control (2nd ed.). Artech House. ISBN 978-1-59693-113-8.