Introduction
The JOC Cockpit comes with an editor for Managing Authentication and Authorization - the Manage Accounts view. FEATURE AVAILABILITY STARTING FROM RELEASE 1.11.2
Permissions Hierarchy
Permissions are configured hierarchically:
- User Account
- Role(s)
- Permission(s)
- Role(s)
In addition:
- Permissions can be restricted to specific JobScheduler Master IDs and
- Roles can be restricted to specific Folders within a JobScheduler's live folder.
Using the Manage Accounts view
Getting Started
After installing the JOC Cockpit, log in with the default root:root user name and password.
The Manage Accounts section of the JOC Cockpit is then accessed via the Profile Menu as shown in the screenshot below.
The Account Manager has three main Views:
- Accounts: for the configuration of User Accounts. Accounts configured here use shiro name / password Authentication.
- Note that while Shiro authentication is not as secure as, for example, LDAP, it provides a convenient basis for configuring authorization in a test environment.
- See the JOC Cockpit - Authentication and Authorization article for more information about Shiro and other methods of authentication that can be used with the JOC Cockpit.
- Masters: for configuring the JobScheduler Masters that can be accessed by a Role
- Permissions: for configuring access to Folders and the Permissions for a Role
These views will be described in the following sections.
The Accounts View
The Accounts view is the view that is opened first when a user selects the Manage Accounts view and lists all the User Accounts that have been configured along with the Roles they have been assigned.
The above screenshot shows the default root User Account which is the only Account that is configured after installation of the JOC Cockpit.
The Create Account button is used to open a window to add a new User Account - clicking on the additional option (ellipsis) symbol or the Account name brings the user to the Masters view (described below) where the Account Name, Password and Role(s) allocated can be edited.
The Masters View
The main purpose of the Masters view is to allow JobScheduler Master Roles to be configured.
When the view is first opened after installation of the JOC Cockpit it will appear as shown in the next screenshot:
The above screen shows seven default roles that are provided with the JOC Cockpit. These Roles are intended to help system administrators get a realistic authorization configuration working as quickly as possible and can be modified as required. These roles are valid for all JobScheduler Master instances in the environment.
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 Role name in the Masters view list. An example Permissions set is described in the next section.
The Permissions View
The main purpose of the Permissions view is to allow Permissions and Folders to be configured for each Role.
The screenshot below shows the default permissions for the administrator Role.
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 the Permission to be made subtractive - i.e. for a 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 Jobs, Job Chains, etc - within a JobScheduler Master's live
folder and will be described later.
Editing Permissions is described below .
Initial Configuration
Adding User Accounts and Roles
The following example describes how to add User Accounts to the JOC Cockpit in addition to the default root user account. Each User Account will be assigned one of the default Roles described in the Masters View section above and for simplicity will use the same name as the Role they will be given.
To add a Business User Account:
- Go to the Accounts view and click on the Create Account button at the top right.
- This will open the following window:
- Account Names may not contain spaces.
- Selecting the business_user Role from the list will avoid possible errors from a mistyped role name.
- It will be clear form the functioning of the Roles selection that any number of Roles can be specified for a User Account if required.
- Click the Submit Button to save the Account configuration.
- Note that if one of the Accounts should contain a configuration error (such as a blank space in an Account Name), none of the Accounts will be saved to the configuration file.
Once a User Account has been created for each of the default Roles, the Accounts view would look like:
Account Use
The root User can now be logged out via the Profile Menu and the other User Accounts used.
Individual Users can check - but not change - the Permissions they have been granted in the Profile View for their Account as can be seen in the following screenshot which shows part of the Permissions section for Administrator Account with the default administrator Role.
Note that as the default administrator Role is granted a limited Permissions set, the Main Menu Bar in the JOC Cockpit only contains a link to the Dashboard view as can be seen in the screenshot below. In contrast, the root User Account has links for a further seven views as shown in the screenshots above).
By default the administrator Role is granted Permissions for the Manage Accounts view and therefore the configuration of the User Accounts will continue using this Account rather than root.
The screenshot below shows the Permissions granted to the Account administrator that has been assigned the administrator role with the default Permissions set:
A matrix describing and listing the Permissions that are granted by default for the default Roles is available in the Authentication and Authorization - Permissions for the JOC Cockpit Web Service article.
In addition, the same article contains a link to a full list of all Permissions that can be granted.
Editing User Permissions
Permissions Structure
Permissions are strictly hierarchical:
- A Role with the Permission
sos:products:joc_cockpit:jobscheduler_master:view
'only' allows a User to view JobScheduler Masters while a User with the 'higher'sos:products:joc_cockpit:jobscheduler_master
Permission is able not only to view JobScheduler Masters but able to carry out all other operations - view, execute and administrate.
Editing Permissions
Consider the default business_user
Role, which has the following permission:
sos:products:joc_cockpit:jobscheduler_master:view
:status
This permission does not allow the business_user
Role to access JobScheduler Master log files or parameters which would be granted individually with the following Permissions:
sos:products:joc_cockpit:jobscheduler_master:view
:mainlog
sos:products:joc_cockpit:jobscheduler_master:view
:parameters
The following Permissions can be set to allow the business_user
Role to view JobScheduler Master statuses and log files but not parameters:
sos:products:joc_cockpit:jobscheduler_master:view
:status
sos:products:joc_cockpit:jobscheduler_master:view
:mainlog
Alternatively, it may make sense in some situations to grant the Role a higher level Permission and then remove specific Permissions. This approach is shown in the following combination:
sos:products:joc_cockpit:jobscheduler_master:view
-sos:products:joc_cockpit:jobscheduler_master:view
:
parameters
where the ...jobscheduler_master:view
Permission is an overall 'view' Permission and the -sos:...jobscheduler_master:view
Permission is removed from the :
parameters
business_user
Role.
Caution
Users have to have a Role with the following Permission - or higher - before they are able to log into the JOC Cockpit:
sos:products:joc_cockpit:jobscheduler_master:view:status
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
...jobscheduler_master:execute:restart:terminate
permission in the process being selected. - Once selected the Permission can be edited before the Submit button is clicked. This allows, for example, the Permission to be modified to
...
, allowing the Role to carry out all operations covered by this Permission. These are:jobscheduler
_master:execute:restart
sos:products:joccockpit:
jobscheduler
_master:execute:restart:terminatesos:products:joccockpit:
jobscheduler
_master:execute:restart:abort
- The following screenshot shows the edited version alongside the original:
- A 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.
- For example, the screenshot below shows that the
- Note that the Permissions listed are all individual Permissions. They can be edited to make them higher level / less specific.
- 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.
Modifying Existing Permissions:
- The pencil symbol 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.
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 tree 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 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
- Select / Unselect a Permission - click on the body of an unselected / selected element
In the following screenshot the view element has been selected, automatically selecting the view:status, view:parameter and view:mainlog child permissions.
In addition, the view:mainlog child permission has been negated, meaning that only the view:status and view:parameter child permissions are active.
JobScheduler-Specific Permissions
By default User Accounts are granted Permissions for all the JobScheduler Masters and JobScheduler Master Clusters in a scheduling environment. However, Roles can be created that are only able to access one or more specific JobScheduler Masters or JobScheduler Master Clusters in the environment. This is done in the Masters section of the Manage Accounts view as shown in the next screenshot.
Note that if one of the default Roles is configured to apply for a specific JobScheduler Master then it will no longer apply for the other Masters in the environment.
- The Graphical Permissions Editor is activated by selecting the 'Tree' symbol at the top right of the Permissions section.
Folders
Folders are used to restrict User access to JobScheduler objects such as Jobs, Orders 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 within a JobScheduler's live folder. However Roles can be restricted to accessing specific folders within a live folder.
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 demo_user and demo_role have already been configured and the demo folder created ono the file system.
To open the Permissions view for a particular Role, first open the Manage Accounts view, switch to Masters 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, specify the folder Path either by:
- entering the Path relative to the JobScheduler Master's live Folder (e.g.
/demo
or/demo
/*) or - clicking on the folder icon to open a tree view of the live Folder and selecting the Folder as shown in the screenshot below:
Note that the JobScheduler will have to be restarted if the Folder for the Permissions has been added with a File manager - and not JOE - before the folder will show in the tree view.
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 demo_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:joc_cockpit:jobscheduler_master:view:status
Roles with Folder Permissions are often configured for Users in combination with default Roles. For example, if the demo_user described here was allocated the it_operator Role in addition to the demo_role, they would be able to carry out the tasks allowed by the default IT Operator Permissions but only for JobScheduler Objects in the demo folder and, if configured, its child Folders. See the Use Case below for an example configuration.
Use Cases
Mandator-Specific User Accounts
Consider the case where an Application Manager works for a mandator (client), in an environment where a JobScheduler Master is used for two mandators, A & B.
- Each mandator's JobScheduler objects (Jobs, Orders, Schedules, etc.) are stored in a sub-folder of the JobScheduler Master's
live
folder. - Mandator A's Application Manager has the standard permissions allocated for this Role but can only see their mandator's Jobs, Orders, Schedules and log files.
File Structure
The JobScheduler Master live
folder will have the following structure:
live
mandator_a
mandator_b
sos
(housekeeping jobs, etc)
User Accounts, Roles and Permissions
A User Account for mandator A's Application Manager (mandator_a_am_user) will be configured, in addition to the default User Accounts provided with the JOC Cockpit (root, administrator, application_manager, incident_manager, etc.). The mandator A Application Manager account will be allocated two roles - the default application_manager Role and a specially created mandator_a_role. The mandator_a_role will then be restricted to accessing only the mandator_a
folder.
Configuration Steps
See the sections above for more detailed instructions about configuring Account Roles, etc..
- Create the mandator_a_role in the Masters section of the Manage Accounts view.
Once created the new role will be added to the Roles list which can be seen in the background of the screenshot above. - The mandator_a_am_user account is now created in the Accounts section and the application_manager and mandator_a_role Roles specified.
- The mandator A Folder access restriction is now added for the mandator_a_role in the Master section.
When a user now logs in with the credentials for the mandator_a_am_user account they will only be able to access JobScheduler objects in the mandator_a folder as well as log and audit log information relevant to these objects. This can be seen in the following screenshot showing the Job Chains view:
Note that the mandator_a_role Role can be "reused" to restrict the access of other mandator-specific User Accounts that may be required to meet the full service requirement of Mandator A.
Note also that a download archive containing the relevant files to implement both use cases described in this article is available in the last section of this article.
Modifying User Account Permissions for a Specific Mandator
Consider the case where a Business User account is to be configured for a mandator B where the account user can start and monitor their own Jobs and Orders.
- The user should only see their own JobScheduler objects.
- This is configured by setting Folder Permissions for a mandator-specific Role as described in the previous use case.
- The user should be able to see general status information (Master and Agent Cluster status) but not take any action:
- This is part of the default business_user Permission set and is configured by allocating the default business_user Role to the User Account - again, as described in the previous use case.
- The user should be able to start and stop their own Jobs and Orders and set Run-times.
These operations require additional Permissions that are not provided as part of the default business_user Permission set, which is shown in the following listing:
The Default business_user Permissions Setsos:products:joc_cockpit:jobscheduler_master:view:status sos:products:joc_cockpit:jobscheduler_master_cluster:view:status sos:products:joc_cockpit:jobscheduler_universal_agent:view:status sos:products:joc_cockpit:daily_plan:view:status sos:products:joc_cockpit:history:view sos:products:joc_cockpit:order:view:status sos:products:joc_cockpit:order:view:order_log sos:products:joc_cockpit:job_chain:view:status sos:products:joc_cockpit:job_chain:view:history sos:products:joc_cockpit:job:view:status sos:products:joc_cockpit:job:view:history sos:products:joc_cockpit:job:view:task_log sos:products:joc_cockpit:process_class:view:status sos:products:joc_cockpit:schedule:view:status sos:products:joc_cockpit:lock:view:status sos:products:joc_cockpit:holiday_calendar:view:status sos:products:joc_cockpit:maintenance_window:view:status sos:products:joc_cockpit:audit_log:view:status sos:products:joc_cockpit:customization:share:view
Configuration Steps
The following configuration steps are carried out in the same manner as described in the previous example:
- A mandator_b Folder is added to the JobScheduler Master's
live
Folder. - A User Account mandator_b_bu_user and Role mandator_b_role are added.
- The mandator_b_role Role is restricted to being only to able to access objects in the mandator_b Folder and its Sub-folders.
These steps mean that the Mandator B Business User will be able to carry out the operations allowed by the default business_user Permissions Set and will only be able to see their own JobScheduler objects.
Note that if the additional Permissions for Business User are added to the mandator_b_role and this Role could be used later to to restrict other User Accounts to only accessing the mandator_b Folder then these User Accounts would be automatically be allocated the additional Permissions. As this may not be desirable, a more structured approach would be to create a third Role for the Business User (mandator_b_bu_role) specifically for these additional Permissions.
The additional Permissions required for the mandator_b_bu_role are added in the Permissions section of the Managing Accounts view.
The following individual Permissions could be used to start Orders and Jobs and the other operations specified:
- Orders
sos:products:joc_cockpit:order:view
sos:products:joc_cockpit:order:change
-sos:products:joc_cockpit:order:change:hot_folder
sos:products:joc_cockpit:order:execute
- Job Chains
sos:products:joc_cockpit:job_chain:
view
sos:products:joc_cockpit:job_chain:execute:stop
sos:products:joc_cockpit:job_chain:execute:unstop
sos:products:joc_cockpit:job_chain:execute:add_order
- Jobs
sos:products:joc_cockpit:job:
view
sos:products:joc_cockpit:job:
change:run_time
sos:products:joc_cockpit:job:execute:start
sos:products:joc_cockpit:job:execute:stop
sos:products:joc_cockpit:job:
execute:unstop
Alternatively, a more liberal approach could be taken and, for example, copy the Permissions that are granted by default to the IT Operator Role:
sos:products:joc_cockpit:order
sos:products:joc_cockpit:jobchain
sos:products:joc_cockpit:job
Example Files
Download the Example
Configuration foles to create working examples of the above use cases can be downloaded from this link:
Install the Example
When the archive is unpacked three elements will shown:
- two folders:
mandator_a
andmandator_b
and
- a
shiro.ini
configuration file.
Copy the two folders with all their contents to your JobScheduler's live
folder. It is not necessary to delete any of the existing folders.
Make a backup of the current shiro.ini
file in the /joc/resources/joc folder
and then overwrite the current shiro.ini
file from the version from the download archive. See the Installation Instructions for the JobScheduler and JOC Cockpit for information about the default locations of these folders.
Restart the Jetty server to implement the changes in the shiro.ini
configuration.
Example Description
Each of the mandator folders contains a hello_world
sub-folder with job chains and orders that are scheduled to run once an hour.
The shiro.ini
file contains a configuration based on the shiro.ini
file delivered with the JOC Cockpit installation with the following default roles active:
User | Password | Role |
---|---|---|
root | root | all |
administrator | secret | administrator |
api_user | secret | api_user |
application_manager | secret | application_manager |
business_user | secret | business_user |
incident_manager | secret | incident_manager |
it_operator | secret | it_operator |
In addition the following mandator-specific Users have been configured:
User | Password | Roles | Folder | Permissions |
---|---|---|---|---|
mandator_a_am_user | secret | mandator_a_role | mandator_a | - |
application_manager | - | default | ||
mandator_b_bu_user | secret | mandator_b_role | mandator_b | - |
mandator_b_bu_role | - | see text | ||
business_user | - | default |