...

• 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 offers to manage provides the management of roles.
  • The JS7 - HashiCorp® Vault Identity Service offers to manage provides management of roles if the VAULT Identity Service Type is used.
• Permissions are managed from JOC Cockpit independently from of the Identity Service in use.
• For the assignment of roles to user accounts see see the JS7 - Manage User Accounts article.

Roles and Permissions

Role based Access Management

...

• 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. Frequently roles 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 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. Should no administrative role be left If all administrative roles are deleted, then this corresponds to locking the door behind you and throwing away the keys. In this situation consider refer to the JS7 - Rescue in case of lost access to JOC Cockpit article.

Scope and Structure of Permissions

...

• Scope
  • JOC Cockpit Permissions are assigned for operations in JOC Cockpit, for example to manage , for managing calendars and the daily plan etc.
  • Controller Permissions are assigned for operations on scheduling objects per Controller, for example to deploy , for deploying workflows, to add 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 any all Controllers and they can be specified on a per 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 permission permissions can be overruled from any all roles, they . They can be:
          • denied by a permission of the Default Controller specified by some other 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 any all roles unless denied by a permission from a role for the given Controller.
        • Denied permissions work without limits across any all roles for the given Controller.

...

Views are available for roles and and permissions including the Graphical Permissions View and the Textual Permissions View.

Roles View

From the list of Identity Services users 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:

For each role a A default link is available for each role to navigate to the Graphical Permissions View. 

...

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 not neither granted and is not 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.
  • Undo/Redo
    • Changes to the permissions tree are stored to 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.

...

The right upper corner of the Permissions sub-view offers allows the user to toggle between the Graphical and Textual Permissions ViewViews.

• Explanation:
  • Individual permissions can be modified and can be removed from a role using the pencil icon and X icon that , 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 that any scheduling objects such as workflows which are only visible from the assigned folder only.

Assignment Strategies

Permission Hierarchy

...

• A role with the permission sos:products:controller:view allows a user to view Controllers only, while a user with the sos:products:controller permission is able to carry out any operations such as to  view, to restart, to terminate, and to switch-over between Controller instances.
• The JS7 - Permissions article explains the list of permissions.

...

The sos:products:controller permission is an overall Controller permission including permissions to view, to  restart and to  terminate a Controller. The -sos:products:controller:switch_over permission is denied.

...

User accounts have to be assigned a role with the following minimum permission set in order to be able to login to the JOC Cockpit:

sos:products:joc:administration:controller:view

...

Permissions are added by clicking the respective relevant permission icon in the Graphical Permissions View:

...

• The Add Permission button in the Permissions sub-view allows to select selection of permissions from a list as explained described below.

• Note that specific permissions are used from a list. Users can modify permissions to to have a more global or to a more specific scope.
  
  • For example, with in the screenshot below screenshot , the sos:products:joc:get_log permission is assigned:
    
    
    
    
  • Additive Permissions: by default selected permissions are granted, i.e. they add are added to the role's permission set of a role.
  • Subtractive Permissions: selected permissions are denied to remove by removing a specific part of a more global permission. This is achieved by use of the Excluded checkbox.
    
    

...

Graphical Permissions View

See explanations the instructions provide above about how to Add Permissions.

Textual Permissions View

...

When clicking the pencil icon then the following popup window opens:

This allows to switch the permission or to make it to be switched or be made an Additive Permission or Subtractive Permission depending on the Excluded checkbox.

...

In the above screenshot, the application_manager role is assigned a Specific Controller with ID testsuite.

With When the testsuite Controller being is selected the role displays two links for default Controller and for the testsuite Controllers like this:

...

• Default Permissions:
  • sos:products:controller:view
• Permissions for a Specific Controller such as testsuite:
  • sos:products:controller:agents:view

The JS7 - Dashboardoffers to switch allows switching between connected Controllers and to the display of the status of Agents registered with the respective Controller. This requires that the above view permission described above for the Controller is in place.

...

By default permissions are granted for any all folders. However, roles can limit access to specific folders.

This is achieved by adding folder permissions, i.e. a set of permissions to view only the content of a specific folder only. With folder permissions being in place the permission to access any other folders is automatically denied. Should folder permissions be applied to a number of folders then each folder has to be added individually to for the given role.

Add Folder

Inventory folders are added by use of the Add Folder button visible in the upper right corner of both the Graphical Permissions View and of the Textual Permissions View of for the respective relevant role like this :

Explanation:

...