Page History
Table of Contents |
---|
Introduction
Operations
Manage Permissions
Permissions Structure
Role based access management is offered from JS7 - Identity Services within the scope of JS7 - Identity and Access Management.
- The Identity Service Type determines if roles are managed from JOC Cockpit or from the Identity Provider, for example from an LDAP Server.
- The JS7 - JOC Identity Service provides the management of roles.
- The JS7 - HashiCorp® Vault Identity Service provides management of roles if the
VAULT
Identity Service Type is used.
- Permissions are managed from JOC Cockpit independently of the Identity Service in use.
- For the assignment of roles to user accounts see the JS7 - Manage User Accounts article.
Roles and Permissions
Role based Access Management
User accounts are assigned a number of roles.
- Each role is assigned a number of permissions.
- Permissions are available in the following flavors:
- Additive Permissions are granted to a user account and add to the permission set of a user account.
- Subtractive Permissions deny use of a permission and restrict the user account's permission set as they beat Additive Permissions across roles.
- Users are free to create any roles and to assign permissions. Roles are frequently determined from an organizational point of view, for example:
- administrator
- application manager
- business user
- JS7 ships with a number of defaults for roles and permissions, see the JS7 - Default Roles and Permissions for details.
Please keep in mind that at least one role that includes administrative permissions to access all objects in JOC Cockpit and Controllers is required and has to be assigned an administrative user account. If all administrative roles are deleted, then this corresponds to locking the door behind you and throwing away the keys. In this situation refer to the JS7 - Rescue in case of lost access to JOC Cockpit article.
Scope and Structure of Permissions
Permissions can be specified in scope and hierarchy:
- Scope
- JOC Cockpit Permissions are assigned for operations in JOC Cockpit, for example, for managing calendars and the daily plan etc.
- Controller Permissions are assigned for operations on scheduling objects per Controller, for example, for deploying workflows, adding orders etc.
- If more than one Controller is connected to JOC Cockpit then a user account can be assigned a role that for example allows deployment to one Controller but not to other Controllers.
- Controller permissions can be specified as a default for all Controllers and they can be specified on an individual Controller basis.
- Permission Tree
- Permissions can be considered as a tree that offers a hierarchy of branches.
- Granting or denying permissions at a higher level inherits the permission assignment recursively to deeper levels of the tree.
- Permission Status
- Permissions can take one of three status values, being unassigned, granted or denied.
- Unassigned permissions do not suggest any assumption if the permission is granted or denied.
- Granted permissions are considered additive within limits as they can be overruled by denied permissions.
- Denied permissions are considered subtractive without limits as they cannot be overruled by granted permissions.
- Permission Sets
- Roles are assigned permissions. A user account can accumulate a number of roles, therefore permissions are merged to a permission set by the following rules.
- JOC Cockpit Permissions
- Unassigned permissions are ignored.
- Granted permissions work across any roles unless merged with a denied permission from a role.
- Denied permissions work across any roles and cannot be overruled by granted permissions from any role.
- Controller Permissions
- Default Controller
- Unassigned permissions are ignored.
- Granted permissions overrule unassigned permissions from any roles and Controllers.
- Granted permissions can be overruled from all roles. They can be:
- denied by a permission of the Default Controller specified by another role,
- denied by a permission for a Specific Controller.
- Denied permissions
- Specific Controller
- Unassigned permissions are ignored, instead the permissions of the Default Controller are applied.
- Granted permissions work across all roles unless denied by a permission from a role for the given Controller.
- Denied permissions work without limits across all roles for the given Controller.
- Default Controller
- JOC Cockpit Permissions
- Roles are assigned permissions. A user account can accumulate a number of roles, therefore permissions are merged to a permission set by the following rules.
Views
Views are available for roles and permissions including the Graphical Permissions View and the Textual Permissions View.
Roles View
Users can click the name of an Identity Service from the list of Identity Services:
Having selected an Identity Service the Roles view is displayed like this:
A default link is available for each role to navigate to the Graphical Permissions View.
Additional links can be added by use of the Add Controller button. Such links are used to Assign Permissions for a Specific Controller.
Anchor | ||||
---|---|---|---|---|
|
The view allows graphical navigation and selection of permissions and is the default view for the permissions of a given role:
- Explanation:
- Navigation
- The Expand All and Collapse All buttons open and close any child branches.
- The Expand Active and Collapse Active buttons open and close child branches with granted or denied permissions.
- The
+
and-
icons at the right edge of each permission icon open and close child branches.
- Status and Colors
- Permissions show the following background colors to indicate the status:
- White: Permission is not assigned, i.e. is neither granted nor denied.
- Dark Blue: Permission is granted and the grant is inherited to child permissions recursively.
- Light Blue: Permission is inherited from a granted parent permission.
- Dark Grey: Permission is denied and the denial is inherited to child permissions recursively..
- Light Grey: Permission is inherited from a denied parent permission.
- Display of permission can include a triangular attention sign such as
- The white background color indicates an unassigned permission, the triangle indicates that further down in the permission hierarchy a permission is granted or denied.
- The blue background color indicates a granted/inherited permission, the triangle indicates that further down in the permission hierarchy a permission is not granted or is denied.
- Granting Permissions
- Clicking the middle of an unassigned (white) permission grants the permission (dark blue).
- Clicking the middle of a granted permission revokes the grant and puts the permission to the unassigned status (white).
- Denying Permissions
- The
+
icon inside a permission icon denies the permission (dark grey) recursively for child permissions that are located deeper in the permissions tree (light grey). - A denied permission shows the
-
icon, clicking this icon revokes the denial and puts the permission to the unassigned status.
- The
- Permissions show the following background colors to indicate the status:
- Undo/Redo
- Changes to the permissions tree are stored in the JS7 - Database.
- The Undo button allows the last 10 changes to be undone stepwise.
- Any changes held in the Undo button will be deleted when the user leaves the Permissions sub-view.
- The Redo button changes the permissions tree back to its initial state when the Permissions sub-view is displayed.
- The status held with the Redo button is deleted when a user leaves the Permissions sub-view.
- Navigation
Anchor | ||||
---|---|---|---|---|
|
The view acts as an alternative to the Graphical Permissions View and displays permissions from a list of textual entries.
The right upper corner of the Permissions sub-view allows the user to toggle between the Graphical and Textual Permissions Views.
- Explanation:
- Individual permissions can be modified and can be removed from a role using the pencil icon and X icon, which are faded in when the user's mouse is moved over a permission.
- The Edit function allows the permission to be made subtractive, i.e. for permissions granted at a higher level the selected permission and any child permissions are denied.
- The folder part of the view is used to restrict the role to access particular folders only - this includes any scheduling objects such as workflows which are only visible from the assigned folder.
Assignment Strategies
Permission Hierarchy
Permissions are Permissions are organized in a hierarchical way:
- A Role role with the Permission permission
sos:products:controller:view
'only' allows a User allows a user to view ControllersControllers only, while a user with the 'higher'sos:products:controller
permission is able not only to view Controllers but is able to carry out additional operations - in this case, any operations such as view, restart, terminate, and to switch_-over between Controller instances. - The JS7 - Permissions article contains a link to a full explains the list of all Permissions that can be granted.
Editing Permissions
- permissions.
Permission Assignment
Assign specific Permissions only
Consider a user account being assigned an application_manager
role holding Consider any user have a role(demo-role
) with the following permission:
sos:products:controller:view
This permission does not allow the demo-role
to perform the operation on the Controllers. These Permissions could be granted individually with the followingapplication_manager
role to perform any modifying operations on Controllers. Instead, such permissions are granted individually by using:
sos:products:controller:restart
sos:products:controller:terminate
Assign global Permissions, Deny specific Permissions
The following Permissions can be set to permissions allow the Role demo-role
application_manager
role to view, restart and terminate the and to restart a Controller, but not Switch_overnot to terminate a Controller and not to switch-over between Controller instances:
sos:products:controller:view
sos:products:controller:restart
Alternatively, it may make sense in some situations users might prefer to grant the Role role a higher level of Permission permissions and then remove to deny one or more specific Permissionspermissions. This approach is shown in used for example with the following combinationpermission set:
sos:products:controller
-sos:products:controller:switch_over
where the ...The sos:products:controller
Permission permission is an overall 'Controller' Permission covering Controller permission including permissions to view, restart and terminate, and the a Controller. The -sos:products:controller:switch_over
Permission is removed from the demo-role Role.
Caution
permission is denied.
Minimum Permission Assignment
User accounts have to be assigned a role with the following minimum permission set in order to be able to login to Users should have Role with the following Permission - or higher - before they are able to log into the JOC Cockpit:
sos:products:joc:administration:controller:view
Assignment Operations
Anchor | ||||
---|---|---|---|---|
|
A role can be added from the Roles view
Editing Procedures
Three editing procedures are available for editing Permissions:
by use of the Add Role button like this:
Anchor | ||||
---|---|---|---|---|
|
Graphical Permissions View
Permissions are added by clicking the relevant permission icon in the Graphical Permissions View:
Unassigned Permissions
The white background color indicates that a permission is not assigned, i.e. is not granted and it is not denied.
Clicking the middle of an unassigned (white) permission grants the permission (dark blue).
Granted Permissions
A dark blue background color indicates that a permission is granted and that the grant is inherited to child permissions recursively.
Clicking the middle of a granted permission revokes the grant and puts the permission to the unassigned status (white).
Denied Permissions
The dark grey background color indicates that a permission is denied and that the denial is inherited to child permissions recursively..
Clicking the -
of a denied permission revokes the denial and makes it a granted permission (dark blue). Clicking once again makes it an unassigned permission (white).
Textual Permissions View
...
The Add Permission button in the Permissions
View allows a Permission to be selectedsub-view allows selection of permissions from a list
of all available Permissions as shown in the screenshotas described below.
- Note that the Permissions listed are all individual Permissions. They can be edited to make them higher level / less specificspecific permissions are used from a list. Users can modify permissions to have a more global or more specific scope.
- For example, in the screenshot below shows that , the
...administration:controller:view
permission in the process is selected.sos:products:joc:get_log
permission is assigned: - Additive Permissions: by default selected permissions are granted, Selected permission can also be made subtractive - i.e. they are added to the role's permission set.
- Subtractive Permissions: selected permissions are denied by removing to remove a specific part of a higher level Permission.more global permission. This is done achieved by ticking use of the Excluded checkbox, which is obscured in the above screenshot..
- For example, in the screenshot below shows that , the
Anchor | ||||
---|---|---|---|---|
|
Graphical Permissions View
See the instructions provide above about how to Add Permissions.
Textual Permissions View
Permissions can be modified by moving the mouse to one of the permissions displayed:
When the mouse is hovering the permission then the following editing icons are displayed:
Explanation:
- The pencil icon is displayed to offer modification of the permission.
- The X icon can be used
Modifying Existing Permissions:
- The pencil symbol is shown alongside existing Permissions in the Permissions view (shown in the screenshot above) can be used to change the function of a Permission in a Role - to make an additive Permission subtractive and vice-versa. It cannot be used to edit a Permission. The X symbol displayed alongside existing permissions in the Permissions sub-view is used to remove a permission from a role.
- Note that a role must be configured to be assigned either a permission or a folder as otherwise the role is considered empty and will be deleted.
- Note that if a user account is not assigned the following permission (or a permission from a higher level) then this user account will not be able to login to JOC Cockpit:
sos:products:joc:administration:controller:view
- The Expand All button (shown in the above screenshot) can be used to open all the tree elements.
- Navigation is carried out by dragging & dropping the tree view.
- The functions available for the tree elements are (with reference to the screenshot below):
- Select / Unselect a Permission - click on the body of an unselected / selected element
- Selected Permission elements are shown in blue (see the view element in the screenshot)
- Children of selected Permission elements are shown in light blue (as shown in the screenshot)
- Select / Unselect a Permission - click on the body of an unselected / selected element
- Deny a Permission - click on the plus sign at the left hand end of the element
- Revoke a Permission Denial - click on a - sign at the left hand end of the element
- Show / hide child elements - click on the + / - symbols at the right edge of an element
- In the following screenshot the administration element has been selected, automatically selecting the administration:accounts, administration:certificates, administration:controllers, administration:customization, administration:settings In addition, the controllers:manage child permission has been denied, resulting in the fact that the controllers:view is active only.
Graphical Permission Editing:
The graphical view is activated by selecting the 'tree' symbol at the top right corner of the Permissions sub-view:The editor opens with a partially collapsed permissions tree as shown in the next screenshot:
Manage Permissions specific for a Controller
When clicking the pencil icon then the following popup window opens:
This allows the permission to be switched or be made an Additive Permission or Subtractive Permission depending on the Excluded checkbox.
Anchor | ||||
---|---|---|---|---|
|
By default user accounts are granted permissions for any Controllers registered with JOC Cockpit. Permissions that should be applicable to a Specific By default User Accounts are granted permissions for all Controllers in a scheduling environment. Permissions that are applicable to a particular Controller only can be added to a role. This can be achieved in from the Manage Roles sub-view of the Identity Management Service.
Roles view:
In the above screenshot, the demoapplication_
rolemanager
role has been assigned for the is assigned a Specific Controller with ID controller2.2.0 testsuite
.
When the testsuite
Controller is selected the role displays two links for default
Controller and for the testsuite
Controllers like this:
. and will appear in the list of roles as follows.
In this configuration, the demoapplication_
rolemanager
role does is not yet have granted any permissions specific to the Controller ID controller2.2.0. At least testsuite
. A minimum of one permission needs has to be added before the controller2.2.0 - demo_role configuration will be stored persistently.
The interaction of default Controller permissions and Controller specific permissions within the same role is illustrated as follows.
:
- Default Permissionsdefault permissions:
sos:products:controller:view
- -specific permissionsPermissions for a Specific Controller such as
testsuite
:sos:products:controller:agents:view
The Dashboard view for all Controllers will display The JS7 - Dashboardallows switching between connected Controllers and the display of the status of Agents registered with the current Controller but the status of Agent Clusters will only be displayed for the specified Controller - in this case for Controller ID controller2.2.0.
Manage Folder Permissions
respective Controller. This requires that the view permission described above for the Controller is in place.
Assign Folder Permissions
Inventory folders can be Folders are used to restrict access to objects such as workflows and schedules. For example, user accounts can be limited restricted to access objects for particular mandators / clients only.
...
This is achieved by adding a folder permissionpermissions, i.e. a set of permissions to view only the content of a specific folder only. With a folder permission being permissions in place the permission to access any other folders is automatically revokeddenied. If Should folder permissions should be used for applied to a number of folders then each folder permission has to be specified added individually for the given role.
Add Folder
...
Folder permissions are granted from the Permissions sub-view. Note that before folder permissions can be assigned a role, the role has to be specified for a user account. In the below example, a test user account and demo_role role have been configured and the demo folder has been created in the inventory.
To open the Permissions sub-view for a specific role, first open the Manage Identity Services page for the respective Identity Service, switch to the Roles sub-view and select the role that should be assigned folder permissions. For assignment click the name of the role in the list of roles.
...
Inventory folders are added by use of the Add Folder button visible in the upper right corner of both the Graphical Permissions View and the Textual Permissions View for the relevant role like this :
Explanation:
- Folders are selected from a tree widget that is opened by clicking the folder input field.
- The Recursive option grants access to any sub-folders of the selected inventory folder.
Check the Recursive checkbox in the Add Folder popup window if recursive access to sub-folders is required and click the Submit button.
Any user account that is assigned the demo_role will be able to access scheduling objects in the demo folder only.
Note that the test user account will be able to log in to the JOC Cockpit without being assigned a role, however, no menu items and no functionality is offered from the GUI. A minimum permission is required e.g. by a role that grants the following permission:
sos:products:controller:view