...
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
livefolder. - 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:
livemandator_amandator_bsos(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
- 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 Role can be "reused" to restrict the access of other 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_aandmandator_band
- a
shiro.iniconfiguration 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 |
| Show If | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||
Use CasesMulti-Mandator SchedulingA 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 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 FilesDownload the ExampleA working example of the above use case can be downloaded from this link: Install the ExampleWhen the archive is unpacked three elements will shown:
Copy the two folders with all their contents to your JobScheduler's Make a backup of the current Restart the Jetty server to implement the changes in the Example DescriptionEach of the mandator folders contains a The
In addition the following mandator-specific Users and Roles have been configured:
Holders of the three mandator_a_* user accounts are only able to access the Jobs, Orders, Schedules, etc in the relevant 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.
|