How to Delegate Roles and Containers

You are here:

Settings > Roles & Permissions


You can delegate the creation of Roles and Containers to others in System Frontier. This allows you to manage other groups’ access and abilities within the application.

Delegation of Roles

If a Role, we’ll call it a parent Role, has been given the CreateRole permission, then the members of that Role have the ability to create other Roles and to modify or delete those created Roles. Generally, this is used to delegate permissions to other groups within their organization and within the Scope defined by the parent Role. The parent Role is able to manage any child Roles that they create.

The parent Role has the permissions granted to it by the SFSA Role. In this case, the parent Role has the CreateRole permission, which allows it to create child Roles.

When the parent Role creates a role, the child Role will only have the permissions given to it by the parent Role and will not have the higher level administrative permissions that would allow it to create other Roles.

In the example below, the SFSA Role can create any Role. In this case it has also given the HR Role and the IT Role the CreateRole permission, which in turn, gives them the ability to manage Roles that they create. It has not given the Finance Role that permission.

As a result, the members of the HR and IT Roles can also create other Roles. The Finance Role cannot create a Role.

An example of Role delegation.

The HR Role has created the Recruiting Role and the Benefits Role. The IT Role has created the Security Role, the Build Role, and the Support Role.

None of the Roles created by the HR or IT Roles can create other Roles. Role delegation only goes down 1 level. So, the SFSA Role can create parent Roles and grant them the CreateRole permission, which allows the parent Roles to create child Roles, but a child Role cannot pass along the CreateRole permission.

Upon creation of a new Role, the ModifyRole permission will appear for the parent Role. Beside it under the Scope column will be a link showing the number of child Roles that the Role has created. Clicking on the link shows those Roles and will allow the parent Role to delete them, if desired.

An example of a scope for a parent Role shows the child Roles that it has created or that it otherwise manages.

Also, newly created Roles will appear in the Roles & Permissions page where the parent Role can modify child Roles. Only those Roles which the parent has created will be visible (or any others where the Role has been granted the ModifyRole permission specifically).

Non-administrative permissions that have been granted to the parent Role are available to be granted to a child Role by the parent Role.

The scope selection for a permission is limited to the containers that fall under the root Container for the parent Role. These may include the root Container as well as any Containers created by the parent Role.

An example of permission scopes.
Once a parent Role with the CreateRole permission has created a child Role, then the ModifyRole permission will appear for that parent Role. ModifyRole allows the parent Role the ability to modify and delete child Roles.

Delegation of Containers

The CreateContainer permission works just like the CreateRole permission. With the CreateContainer permission a Role can create Containers.

The CreateContainer permission likewise only extends to 1 child level. The SFSA Role can grant CreateContainer to a parent Role, but the child cannot grant CreateContainer to any of its offspring.

In the below example, the SFSA Role has created the FODV Admins Role. SFSA has granted FODV Admins access to the FODV Servers Container. This is designated in the Root Container section. The Root Container section will not be visible to the child Role. Additionally here, the FODV Admins Role is given the CreateContainer permission.

The Role (edit) page for a parent Role that has been granted the CreateContainer Role.

FODV Admins can create new Containers, but those new Containers can only consist of members of the All FODV Servers. For example, they can create new Containers called FODV SQL Servers and FODV IIS Servers. The members of the new FODV SQL Servers Container can only come from the list of servers in the All FODV Servers and not outside of that scope.

An example of Container creation for a parent Role.
New Containers can only contain computers to which the Role has been granted access by the Role above it..

After a Role with the CreateContainer permission has created a Container, they will notice that the WriteContainer permission appears and the Scope number is incremented. Clicking on the Scope link in the WriteContainer line will show all of the Containers that have been created by the Role or that the Role manages.

Container scope for a permission.
The WriteContainer permission allows the Role the ability to modify and delete Containers created by that Role or that they otherwise manage.

Under the Manage > Containers menu item, Role members can see their Container, Containers that they have created, All Computers, and any Container where they otherwise have permission to view. If they have the permission of CreateContainer, they will also see the Create link.

When a child Role edits a Container from the Manage > Containers menu, the Credential Mapping field is grayed out.

Was this article helpful?
Dislike 0