Permission Sets

A permission set represents the permissions for users that access ERA Web Console. They define what the user can do or see in the Web Console. Native users have their own permissions while domain users have the permissions of their Mapped security group. Each permission set has its domain of application (static groups). Permissions which are selected in the icon_section Functionality section will apply over objects in the groups which are set in the icon_section Static Groups section for each user assigned by this permission set. Having access to certain Static Group automatically means access to every one of its subgroups. With proper setting of static groups it is possible to build separated branches for local admins (see the example).

A user can be assigned a permission set even without being able to see it. A permission set is also an object which is automatically stored in the home group of the user who created it. When a user account is created, the user is stored as object in the home group of the creating user. Usually the Administrator creates users, so they are stored in the group All.

Access Group Filter

access_group

The Access Group filter button enables users to select a static group and filter viewed objects according to the group where they are contained.

admin_AR_permissions

 

validation-status-icon-warning IMPORTANT

Good practice for working with permissions:

Never give access to Server Settings to inexperienced users - only Administrator should have this access.

Consider restricting access to Client Tasks > Run Command - it is a very powerful task that could be abused.

Non-admin level users should not have permissions for Permission Sets, Native Users, Server Settings.

If  a more complicated model of permissions is needed, do not hesitate to create more permission sets and assign them accordingly.

 

Next to permissions to ERA functionality, there can be given Read, Use, Write access to User Groups.

light-bulbEXAMPLE: Duplication

For an object duplication the user needs to have Read permission on the original object and Write permission on his Home Group for this type of action.

John, whose home group is John’s Group, wants to duplicate Policy 1, which was originally created by Larry, therefore the policy is automatically contained in Larry's home group, Larry's Group. This is the recommended way of achieving it:

1.Create a new static group. Name it, for example, Shared policies.

2.Assign both John and Larry with Read permissions for Policies in the group Shared policies.

3.Larry moves Policy 1 to the Shared policies group.

4.Assign John with Write permissions for Policies in his home group.

5.John can now Duplicate the Policy 1 - duplicate will appear in his home group.

light-bulbEXAMPLE: Difference between Use and Write

If Administrator does not want to allow user John to modify policies in the Shared policies group, he would create a permission set with:

Functionality Policies: Read and Use permissions selected

Static Groups: Shared Policies

With these permissions assigned to John, John is able to run those policies but he can not edit them, create new, nor delete them. If an administrator were to add Write permission, John could create new, duplicate, edit and delete policies within the selected static group (Shared policies).