Cisco Crosswork Network Controller 7.2.x Administration Guide

Device access groups

Updated: August 14, 2026

Want to summarize with AI?

Explains how Device Access Groups provide device-level access control beyond role-based API and task permissions.

Device Access Groups are logical groups of devices that help administrators manage device-level access for users.

Crosswork Network Controller offers access control based on user roles, with Read, Write, and Delete permissions for specific APIs grouped by functional areas.

While this centralizes access control, it does not extend to device-level access. To manage device access for users, Device Access Groups can be used to logically group devices. Non-admin users assigned to the system-level task of Device Access Groups management can create and manage these groups.

Differences between APIs, tasks, and Device Access Groups

Device Access Groups are not directly related to API access control or task-based access control. Here's a breakdown of their differences and roles:

APIs: Control Read, Write, and Delete access levels to the APIs but do not control the UI access of a user. Permissions for APIs are defined and enforced at the API level, allowing administrators to specify what actions a user can perform.
Tasks: Control access to certain functionalities by combining a set of APIs. Enabling a specific task also enables the corresponding APIs required for that task.
Device Access Groups: Serve as an extra security layer to control access to specific devices or resources within Crosswork Network Controller, beyond API and task-based access controls. They are used to logically group devices for user management.

Administrators have full control over building user roles and permissions, including defining Device Access Groups. Device Access Groups become relevant only after a user has passed the initial API-based and/or task-based access controls set by an administrator. Once these initial access levels are granted, Device Access Groups provide additional control over which devices a user can have WRITE permissions for provisioning.

Administrators can configure Device Access Groups according to specific requirements, adding an extra layer of control and customization for access management within Crosswork Network Controller.

How device access groups work

When a user is associated with one or more Device Access Groups, they can make configuration changes and provision services on the devices within those groups. A Crosswork Network Controller user with an administrator role or a mapped Device Access Groups management task can:

Create and manage Device Access Groups.
Assign users to specific Device Access Groups.
Define and control which devices users can access and modify.
Ensure that users have the appropriate permissions to perform their tasks on designated devices.

Device Access Groups control device-level WRITE or Provisioning and Crosswork Network Controller flows that trigger such operations. They do not affect WRITE or EDIT operations within Crosswork Network Controller itself.

You can restrict users to specific tasks based on their role's permissions, ensuring only authorized individuals have access and control over their actions within the system. Crosswork Network Controller's role-based access control synchronizes with NSO and Device Access Groups to streamline device configurations, using JWT tokens for authentication and authorization in RESTCONF and JSON-RPC API workflows. However, reverse synchronization is not possible; changes in NSO are not reflected in Crosswork Network Controller Device Access Groups (for detailed information on the prerequisites for setting up NSO, refer to Configure NSO Servers). External LDAP, TACACS, and RADIUS servers support Device Access Groups integration.

Summary

The Device Access Group process involves Crosswork Network Controller users, roles, Device Access Groups, NSO synchronization, and external authentication servers.

Crosswork Network Controller users make configuration changes and provision services on devices in associated Device Access Groups.
Administrators or users with the mapped Device Access Groups management task create groups, assign users, and control device access.
Crosswork Network Controller role-based access control synchronizes with NSO and Device Access Groups for RESTCONF and JSON-RPC API workflows.

Workflow

These stages describe how device access groups work.

A Crosswork Network Controller user is associated with one or more Device Access Groups.
The user makes configuration changes and provisions services on devices within those groups.
Crosswork Network Controller uses role permissions and Device Access Group privileges to restrict or allow operations on devices.
Crosswork Network Controller synchronizes role-based access control with NSO and Device Access Groups for supported workflows.

Create device access groups

To enable seamless device-level granular Role-Based Access Control across Crosswork Network Controller applications and integrated NSO, create a device access group that will allow for centralized management of device access permissions, ensuring consistent role-based access implementation across the system. Only users belonging to a role that has the "Device Access Group Management" task enabled have the ability to perform Create, Read, Update, and Delete operations on the device access groups.

Procedure

	1.	From the main menu, choose Administration > Device Access Groups.
	2.	Click the icon next to ALL-ACCESS, then click Add Sub-Group.
	3.	Add the name and description of the sub-group under Group Details.
	4.	Click Create. When you add devices to a device access group, you can view the Devices tab next to Group Details.
	5.	Click Add Devices.
	6.	Select the devices you want to add and click Save. You can also filter the devices that you want to add using the Filter By options for Host Name, Product Type and Node IP. The devices are added under device access groups as well as updated in the NSO site.
	7.	Click Save.

Edit device access groups

You can add or remove a device from an existing Device Access Group.

The delete group check is only relevant for local users defined in Crosswork Network Controller and does not apply to users managed by external AAA servers.

Procedure

	1.	From the main menu, choose Administration > Device Access Groups.
	2.	Click the Device Access Group that you want to edit and then click Edit Group. You can add more devices by clicking Add Devices or remove them by clicking Remove Devices.
	3.	Click Save. Note You cannot delete a Device Access Group if a user is exclusively associated with it. However, if all users associated with the Device Access Group also belong to other Device Access Groups, you can delete it.

Assign task permissions

You can assign the tasks that you have created to a specific role. You can enable or disable these tasks based on the permissions you want to give for a role. The task permissions are defined by the Global APIs, which allow you to assign Read/Write/Delete permissions for that specific task.

Procedure

	1.	From the main menu, choose Administration > Users and Roles > Roles.
	2.	Click Task Permissions to view a list of all the available tasks for your application. Figure 1. Users and roles window
	3.	Select the task for which you want to assign permissions. Under the Global API Permissions tab, you can also view the specific Read/Write/Delete permissions that are automatically enabled for the selected task. Note Provisioning RBAC is managed through provisioning tasks. All users with provisioning task permissions are expected to have read, write, and delete access.
	4.	Click Save.

Associate users with device access groups

Procedure

	1.	Create a role with Read, Write, and Delete API permissions and assign the set of specific tasks that need to be enabled within each role. Refer to the section, User roles, functional categories, and permissions for more details.
	2.	Assign this role and one or more Device Access Group to a user. Refer to the section, Add a user for more details. When the user logs in, the user can only perform operations allowed by the tasks on devices belonging to the associated Device Access Groups. Based on task permissions and Device Access Group privileges, a restricted read-only Device Access Group user has the following capabilities while provisioning policies on BWoD, LCM, CSM, DLM, DGM and CAT. Such a user can: Preview and dry run policies but cannot provision or commit changes for the policies. View Services and Traffic Engineering configuration pages but cannot edit or import files. Perform Path Query operations. View Services and Traffic Engineering configuration pages but cannot edit or import files. Create VPN services. View the devices that are associated with a failed service, along with the detailed error message but cannot take actions on the errors. Correspondingly, a Device Access Group user with all the Read, Write, and Delete permissions has the following capabilities. Such a user can: Perform all the tasks listed for a restricted read-only Device Access Group user. Provision policies for which they have been granted access to. For instance, if a user wants to create an RSVP-TE policy on a Tunnel, they will be able to do so only if they have been granted access to the head-end node. However, note that access to the endpoints and hops is not checked for Device Access Group control. View the devices that are associated with a failed service, along with the detailed error message. Additionally, users with all privileges can take actions on errors such as Check-Sync, Sync-To, and Compare-Config at the node level. Run and execute Playbooks. Note To restrict device access in Crosswork Network Controller for read-only users, the administrators must create an empty Device Access Group (for example, NO_DEVICE_ACCESS) without any devices, and assign it while creating read-only user profiles (or user profiles associated with read-only roles).

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.