Domain RBAC Overview
A domain is a sphere or a boundary around which you can interact with a system. A Junos Space Network Management Platform domain encompasses all Junos Space objects; it enforces access, controls visibility, and provides for management of network objects. By creating a domain, you create a container for interacting with the system. Devices are the key elements in a domain. You use domains and the devices within those domains to configure a device-management partitioning scheme allowing for role-based access control (RBAC).
Domains allow you to control and partition a network from the management point of view. You can create a network based on certain criteria while providing users with management access to their devices. At the same time, domains allow sharing of objects and certain configuration enforcements. Objects in the Global domain can only be accessed in read-only mode by the child domains, if view parent is enabled. Access across peer domains is not allowed. This kind of network partitioning is required for both managed security service providers (MSSP) and enterprise customers. The Network Management Platform enables users to manage objects from all the allowed domains in the aggregated view. However, Security Director does not support this functionality. Starting in Security Director 15.2, RBAC is available on the Administration tab, under the Users & Roles section on the left navigation pane.
The following sections explain the impact of domain RBAC on Security Director objects and services.
About Domains
By default, Junos Space and, therefore, Security Director comes with only the Global domain defined. New domains can be created as child domains of the Global domain. When you create a domain, you work with roles and users. Figure 1 shows a simple domain scheme that will be used as a reference throughout this document. For more information about creating domains, see Creating Domains in Security Director.
Working with Roles
Roles are used to group access permissions for easier assignment to users. For example, the Super Administrator role assigns read and write access to all aspects of Junos Space, Security Director, and the functions within. On the other hand, the Domain Administrator has read and write access to some functions, read-only access to other functions, and no access to some other functions. Security Director comes with several predefined roles that cannot be changed, including the Super Administrator and the Domain Administrator. User-defined roles can be created by cloning and then editing the predefined roles or by creating new roles from scratch. Users are assigned to roles during the creation of their accounts or by editing the user accounts after creation.
Users can be assigned to multiple roles. If a user is assigned to multiple roles that have conflicting permissions, the least restrictive permissions are applied to that user account. For example, suppose the Administrative Auditor role restricts users to only viewing report definitions and the Report Definition Administrator role allows users to modify report definitions. If a user is assigned to both roles, that user will be able to modify report definitions. Figure 2 illustrates this principle.
Working with Users
User accounts can be thought of as the recipients of RBAC policies. In Security Director, users are assigned to specific domains and to specific roles. Access to domains defines which devices and objects users can work with and assignment of users to roles defines what functions users can perform on the objects to which they have access. For more information about working with users, see Creating Users in Security Director.
Figure 3 shows the Global domain view of the Junos Space users list. Note the Assigned Domain column outlined in green.
About Objects or Services
Prior to domain RBAC, you only needed write permission for a domain to create an object or service in it. Now with domain RBAC, you also need access to a domain to create an object or service in that domain. For example, suppose you have domains D1, D2, and Global. To create an object in D1, you must switch to the D1 domain before you can create an object in that domain.
You cannot create an object or service in one domain while you are in a different domain.
In Security Director Release 13.2 and later, the REST API cannot be used to create objects in child domains, even if the user account used with the API has write access to the child domain. All objects created through the REST API are created in the Global domain.
All the objects that are created internally as part of an operation are part of the domain in which the operation is triggered. For example, all audit logs for an operation are created in the domain in which the operation is triggered.
- Reading or Viewing Objects or Services
- Updating or Modifying Objects or Services
- Deleting Objects or Services
- Referencing Objects
- Moving Objects Across Domains
- Naming Objects in a Domain
Reading or Viewing Objects or Services
You can view all objects in a domain to which you have access. In Security Director, you must switch the view to the D1 domain to view objects in that domain. If you have read access to both the D1 and D2 domains, you cannot see D2 domain objects from the D1 domain view, and vice versa. You can see objects in the Global domain from the D1 domain, provided the D1 domain has view parent permission. You cannot see D1 or D2 objects from the Global domain.
The ability to read or write objects in any given domain is dependent on switching your view to that specific domain from the Domains menu. However, Security Director also allows you to view objects in the parent domain as read-only if the view parent setting is enabled. For example, given the domain structure shown in Figure 1, the resulting views of the shared address objects in domains D1 and D2 are shown in Figure 4 and Figure 5 and respectively.
In the D1 Domain view, address objects from the System, Global, and D1 Domains are visible. These address objects can be used with devices and policies in the D1 Domain.
Because the view parent setting is disabled in D2, the only visible addresses in the D2 domain are the ones that exist in the System Domain. Any address created later in the D2 Domain would also show in this view.
Updating or Modifying Objects or Services
To modify a domain object through Security Director, you must switch to that domain. You cannot switch to a domain for which you do not have access. You cannot modify an object in one domain if you are in a different domain.
Modifying objects through REST is ID based. To modify an object in a domain, you must have write access to that domain and your user role must include modify permissions for the object type in question. Objects in the System domain are in read-only mode so you cannot modify them.
Deleting Objects or Services
To delete a domain object through Security Director, you must switch to that domain. You cannot delete an object in one domain if you are in a different domain.
Deleting objects through REST is ID based. To delete an object in a domain, you must have write access to that domain and your user role must include delete permissions for the object type in question. Objects in the System domain are in read-only mode so you cannot delete them.
Referencing Objects
An object can always reference another object in the same domain, with no restrictions. An object in the D1 domain can reference other objects in the D1 domain. The rules are more complex for referencing objects in a different domain. For example, a D1 domain object can reference objects in the D1 domain or in its parent domain, the Global domain. However, D1 objects cannot reference D2 objects. Objects in the Global domain cannot reference objects in child domains, D1 and D2. See Figure 6.
There is an exception to this rule when it comes to referencing devices. Objects in the D1 domain can reference devices in the same domain or they can reference devices in the D2 domain. But this is not true in reverse; that is, objects in the D1 domain cannot reference devices in the Global domain.
Services cannot reference other services even within the same domain.
Moving Objects Across Domains
You can move objects from one domain to another, in general. For example, you can move an object from the D1 domain to the Global domain and from the Global domain back to the D1 domain. A validation is performed to check that the move was valid. Invalid moves are not allowed. Moving an object becomes complex if the object is referenced by another object. An object in the D1 domain can be moved up to the Global domain if it is referenced by another object that is either in the D1 domain or in the Global domain. However, moving an object from the Global domain to the D1 domain is not allowed if the object is referenced by another object in the Global domain.
The rules are different for moving device objects between domains. You can move a device from the Global domain to the D1 domain if the device is used by an object in either the Global or the D1 domain. However, moving a device from the D1 domain to the Global domain is not allowed if an object in the D1 domain is using that device.
To move a device that is part of a cluster, you must move both members of the cluster. You cannot move only the primary or only the secondary device. You can move an object from the D1 domain to the Global domain only if you have write access to the Global domain and view parent access enabled in the D1 domain.
Naming Objects in a Domain
The name of an object must be unique within a domain hierarchy. Objects with the same name cannot be created in both the D1 and Global domains. The domain hierarchy includes the current domain, its parent, and its child domains.
All the name validations consider domains as one of the constraints.
The object name must be a string beginning with a number or letter and consisting of alphanumeric characters, colons, periods, slashes, dashes, and underscores. The object name must not contain special characters such as &, <, >, and \n.
About Predefined Objects
All Security Director predefined objects are in the System domain. The predefined services, addresses, signatures, and so on are visible from all the domains in read-only mode.
All device-specific predefined objects are also in the System domain. When a new predefined object is discovered during the device discovery process, that object is also placed in the System domain. The All Device policy is placed in the Global domain and you can modify that policy.