...
- 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:
- The editing function A selected permission can also be used to make a selected permission made subtractive - i.e. to remove a specific part of a higher level Permission.
- This is done by directly prefixing the Permission with a minus symbol - i.e. without a space between the minus and the Permissionticking 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:
- ...
Show If | ||
---|---|---|
| ||
JobScheduler-Specific PermissionsBy default user accounts User Accounts are granted Permissions for all the JobScheduler Masters and JobScheduler Master Clusters in an 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 a scheduling 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. It is therefore ... < VERIFY |
Anchor | ||||
---|---|---|---|---|
|
...
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.
Example Files
Download the Example
A working example of the above use case 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 | Role | Password |
---|---|---|
root | all | root |
administrator | administrator | secret |
api_user | api_user | secret |
application_manager | application_manager | secret |
business_user | business_user | secret |
incident_manager | incident_manager | secret |
it_operator | it_operator | secret |
In addition the following mandator-specific User and Role has been configured:
User | Roles | Password |
---|---|---|
mandator_a_am_user | mandator_a application_manager | secret |
...
user | aa |
---|
Use Cases
Multi-Mandator Scheduling
A JobScheduler Master can be used to provide job scheduling services for a number of mandators / clients and ensure that Users such as operators or support staff associated with one mandator do not have access to scheduling activities or configuration information for another mandator. This is achieved by configuring a combination of Roles and Folder Permissions.
Consider a JobScheduler Master carrying out scheduler activities for two clients mandator A and mandator B:
- The JobScheduler's
live
Folder is structured as follows:live
mandator_a_folder
(for all Jobs, Orders, etc. for this client)mandator_b_folder
(for all Jobs, Orders, etc. for this client)sos
(the default folder for Housekeeping and other Jobs, Orders, etc.)
- Incident management for each mandator is carried out by separate User with the default incident_manager Role and a Role with Folder Permissions restricting them to the respective mandator Folder- i.e.
mandator_a_im_user
(Incident Manager User for mandator A)- incident_manager (common default Role)
- mandator_a_role (mandator-specific Role)
mandator_a_folder
(Folder Permission)
mandator_b_im_user
(Incident Manager User for mandator B)- incident_manager (common default Role)
- mandator_b_role (mandator-specific Role)
mandator_b_folder
(Folder Permission)
The above configuration means that the incident manager Users for mandator A and mandator B will only be able to see the Jobs, Orders, log files, and other possibly confidential information for their respective mandator.
See the Folders Section (above) for instructions about configuring Folder Permissions.
Example Files
Download the Example
A working example of the above use case can be downloaded from this link:
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:
Code Block language text title The Default business_user Permissions Set sos: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
Anchor | ||||
---|---|---|---|---|
|
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
...
- and
mandator_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 location 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 |
In addition the following mandator-specific Users and Roles have been configured:
...
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 |
it_operator
...
...
mandator |
...
_b | - | |||
mandator_b_bu_role | - | see text | ||
business_user | - | default |
...
Note that the user accounts with the it_operator Role are the only ones configured in this example that have the necessary Permissions to start Orders.
...