Page History
Table of Contents |
---|
Introduction
- JS7 - Identity Services implement implement Authentication Methods and access to Identity Providers, for . For example, credentials such as user account/password are used as an Authentication Method to access an LDAP Directory Service acting as the Identity Provider, see see the JS7 - Identity and Access Management.
- JOC Cockpit implements a pluggable architecture that allows to add Identity Service products with future JS7 releases.
- For compatibility reasons early releases of JS7 include the Shiro Identity Service, see
Jira server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1145 Display feature availability EndingWithRelease 2.3.0
...
- article for more information.
- Depending on the Identity Service Type in use, the user accounts are managed and stored with the Identity Service or with the JOC Cockpit, see JS7 - Identity Services.
- The JOC Cockpit manages permissions and roles for any Identity Services and stores such information independently of the Identity Service.
- Find details from the following articles:
Manage User Accounts, Roles and Permissions
After installing the JOC Cockpit , a user can log in with the default root:root
user name account and password which comes under the Shiro identity service.
The Manage Accounts section of the JOC Identity is then accessed via the Profile Menu as shown in the screenshot below. Select Identity Management Service.
The Identity Management Service window has the list of the available Identity Services which is previously created or you can also create a new Identity service. From here you can select the Identity Services to manage the accounts inside it. Select the JOC from the list.
The JOC Identity Service window has the three main section which can managed via the tabs:
- Accounts: for the configuration of User Accounts. Accounts configured in the Database and access from there only.
- Manage Roles: for configuring Roles and the Controller that can be accessed by a Role.
- Permissions: a sub-view for configuring access to Folders and Role Permissions.
- Profile: from this view user can check the last login detail.
These tabs will be described in the following sections.
The Accounts Tab
The Accounts tab is opened first when a user selects the Identity Service from the Identity Management Service window and lists all the User Accounts that have been configured along with the Roles they have been assigned.
The above screenshot shows the test User Account which is manually created with the role. Currently, JOC Identity Service does not contain any default account and roles inside it.
- The Create Account button is used to open a window to add a new User Account with name, password, and Roles.
- The additional options (ellipsis) symbol allows an Account to be edited (change the Account Name and/or Password, select/deselect Roles) and to be copied or deleted.
- Clicking on the Account Name brings the user to the Manage Roles tab (described below) where the Controllers and Role(s) allocated for the User Account can be edited.
The Manage Roles Tab
The main purpose of the Manage Roles tab is to allow Controller Roles and any Controller which these Roles will be restricted to be configured.
When the tab is first opened after installation of the JOC Cockpit it will be blank and no roles are created by default. In the below screenshot you can see test-role created manually.
Roles contain default in the controller which means the role is available for all the Controllers - the default setting.
If the Manage Roles tab is opened by clicking on an Account Name in the Accounts tab (described in the previous section), the Manage Roles Tab will show those Roles that have been assigned to that Account. The Account that is active is shown in the Account button, which can also be used to select and deselect Accounts.
Positioning the mouse over a role name blends in two links as shown in the screenshot above:
- the pencil link allows the role to be edited and
- the X link allows the role to be deleted.
A set of Permissions is configured for each role. Each Permissions set can be inspected by clicking on the default from the list of roles, which will open the Permissions tab for the Role. An example Permissions set is described in the next section. A matrix showing the default Roles and their Permissions along with a description of the Permission is provided in the JS7 - Permissions article.
The Permissions Sub-View
The main purpose of the Permissions view is to allow Folders and Permissions to be configured for each Role.
Folder Selection
Folders are added using the Add Folder button shown in the background of the screenshot below, at the top right.
Folders themselves are selected from a simple tree view of the folders. This tree view is opened by clicking on the folder symbol shown in the screenshot.
Permissions Configuration
Two editors are available for the configuration of the Permissions granted for a Role:
...
- The states saved in the Undo button will be deleted when the Permissions tab is left.
...
- The state stored in the Redo button will be deleted when the Permissions tab is left.
...
- Granted Permissions have a blue background and are by default recursive.
...
- Individual Permissions can be modified and removed from the Role using the pencil and X symbols that are blended in when the user's mouse is moved over a Permission:
- The Edit function allows the 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 workflow.
Initial Configuration
Creating and Configuring User Accounts and Roles
System administrators will likely want to create and configure their own User Accounts and Roles, for example, limiting access to resources such as JobScheduler objects 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.
Creating a new Role
- New Roles are created in the Manage roles tab using the Add Role button:
- Once a new Role has been created it will be automatically added to the list of Roles shown in the background of the screenshot above.
Configure Permissions and/or Folders for the Role
- Now expand the Role using the arrow button click on the default (blue link) to add Permissions and/or Folders in the Permissions tab. The Procedures available for adding and editing Permissions and Folders are described in the Editing User Permissions and Folders sections below.
- Note that Roles that neither have Permissions or Folders assigned to them are deleted automatically when the Manage Identity Service view is left.
Create a new User Account
...
- Note that deselecting a Role in this modal window 'uncouples' the Role from the User Account - it does not delete the Role.
Editing User Permissions
Permissions Structure
Permissions are strictly hierarchical:
- 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 able to carry out other 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 -
Permission is removed from the demo-role Role.sos:products:controller:switch_over
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:
root
password that are available from the JS7 - JOC Identity Service.
- The
JOC
Identity Service is active and is the only Identity Service available by default. - The
JOC
Identity Service includes the defaultroot
user account. Users are encouraged to change the password of theroot
user account after initial installation of the JOC Cockpit.
To manage user accounts, roles and permissions from any JOC Cockpit page, use the user menu in the right upper corner and select Manage Identity Services:
The Manage Identity Services page holds the list of the available Identity Services. By default the list is populated from the JS7 - JOC Identity Service. Users can add new Identity Services. From this page users can select an Identity Service to manage the user accounts associated with the Identity Service. Assume that the JOC
Identity Service is selected by clicking the name JOC
.
The JOC
Identity Service page offers three sub-views: Roles, Accounts, Profiles. Selecting an Identity Service by default opens the Roles sub-view.
- Roles: Permissions can freely be grouped to roles. This includes specifying permissions for scheduling objects in the JOC Cockpit and in Controllers.
- Accounts: Management of user accounts that are stored with the JS7 - Database.
- Profiles: Information about the date of last login by user accounts.
The Roles sub-view
The Roles sub-view allows assignment of permissions for access to scheduling objects with the JOC Cockpit and Controllers.
When the sub-view is opened after initial installation of JOC Cockpit, then it is populated with default roles and permissions, see the JS7 - Default Roles and Permissions article for more information. Users are free to modify, add and delete any roles. Please keep in mind that at least one role that includes administrative permissions to access all objects in the JOC Cockpit and Controllers is required and has to be assigned an administrative user account. Should an administrative role no longer be left 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.
The Accounts sub-view
The Accounts sub-view is available when a user selects the Identity Service from the Identity Management Services page. This sub-view lists the user accounts that are configured along with their roles.
The Permissions sub-view
This view allows graphical navigation and the selection of permissions:
Further Resources
Display children header |
---|
...
- 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 alongside existing Permissions in the Permissions view can be used to remove an existing Permission from a Role.
- Note that a Role must be configured to have either a Permission or a Folder or it will be deleted.
- Note that if a user does not have the following permission or higher they will not be able to log into the JOC Cockpit interface:
sos:products:joc:administration:controller:view
...
Graphical Permissions Editing:
- The Graphical Permissions Editor is activated by selecting the 'Tree' symbol at the top right of the Permissions section.
- 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)
- Select / Unselect a Permission - click on the body of an unselected / selected element
- Negate a Permission - click on the plus sign at the left hand end of the element
- Remove a Permission Negation - 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 of an element
...
Controllers-Specific Permissions
By default User Accounts are granted Permissions for all the Controller and Controller Clusters in a scheduling environment. Permissions that are only applicable to a particular Controller or Controller Cluster can be added in a role. This is done in the Manage Roles tab of the Identity Management Service for JOC.
In the screenshot, the demo_role Role has been assigned for the controller with the ID controller2.2.0. and will appear in the list of the role as shown.
In this configuration, the demo_role will not yet have any Permissions that are specific to the controller2.2.0. At least one Permission needs to be added before the controller2.2.0 - demo_role configuration will be permanently saved.
The interaction of default and controllers-specific Permissions within the same Role can be illustrated as follows.
- default Permissions:
sos:products:controller:view
- Master-specific Permissions:
sos:products:controller:agents:view
The dashboard view for all controllers in the environment will show the status of the current controller but the status of Agent Clusters will only be shown for the specified controller - in this case controller2.2.0.
Folders
Folders are used to restrict User access to the objects such as workflows and Schedules. This means that, for example, Users can be restricted to accessing only objects for particular mandators / clients.
By default, Permissions are granted for all the folders. However, Roles can be restricted to accessing specific folders.
This is done by granting a Folder Permission, i.e. Permissions to view the content of a folder. When this is done, the Permissions to view all other folders are automatically revoked.
Granting Folder Permissions
Folder Permissions are granted in the Permissions View. Note that before Folder Permissions can be saved for a Role, the Role has to be specified for a User. In the example below, a test user and demo_role have already been configured and the demo folder created on the file system.
To open the Permissions view for a particular Role, first open the Identity Management Service for JOC view, switch to Manage Roles and select the Role that is to be granted Folder Permissions. To do this, click on the Role name in the Roles list.
Now click on the Add Folders button and in the Add Folders modal window, select the subfolder or the parent folder demo/
or /demo/
*.
Check the Recursive box in the Add Folders modal window if required and then click on Submit.
Any User that is allocated this demo_role will now only be able to see JobScheduler objects in the demo folder.
Note that the test user will only be able to log in to the JOC Cockpit if they have at least one Role granting them the following Permission:
sos:products:controller:view
Roles with Folder Permissions are often configured for Users in combination with default Roles.
Shiro Identity Service Settings
The Shiro Identity Service does not require any settings.