Introduction

Operations

Manage Permissions

Permissions Structure

Permissions are organized in a hierarchical way:

• A Role with the Permission sos:products:controller:view 'only' allows a User to view Controllers, 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, view, restart, terminate, and switch_over.
• The JS7 - Permissions article contains a link to a full list of all Permissions that can be granted.

Editing Permissions

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 following:

sos:products:controller:restart
sos:products:controller:terminate

The following Permissions can be set to allow the demo-role Role to view, restart and terminate the Controller, but not Switch_over:

sos:products:controller:view
sos:products:controller:restart

Alternatively, it may make sense in some situations to grant the Role a higher level of Permission and then remove one or more specific Permissions. This approach is shown in the following combination:

sos:products:controller
-sos:products:controller:switch_over

where the ...sos:products:controller Permission is an overall 'Controller' Permission covering view, restart and terminate, and the -sos:products:controller:switch_over Permission is removed from the demo-role Role.

Caution

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

Editing Procedures

Three editing procedures are available for editing Permissions:

• Adding Permissions:

  • The Add Permission button in the Permissions View allows a Permission to be selected from a list of all available Permissions as shown in the screenshot below.
    • Note that the Permissions listed are all individual Permissions. They can be edited to make them higher level / less specific.
      
      • For example, the screenshot below shows that the ...administration:controller:view permission in the process is selected.
        
        
        
        
      • Selected permission can also be made subtractive - i.e. to remove a specific part of a higher level Permission.
        • This is done by ticking the Excluded checkbox, which is obscured in the above screenshot.

• 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

• 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:
    
    
    
    
    • 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)
• 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.
  
  
  
  

Manage Permissions specific for a Controller

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 the Manage Roles sub-view of the Identity Management Service.

In the screenshot, the demo_role role has been assigned for the Controller with ID controller2.2.0. and will appear in the list of roles as follows.

In this configuration, the demo_role role does not yet have any permissions specific to the Controller ID controller2.2.0. At least one permission needs 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 permissions:
  • sos:products:controller:view
• Controller-specific permissions:
  • sos:products:controller:agents:view

The Dashboard view for all Controllers will display the status of 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

Folders are used to restrict access to objects such as workflows and schedules. For example, user accounts can be limited to access objects for particular mandators / clients only.

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

This is achieved by adding a folder permission, i.e. a set of permissions to view the content of a specific folder only. With a folder permission being in place the permission to access other folders is automatically revoked. If folder permissions should be used for a number of folders then each folder permission has to be specified individually.

Add Folder Permissions

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.

Click the Add Folders button and in the popup window select a root level folder or a sub-folder such as /demo/*. or demo/.

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