Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Permissions sub-view allows to configure manage permissions for roles, optionally limited to specific folders.

Folder Selection

...

  • Scope
    • JOC Cockpit Permissions are assigned for operations in JOC Cockpit, for example to manage calendars and the daily plan etc.
    • Controller Permissions are assigned for operations on scheduling objects per Controller, for example to deploy workflows, to add 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 Controllers and they can be specified on a per Controller basis.
  • States
    • Permissions can take one of three states, being unassigned, granted or denied.
    • An unassigned permission does not take any assumption if the permission is granted or denied.
    • A granted permission is active within limits as is can be overruled by denied permissions.
    • A denied permission is active without limits and cannot be overruled by granted permissions.
  • Merge
    • Permissions are assigned to roles. A user account can accumulate a number of roles, therefore the permissions are merged 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 can be overruled from any roles, they can be
            • denied by a permission of the Default Controller specified by some other role,
            • denied by a permission for a Specific Controller.
          • Denied permissions 
        • Specific Controller
          • Unassigned permissions are ignored, instead the permission of the Default Controller is applied.
          • Granted permissions work across any roles unless denied by a permission from any role for the given Controller.
          • Denied permissions work without limits across any roles for the given Controller.
  • Permission Tree
    • Permissions are organized from a tree that offers a hierarchy of branches.
    • Granting or denying permissions at a higher level inherits the permission recursively to deeper levels of the tree.

Permission Management

A graphical and a textual view are available for management of permissions added to a role.

The Graphical View

This view allows graphical navigation and selection of permissions and is the default view.

Image Added

  • 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.
    • States and Colors
      • Permissions show the following background colors to indicate their state:
        • White: Permission is not assigned, i.e. is not granted and is not 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.
      • 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 state (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 state.
    • Undo/Redo
      • Changes to the permissions tree are stored to 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

Image Removed

Folders are selected from a tree view that is opened by clicking the folder icon, see screenshot.

Permissions Configuration

Two editors are available for configuration of permissions added to a role:

  • The Graphical Editor
    Image Removed
    • Explanation:
      • Changes to the permissions tree are stored to 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 state held with the Redo button is deleted when a user leaves the Permissions sub-view.
      • Clicking on the middle of a Permission icon will grant the Permission for the current Role.
        • Granted Permissions have a blue background and are by default recursive.
      • The "+" and "-" symbols at the right edge of each permission icon open and close child branches.
      • The "-" and "+" symbols at the left edge of each permission icon are used to recursively revoke permissions that are located deeper in the permissions tree.
      • Permissions that are affected by revoked permissions are displayed with a gray background 
    The List Editor
      • The Redo button changes the permissions tree back to its initial state when the Permissions sub-view is displayed.
        • The state held with the Redo button is deleted when a user leaves the Permissions sub-view.

The Textual View

The editor displays permissions from a lists of textual entries. The right upper corner of the Permissions sub-view offers to toggle between graphical view and textual view.

Image Modified

  • Explanation:
    • Individual Permissions permissions can be modified and removed from the Role role using the pencil and X symbols icons that are blended faded in when the user's mouse is moved over a Permission:permission.
    • The Edit function allows the Permission permission to be made subtractive - , i.e. for permission granted at a higher level to be removed.The Folder part of the view is for restricting the Role to accessing particular Folders - and thereby particular workflowremoved.
    • 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 are visible from the assigned folder only.

Folder Selection

Folders are added using the Add Folder button visible in the background of the below screenshot in the upper right corner:

Image Added


Folders are selected from a tree view that is opened by clicking the folder icon, see screenshot.

Configuration

Manage User Accounts and Roles

administrators Administrators create and configure User Accounts user accounts and Rolesroles, for example, to limit access to resources such as workflows and logs.

It is often easier to create Manage new Roles, assign Permissions or Folders to these Roles and then create new User Accounts and assign Roles to them.

...

straightforward to first add roles, then assign permissions - optionally limited to folders - and finally to add user accounts and to assign roles.

Add a Role

  • Roles are created from the Roles sub-view using the Add Role button:



  • Once the role has been is created it will be is added automatically to the list of roles displayed in the background of the above page.

Configure Permissions

...

for a Role

  • Now expand the Role using the arrow button click on the default (blue link) to add Permissions and/or Folders in the Permissions sub-view. The procedures available for managing permissions and folders are explained with the Editing User Permissions and Folders sections below.
    • Note that roles that neither have permissions nor folders assigned are deleted automatically when a user leaves the Manage Identity Service page.

...

Add a

...

User Account

  • After Permissions / Folders have been With permissions / folders being configured select the Accounts tab sub-view to create a new User Account and allocate add a user account and assign one or more Roles to this Accountroles.



  • The Edit Account function is accessed by clicking the relevant Action symbol (ellipsis) in the  Actions column of the User Accounts list (visible in the background of the above screenshot). This can be used to change the Password, the Account password or account name and to add or to remove Rolesroles
    • Note that deselecting a Role role in this modal popup window 'uncouples' the Role role from the User Account user account - it does not delete the Rolerole

Manage User 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 shown symbol displayed alongside existing Permissions permissions in the Permissions sub-view can be is used to remove an existing Permission a permission from a Rolerole.
    • Note that a Role role must be configured to have be assigned either a Permission permission or a Folder or it folder as otherwise the role is considered empty and will be deleted.
    • Note that if a user does account is not have assigned the following permission (or higher they a permission from a higher level) then this user account will not be able to log into the login to JOC Cockpit interface:
      • sos:products:joc:administration:controller:view
  • Graphical
    Permissions
    Permission Editing:
    • The Graphical Permissions Editor graphical view is activated by selecting the 'Treetree' symbol at the top right corner of the Permissions section 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)
    • Negate Deny a Permission - click on the plus sign at the left hand end of the element
    • Remove Revoke a Permission NegationDenial - click on a - sign at the left hand end of the element
    • Show / hide child elements - click on the + / - symbols at the right hand end edge of an element
  • In the following screenshot the administration element has been selected, automatically selecting the administration:accountsadministration:certificates, administration:controllers, administration:customization, administration:settings
  • In addition, the controllers:manage child permission has been negated, meaning that only 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 and Controller Clusters in a scheduling environment. Permissions that are applicable to a particular Controller or Controller Cluster only can be added to a role. This can be achieved in the Manage Roles sub-view of the Identity Management Service for JOC.



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



In this configuration, the demo_role role will not  role does not yet have any Permissions that are permissions specific to the Controller ID controller2.2.0. At least one Permission permission needs to be added before the controller2.2.0 - demo_role configuration will be permanently savedstored persistently.

The interaction of default Controller permissions and controllers-Controller specific Permissions permissions within the same Role can be role is illustrated as follows.

  • default Permissionspermissions:
    • sos:products:controller:view
  • MasterController-specific Permissionspermissions:
    • sos:products:controller:agents:view

The Dashboard view for all Controllers in the environment will display the status of the current Controller but the status of Agent Clusters will only be shown displayed for the specified controller 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 restricted limited to access objects for particular mandators / clients only.

...

This is achieved by adding a Folder Permissionfolder permission, i.e. a set of permissions to view the content of a specific folder only. With a Folder Permission 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.

Granting Folder Permissions

...