Domain RBAC Overview

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.

Figure 2: Security Director Roles

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.

Figure 3: Security Director Users

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.

Figure 4: D1 Domain Addresses

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.

Figure 5: D2 Domain Addresses

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.

Figure 6: Security Director Domain References

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.

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.