Table of Contents |
---|
Introduction
Excerpt |
---|
Three methods of user authentication - Shiro, LDAP and Database - |
...
along with user authorization can be implemented for the JobScheduler JOC Cockpit. A general description of the authentication and authorization is presented in the JOC Cockpit - Authentication and Authorization article. This article describes the configuration required to implement each of |
...
these three authentication methods as well as user authorization |
...
. In the 1.11.x Releases and in Release 1.12.0 this configuration information is held in an Apache ShiroTM .ini file and is used |
...
by both the JOC Cockpit |
...
GUI and the JobScheduler Web Services API. |
Configuration File Structure
The Default Configuration
Shiro Authentication
The shiro.ini
file is delivered with an default configuration for Shiro authentication. This configuration includes a number of user profiles - one of which (root:root) is active and has all permissions. This profile allows a system administrator to log onto the JOC Cockpit GUI and access all of its features after installation. After installation a system administrator can use a text editor to modify the shiro.ini
file in order to implement other user profiles, change passwords and, if required, deactivate the root profile.
The location of the shiro.ini
file after installation of the JOC Cockpit is described below.
LDAP and Database Authentication
An example configuration for LDAP and Database authentication is not included with the JOC Cockpit. However, example configurations are presented later in this article to provide system administrators with sufficient information to implement these types of authentication themselves.
Authorization
Default authorization profiles are provided in the shiro.ini
file. System administrators are free to edit these profiles as required.
File Location
The location of the shiro.ini
file is dependent on whether or not the Jetty web server included with the JOC Cockpit installation archive is installed with the JOC Cockpit.
Location when Jetty is Installed with the JOC Cockpit
If the Jetty provided as part of the JOC Cockpit distribution is installed with the JOC Cockpit then the shiro.ini
file can be found in the resources
sub-folder in the jetty_base
directory where the jetty_base
directory is specified during the installation process of the JOC Cockpit. See the JOC Cockpit - Installation article for more information.
- On Windows systems the default location for the
resources
directory will be:C:\ProgramData\sos-berlin.com\joc\resources\joc
- On Unix systems the default location will be:
/home/[user]/sos-berlin.com/joc/
resources
/joc
Location when Jetty is not Installed with the JOC Cockpit
If the Jetty provided as part of the JOC Cockpit distribution is not installed with the JOC Cockpit then the location of the shiro.ini
file and resources
directory will depend on previous installation history. See the Configuration with Alternative Web Servers section of the JOC Cockpit - Installation article for more information.
In this situation the shiro.ini
file and other resources can be moved by the system administrator to an appropriate directory in the web server to be used.
JOC Cockpit Updates
A first installation of the JOC Cockpit will write a single instance of the shiro.ini
file to the resources/joc
folder. As the shiro.ini
file is intended to be modified by system administrators, an update or a full installation of the JOC Cockpit that finds an existing shiro.ini
file will not overwrite this file but create a shiro.ini-example
file alongside the .ini
file. This new file will contain the current example configuration and give system administrators a reference configuration containing any configuration updates.
The Internal File Structure
The shiro.ini
file will have between two and four sections, depending on the authentication method specified and whether or not folder permissions are specified. These sections are:
- [users]
- Contains authentication information when Shiro authentication is used.
- Contains the roles assigned to users after authentication when Shiro authentication is used.
- Is not required for other authentication methods.
- [main]
- If LDAP authentication is to be used:
- contains configuration information for accessing the LDAP directory service;
- contains a mapping of LDAP groups onto JOC Cockpit authorization roles.
- If Database authentication is to be used:
- contains configuration information for accessing the database via Hibernate.
- Contains session timeout information for the JOC Cockpit.
- Is required for all authentication methods.
- If LDAP authentication is to be used:
- [roles]
- Contains the JOC Cockpit authorization information - i.e. the permissions assigned to roles.
- Is required for Shiro and LDAP authentication methods.
- [folders]
- Optional for all authentication methods.
- Defines the set of folders that are available for a role.
The order in which these sections are positioned in the shiro.ini
file is not important.
[users] Configuration
This section contains the authentication information when Shiro authentication is used. It is only required when the Shiro authentication is used.
User information for seven example users is delivered with the JOC Cockpit as shown in the listing below, with a role and password being mapped onto each user name. These roles are described in more detail in the Matrix of Roles and Permissions section of the JOC Cockpit - Authentication and Authorization article. The roles are then mapped onto permissions in the [roles] section of this file (described below).
The default user information for Shiro authentication is shown in the listing below:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[users]
#administrator=secret, administrator
#application_manager=secret, application_manager
#it_operator=secret, it_operator
#incident_manager=secret, incident_manager
#business_user=secret, business_user
#api_user=secret, api_user
root=root, all |
- "As delivered" only one user/role mapping is active - root, with a default password as shown in the listing above. The other user configurations are commented out. System administrators can add and modify these configurations as required.
- It should be clear that the default passwords should replaced either before user profiles are activated or as soon as possible afterwards.
- In this default configuration user names and role names are identical. This is not necessary.
- Passwords are stored in open text. Password encryption is not available with Shiro authentication.
- Note that the api_user is not intended for use with the JOC Cockpit but instead for use by other applications accessing the JobScheduler Web Services.
Syntax
user=password, role1, role2
- Where:
- user is the user name.
- password is saved in open text .
- role entries must be identical to roles specified in the [roles] section of the file. Any number of roles can be assigned to a user. Multiple roles are separated by commas.
- Each entry is specified on a new line, password and role are separated by a comma.
Role Name Restrictions:
- The JOC Cockpit will only show the names of a limited set of roles. These are:
- the roles defined in the default configuration and listed above - i.e.
administrator,
application_manager,
it_operator,
incident_manager,
business_user,
api_user,
root
- a number of additional role names:
events,
joc,
joe,
jid,
workingplan,
controller,
jobeditor,
joc_admin,
admin,
super
- the roles defined in the default configuration and listed above - i.e.
- The JOC Cockpit will only show the names of a limited set of roles. These are:
[roles] Configuration
This section contains the mapping of roles onto permissions. This section is required when either Shiro or LDAP authentication is used.
An default mapping of seven roles is delivered with the JOC Cockpit installation. The roles in this mapping correspond with the seven roles specified in the [users] section of the file. System administrators can add additional and modify role configurations as required. The default mapping is shown in the listing below:
In Releases 1.12.1 and newer this configuration information is held in the Reporting Database and Shiro .ini files are used for importing and inspecting the configuration. |
Scope
This article describes the configuration of user authentication and authorization by directly editing the shiro.ini
file and is therefore directly applicable to the 1.11.x Releases and Release 1.12.0. This method of configuration can be used with all three methods of user authentication and authorization - Shiro, LDAP and Database - for these releases.
The JOC Cockpit also provides a configuration editor for authentication and user authorization, which is described in the Authentication and Authorization - Managing User Accounts article. For the 1.11.x Releases and Release 1.12.0 the functions of this editor do not cover all aspects of authentication and authorization and direct configuration of the shiro.ini
file is required when LDAP and Database authentication and authorization are used. LDAP configuration is described in the LDAP Configuration article.
With Releases 1.12.1 onward, the configuration editor can be used for all aspects of authentication and authorization. In addition, the Reporting database is used for the storage of authentication instead of the shiro.ini
file and the shiro.ini
file is given a new function as a configuration import medium. However, the organization of the authentication and authorization configuration remains the same and the contents of this article provide a detailed insight into the Shiro configuration.
Note that with Releases 1.12.1 onward the JOC cockpit automatically exports the authentication and authorization information from the Reporting database to a shiro.ini.active
file. This file is organized identically to the shiro.ini
file and is intended to provide a convenient overview of the configuration. It can also function as a backup source in the event of a loss of the database.
Updating to Release 1.12.1 and newer
Migration of an existing configuration from a shiro.ini
file to the Reporting database takes place automatically as part of the update procedure. After migration the shiro.ini
file is deleted and the new shiro.ini.active
file generated.
Revert shiro.ini to default values
Download the file shiro.ini-example, rename the file to shiro.ini then login to JOC Cockpit (no restart required).
Using the example shiro.ini file activates password hashing an allows access with the user account: root
and password: root
.
Configuration File Structure
The Default Configuration
Shiro Authentication
The shiro.ini
file is delivered with a default configuration for Shiro authentication. This configuration includes a user profile (root:root), which is active and has a role all with all permissions. This profile allows a system administrator to log onto the JOC Cockpit and access all of its features after installation. Once the root User has created an administrative user account with the necessary permissions, this account can be used to implement other user profiles, set and change passwords and, if required, deactivate the root profile.
The location of the shiro.ini
file after installation of the JOC Cockpit is described below.
LDAP and Database Authentication
Example configurations for LDAP and Database authentication are not included with the JOC Cockpit. However, example configurations are presented later in this article (see Database Authentication) and in the separate LDAP Configuration Article. These configurations are intended to provide system administrators with sufficient information to implement these types of authentication themselves.
Example User Profiles
An example set of six example user profiles is included in the shiro.ini
file, in addition to the root user profile. These profiles are intended to allow users to explore the functioning of the authentication and authorization and to provided a base for administrators wishing to developing their own configuration. These profiles are deactivated by default and not shown in the JOC Cockpit Manage Accounts view unless they are activated .They are commented out but can be easily activated by a system administrator that has permission to modify the shiro.ini
file.
Anchor | ||||
---|---|---|---|---|
|
The shiro.ini
File Location
The location of the shiro.ini
file is dependent on whether or not the Jetty web server included with the JOC Cockpit installation archive is installed with the JOC Cockpit.
Location of the shiro.ini
file when Jetty is Installed with the JOC Cockpit
If the Jetty provided as part of the JOC Cockpit distribution is installed with the JOC Cockpit then the shiro.ini
file can be found in the resources
sub-folder in the jetty_base
directory where the jetty_base
directory is specified during the installation process of the JOC Cockpit. See the JOC Cockpit - Installation article for more information.
- On Windows systems the default location for the
resources
directory will be:C:\ProgramData\sos-berlin.com\joc\resources\joc
- On Unix systems the default location will be:
/home/[user]/sos-berlin.com/joc/
resources
/joc
Location of the shiro.ini
file when Jetty is not Installed with the JOC Cockpit
If the Jetty provided as part of the JOC Cockpit distribution is not installed with the JOC Cockpit then the location of the shiro.ini
file and resources
directory will depend on previous installation history. See the Configuration with Alternative Web Servers section of the JOC Cockpit - Installation article for more information.
In this situation the shiro.ini
file and other resources can be moved by the system administrator to an appropriate directory in the web server to be used.
shiro.ini
File Syntax Restrictions
Upper case letters and special characters should not be used, blank spaces within names should be avoided.
JOC Cockpit Updates
A first installation of the JOC Cockpit will write a single instance of the shiro.ini
file to the resources/joc
folder. As the shiro.ini
file is intended to be modified by system administrators, an update or a full installation of the JOC Cockpit that finds an existing shiro.ini
file will not overwrite this file but create a shiro.ini-example
file alongside the .ini
file. This new file will contain the current example configuration and give system administrators a reference configuration containing any configuration updates.
The Internal shiro.ini
File Structure
The shiro.ini
file will have between two and four sections, depending on the authentication method specified and whether or not folder permissions are specified. These sections are:
- [users]
- Contains authentication information, including passwords, when Shiro authentication is used.
- Contains the roles assigned to users after authentication when Shiro authentication is used.
- Is not required for other authentication methods.
- [main]
- If LDAP authentication is to be used:
- contains configuration information for accessing the LDAP directory service;
- contains a mapping of LDAP groups onto JOC Cockpit authorization roles.
- If Database authentication is to be used:
- contains configuration information for accessing the database via Hibernate.
- Contains session timeout information for the JOC Cockpit.
- Is required for all authentication methods.
- If LDAP authentication is to be used:
- [roles]
- Contains the JOC Cockpit authorization information - i.e. the permissions assigned to roles.
- Is required for Shiro and LDAP authentication methods.
- [folders]
- Defines the set of folders that are available for a role.
- Is optional for all authentication methods.
- Folders are specified relative to the root of the JobScheduler's
live
folder.
Note that:
- The default configuration does not include the [folders] section - this is only required when folder Permissions are configured and will be either dynamically added by the Add Folder function in the Manage Accounts view or should be manually added if the
shiro.ini
file is being directly configured. - The order in which these sections are positioned in the
shiro.ini
file is not important.
Anchor | ||||
---|---|---|---|---|
|
This section contains the authentication information when Shiro and LDAP authentication is used. It is not required when Database authentication is used.
User information for seven example Shiro authentication accounts is delivered with the JOC Cockpit as shown in the first two listings below, The configuration of each User Account is made up of a role and a password which is mapped onto each user account name.
- Passwords are written in plain text in releases 1.11.0 to 1.11.4. Passwords are hashed by default with release 1.11.5 and newer.
- The configuration of password hashing and how to add password hashing to releases 1.11.0 to 1.11.4 is described in the [main] section below.
- The function of individual Roles is described in more detail in the Matrix of Roles and Permissions section of the JOC Cockpit - Authentication and Authorization article. The roles are then mapped onto permissions in the [roles] section of this file (described below).
- "As delivered" only one user/role mapping is active - root, with a default password as shown in the listing above. The other user configurations are commented out. System administrators can add and modify these configurations as required.
- It should be clear that the default passwords should replaced either before user profiles are activated or as soon as possible afterwards.
- In this default configuration user names and role names are identical. This is not necessary.
- Note that the api_user is not intended for use with the JOC Cockpit but instead for use by other applications accessing the JobScheduler Web Services.
The default user account information for Shiro authentication for releases 1.11.0 to 1.11.4 with plain text passwords is shown in the listing below:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[users]
#administrator=secret, administrator
#application_manager=secret, application_manager
#it_operator=secret, it_operator
#incident_manager=secret, incident_manager
#business_user=secret, business_user
#api_user=secret, api_user
root=root, all |
The default user account information for Shiro authentication for releases 1.11.5 and newer with hashed passwords is shown in the listing below:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[users]
root = $shiro1$SHA-512$500000$W0oNBkZY9LRrRIGyc4z2Ug==$NcoU+ZFM9vsM0MeHJ3P5NJ0NdvJrK38qVnl7v7YG7p9o5ZJfMccugJsA9myJsTNx2BF5rbvA696UhTGdUtSnOg==,all
# administrator = $shiro1$SHA-512$500000$BZASvbCtiECiM9kwjqI1ow==$IKfbskqi5VGUm/Ysr0BFS8fMYQQcV78GIDcbV2N1T9Q1os99oVXWd7RZWzWbnqY3OZAjd4EFtbwhTVvxZS++aw==,administrator
# api_user = $shiro1$SHA-512$500000$ZACYLMkDOsIO0aEtznZyig==$md8wSi3b+VTwepBM9fcLoAW6OLfwRpYvlkgm/bHCs7tIri331L4taf1AK3wGYUBreFkNM8vFgWDLdidlppLB4w==,api_user
# application_manager = $shiro1$SHA-512$500000$JELbPBXwYbItkAEkW1bI+A==$JFDIkrjyA/kRrg9cJSESokisYX25HH5fJCW/MAXOAoPHYY0kFJZRrDtRlMA2MwzcofMMIgIwy+SEHF6nQXTZMA==,application_manager
# business_user = $shiro1$SHA-512$500000$75St1KFDgHLxonvHF3X2kQ==$59fl1CMUUyS3qRHbfgLCAeS/nLQqxsXB3jiKT29WIr0q9wmdGC+Vgqs20X3QqKJew1vvJRI/2RnvEqYF6pnpsw==,business_user
# incident_manager = $shiro1$SHA-512$500000$/DVMuadHBMqkAWiSIhyXrA==$brIx90gKCzvz6BTW+nSeBeewZUDCG26RElTAegYWYhmJwCRAAZM4q0PMk5Y+k/wLT7TTKqm6PGJWNzBbrlAObA==,incident_manager
# it_operator = $shiro1$SHA-512$500000$PqETLFA6uhYwtx/1+wLJzg==$PRe/axzjoeCbt/a68wxoHL1e/YrkY+KKTdn5LxJYjIlaUtDtdRpssGTz6z/vxAK+wyo9IT1aZpuwvBVGLQreNA==,it_operator |
- Note that the password hashes provided only work with the default password hashing configuration. This configuration is described in more detail in the [main] section below
Syntax
user=password, role1, role2
- Where:
- user is the user account name.
- Names of accounts used with shiro authentication may not include blank spaces.
- password is either saved in open text, which was the default for releases 1.11.0 to 1.11.4, or as a hash, which is the default for 1.11.5 onward.
- role entries must be identical to roles specified in the [roles] section of the file. Any number of roles can be assigned to a user. Multiple roles are separated by commas.
- Each entry is specified on a new line, password and role are separated by a comma.
- user is the user account name.
Syntax for LDAP Authentication
The syntax for LDAP authentication is described in the LDAP Configuration article.
Role Name Restrictions:
- Role names may not contain a blank space.
Anchor | ||||
---|---|---|---|---|
|
This section contains the authorization information i.e. the mapping of roles onto permissions. This section is required when either Shiro or LDAP authentication is used.
An default mapping of seven roles is delivered with the JOC Cockpit installation. The roles in this mapping correspond with the seven roles specified in the [users] section of the file. System administrators can add additional and modify role configurations as required. The default mapping is shown in the listing below:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[roles]
# Permissions are assigned to roles with a comma separated list of permissions. Permissions may have * as a wildcard.
all | ||||||||
Code Block | ||||||||
| ||||||||
[roles] # Permissions are assigned to roles with a comma separated list of permissions. Permissions may have * as a wildcard. all = sos:products administrator = sos:products:joc_cockpit:jobscheduler_master:view, \ sos:products:joc_cockpit:jobscheduler_master:execute:pause, \ sos:products:joc_cockpit:jobscheduler_master:execute:continue, \ sos:products:joc_cockpit:jobscheduler_master:execute:restart, \ sos:products:joc_cockpit:jobscheduler_master:execute:terminate, \ sos:products:joc_cockpit:jobscheduler_master:execute:abort, \ sos:products:joc_cockpit:jobscheduler_master:administration:edit_permissions, \ sos:products:joc_cockpit:jobscheduler_master:administration:remove_old_instances, \ sos:products:joc_cockpit:jobscheduler_master_cluster, \ sos:products:joc_cockpit:jobscheduler_universal_agent application_manager = sos:products:joc_cockpit:jobscheduler_master:view, \ sos:products:joc_cockpit:jobscheduler_master:execute:pause, \ sos:products:joc_cockpit:jobscheduler_master:execute:continue, \ sos:products:joc_cockpit:jobscheduler_master:administration:manage_categories, \ 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, \ = sos:products administrator = sos:products:joc_cockpit:jobjobscheduler_chainmaster:view, \ sos:products:joc_cockpit:jobjobscheduler_master:execute:pause, \ sos:products:joc_cockpit:process_classjobscheduler_master:execute:continue, \ sos:products:joc_cockpit:schedulejobscheduler_master:execute:restart, \ sos:products:joc_cockpit:lockjobscheduler_master:execute:terminate, \ sos:products:joc_cockpit:eventjobscheduler_master:execute:abort, \ sos:products:joc_cockpit:event_action:jobscheduler_master:administration:edit_permissions, \ sos:products:joc_cockpit:holidayjobscheduler_calendarmaster:view:statusadministration:remove_old_instances, \ sos:products:joc_cockpit:maintenance_window:viewjobscheduler_master_cluster, \ sos:products:joc_cockpit:maintenance_window:enable_disable_maintenance_windowjobscheduler_universal_agent application_manager = sos:products:joc_cockpit:jobscheduler_master:view, \ sos:products:joc_cockpit:auditjobscheduler_logmaster:viewexecute:statuspause, \ sos:products:joc_cockpit:jobscheduler_master:customization:share it_operatorexecute:continue, \ = sos:products:joc_cockpit:jobscheduler_master:administration:viewmanage_categories, \ 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, \ sos:products:joc_cockpit:job_chain, \ sos:products:joc_cockpit:job, \ sos:products:joc_cockpit:process_class, \ sos:products:joc_cockpit:schedule, \ sos:products:joc_cockpit:lock, \ sos:products:joc_cockpit:event, \ sos:products:joc_cockpit:event_action, \ sos:products:joc_cockpit:holiday_calendar:view:status, \ sos:products:joc_cockpit:maintenance_window:view, \ sos:products:joc_cockpit:auditmaintenance_log:view:statuswindow:enable_disable_maintenance_window, \ sos:products:joc_cockpit:customizationaudit_log:share:view incident_managerview:status, \ = sos:products:joc_cockpit:jobscheduler_master:view, \ sos:products:joc_cockpit:customization:share it_operator = sos:products:joc_cockpit:jobscheduler_master_cluster:view:status, \ sos:products:joc_cockpit:jobscheduler_universalmaster_agentcluster:view:status, \ sos:products:joc_cockpit:dailyjobscheduler_universal_planagent:view:status, \ sos:products:joc_cockpit:historydaily_plan:view:status, \ sos:products:joc_cockpit:orderhistory:view, \ sos:products:joc_cockpit:order:remove_setback, \ sos:products:joc_cockpit:job_chain:view, \ sos:products:joc_cockpit:job:view, \ sos:products:joc_cockpit:process_class:view, \ sos:products:joc_cockpit:schedule:view, \ sos:products:joc_cockpit:lock:view, \ sos:products:joc_cockpit:event:view, \ sos:products:joc_cockpit:event_action:view, \ sos:products:joc_cockpit:holiday_calendar:view:status, \ sos:products:joc_cockpit:maintenance_window:view, \ sos:products:joc_cockpit:audit_log:view:status, \ sos:products:joc_cockpit:customization:share:view business_user incident_manager = 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:orderremove_logsetback, \ sos:products:joc_cockpit:job_chain:view:status, \ sos:products:joc_cockpit:job_chain:view:history, \ sos:products:joc_cockpit:jobprocess_class:view:status, \ sos:products:joc_cockpit:jobschedule:view:history, \ sos:products:joc_cockpit:joblock:view:task_log, \ sos:products:joc_cockpit:process_classevent:view:status, \ sos:products:joc_cockpit:scheduleevent_action:view:status, \ sos:products:joc_cockpit:lockholiday_calendar:view:status, \ sos:products:joc_cockpit:holidaymaintenance_calendarwindow:view:status, \ sos:products:joc_cockpit:maintenanceaudit_windowlog:view:status, \ sos:products:joc_cockpit:audit_log:customization:share:view business_user = sos:products:joc_cockpit:jobscheduler_master:view:status, \ sos:products:joc_cockpit:customization:share:viewjobscheduler_master_cluster:view:status, \ api_user = sos:products:commandsjoc_cockpit:jobscheduler_universal_masteragent:view:status, \ sos:products:commands:historyjoc_cockpit:daily_plan:view:status, \ sos:products:commands:orderjoc_cockpit:history:view, \ sos:products:commands:job_chainjoc_cockpit:order:view:status, \ sos:products:joc_cockpit:order:view:order_log, \ sos:products:commandsjoc_cockpit:job_chain:view:status, \ -sos:products:commandsjoc_cockpit:job_chain:view:configurationhistory, \ -sos:products:commandsjoc_cockpit:job_chain:view:configurationstatus, \ -sos:products:commandsjoc_cockpit:orderjob:view:configurationhistory, \ -sos:products:joc_cockpit:commandsjob:orderview:removetask_setbacklog, \ sos:products:commandsjoc_cockpit:process_class:view:status, \ sos:products:commandsjoc_cockpit:schedule:view:status, \ sos:products:commandsjoc_cockpit:lock:view:status, \ sos:products:commandsjoc_cockpit:holiday_calendar:view:status, \ sos:products:commandsjoc_cockpit:maintenance_window:view:status, \ sos:products:commandsjoc_cockpit:audit_log:view:status, \ sos:products:joc_cockpit:customization:share |
Note the following:
- The default mapping provided with the JOC Cockpit installation is only a subset of all the permissions that can be set. A full list of the permissions available is included in the Authentication and Authorization - Permissions for the JOC Cockpit Web Service article.
- The permissions for the api_user are not provided for the JOC Cockpit but for the JobScheduler Web Services API. For this reason the permissions structure is different and uses:
sos:products:commands:...
instead ofsos:products:joc_cockpit:...
.
Syntax
...
a minus sign ("-") can be used at the start of a permission to disallow a user access to a resource that they would otherwise be able to use (See, for example the permission set for the api_user in the listing above).
The following example shows the role demo is allowed access to all products but is not allowed to see status of JobScheduler Master Clusters or any information related to Orders in the JOC Cockpit.
...
language | text |
---|---|
title | Shiro Configuration - Permisisons Exclusion |
...
:view api_user = sos:products:commands:jobscheduler_master:view:status, \ sos:products:commands:history:view, \ sos:products:commands:order, \ sos:products:commands:job_chain, \ sos:products:commands:job, \ -sos:products:commands:job:view:configuration, \ |
...
-sos:products:commands:job_chain:view:configuration, \ -sos:products: |
...
commands:order:view: |
...
configuration, \ -sos:products: |
...
Granting and denying of permissions is carried out according to the union principle from set theory - all permissions granted are brought together and then all permissions denied are removed.
...
The api_manager role allows the demo_user to carry out all job-related operations in the JOC Cockpit with the exception of viewing the job configuration. For convenience, these permissions are shown in the code block below.
The incident_manager role allows the demo_user to view all job-related operations.
...
language | text |
---|---|
title | Shiro Configuration - Multiple Roles |
...
commands:order:remove_setback, \ sos:products:commands:process_class:view:status, \ |
...
sos:products:commands:schedule:view:status, \ sos:products |
...
:commands:lock:view:status, \ |
...
sos:products: |
...
commands:holiday_calendar:view: |
...
status, \ |
...
- What cannot be changed:
- The number and type of permissions is fixed.
- What can be changed:
- The number of roles can be changed.
- The permission value yes / no can be changed for each permission in each role.
- Restrictions:
- The JOC Cockpit will only show the names of a limited set of roles. These are listed in the [users] Configuration section above.
sos:products:commands:maintenance_window:view:status |
Note the following:
- The default mapping provided with the JOC Cockpit installation is only a subset of all the permissions that can be set. A full list of the permissions available is included in the Authentication and Authorization - Permissions for the JOC Cockpit Web Service article.
- The permissions for the api_user are not provided for the JOC Cockpit but for the JobScheduler Web Services API. For this reason the permissions structure is different and uses:
sos:products:commands:...
instead ofsos:products:joc_cockpit:...
.
Syntax
role=permission1, \
permission2
- where:
- permissions are separated by commas (","),
- each permission is shown in the
.ini
file on a new line to ease readability, - a backward slash after each permission is the line continuation character,
- individual permissions are specified hierarchically, with each "level" being separated by a colon (":"),
- spaces (" ") are not allowed in role names,
- a wildcard ("*") can be used for all permissions,
a minus sign ("-") can be used at the start of a permission to disallow a user access to a resource that they would otherwise be able to use (See, for example the permission set for the api_user in the listing above).
The following example shows the role demo is allowed access to all products but is not allowed to see status of JobScheduler Master Clusters or any information related to Orders in the JOC Cockpit.
Multiple JobScheduler Master Instances
The default role configuration grants roles with the same permissions for all JobScheduler Masters or Master Clusters in a scheduling environment.
The ID of a JobScheduler Master or Master Cluster can be used to allow or disallow access to that Master or Master cluster.
The following example shows the JobScheduler Master with ID "scheduler_1" being granted access by all operations but for JobScheduler Master with ID "scheduler_2" only allowed limited permissions are granted and all permissions on JobScheduler Universal Agents.
- Note that the
jobscheduler_master:view
permission should never be restricted to a particular JobScheduler ID as this will prohibit all other JobScheduler Masters from being seen. See the block below for an example configuration:Code Block language text title Shiro Configuration -
...
Permisisons Exclusion demo = sos:products
...
, \
...
-sos:products:joc_cockpit:jobscheduler_master_cluster:view:status, \
...
-sos:products:joc_cockpit:
...
order
Granting and denying of permissions is carried out according to the union principle from set theory - all permissions granted are brought together and then all permissions denied are removed.
- The order in which roles and permissions are denied or removed is not important.
To illustrate this point consider the - perhaps artificial - situation where a user is given two roles: api_user and incident_manager, defined in the order shown in the code block below and each with their default permissions as listed above.The api_manager role allows the demo_user to carry out all job-related operations in the JOC Cockpit with the exception of viewing the job configuration. For convenience, these permissions are shown in the code block below.
The incident_manager role allows the demo_user to view all job-related operations.
Code Block language text title Shiro Configuration - Multiple Roles [users] demo_user=secret, api_user, incident_manager [roles] api_user = ...
...
sos:products:joc_cockpit:
...
job, \
...
-sos:products:joc_cockpit:
...
job:view:configuration, \
...
... incident_manager = ... sos:products:joc_cockpit
...
:job:view, \ ...
- Regardless of the order in which the roles of the demo_user are defined, the demo_user will be able to view job all job operations except job configuration.
- The full default matrix of permissions is shown in the Matrix of Roles and Permissions section of the JOC Cockpit - Authentication and Authorization article.
- Roles and permissions are configurable to the following extent:
- What cannot be changed:
- The number and type of permissions is fixed.
- What can be changed:
- The number of roles can be changed.
- The permission value yes / no can be changed for each permission in each role.
- Restrictions:
- The JOC Cockpit will only show the names of a limited set of roles. These are listed in the [users] Configuration section above.
- What cannot be changed:
Multiple JobScheduler Master Instances
The default role configuration grants roles with the same permissions for all JobScheduler Masters or Master Clusters in a scheduling environment.
The ID of a JobScheduler Master or Master Cluster can be used to allow or disallow access to that Master or Master cluster.
[main] Configuration
The contents of this section depend on the authentication method used.
Shiro Authentication
The only information required in the [main] section for Shiro authentication is a session timeout. The default session timeout setting is 15 minutes as shown in the listing below:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[main]
securityManager.sessionManager.globalSessionTimeout = 900000 |
Syntax
- Timeout is specified in milliseconds.
LDAP Authentication
The [users] section of the shiro.ini
file can be deleted or completely commented out when LDAP authentication is to be used.
The [main] section contains the following information:
- specification of the LDAP directory service,
- a mapping of the JOC Cockpit role names specified in the [roles] section of the file onto LDAP group names and
- a session timeout.
Example LDAP Configuration
An example for LDAP configuration is provided with the listing below:
The following example shows the JobScheduler Master with ID "scheduler_1" being granted access by all operations but for JobScheduler Master with ID "scheduler_2" only allowed limited permissions are granted and all permissions on JobScheduler Universal Agents.
Note that the
jobscheduler_master:view
permission should never be restricted to a particular JobScheduler ID as this will prohibit all other JobScheduler Masters from being seen. See the block below for an example configuration:
Code Block language text title
...
Shiro Configuration -
...
[main]
# Active Directory realm configuration
# See http://shiro.apache.org/static/current/apidocs/org/apache/shiro/realm/activedirectory/ActiveDirectoryRealm.html
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = cn={0},cn=myLDAPFolder,dc=localhost
ldapRealm.searchBase = cn=myLDAPFolder,dc=localhost
ldapRealm.contextFactory.url = ldap://localhost:389
#ldapRealm.groupNameAttribute=memberOf
#ldapRealm.userNameAttribute=cn
ldapRealm.userSearchFilter=(&(objectClass=user)(cn=%s))
# Mapping of a LDAP group to roles. You can assign more than one role with separator sign |
ldapRealm.groupRolesMap = \
"cn=JobScheduler_it_operator,cn=Roles,cn=myLDAPFolder,dc=localhost":"it_operator", \
"cn=jobscheduler_admin,cn=Roles,cn=myLDAPFolder,dc=localhost":"administrator|application_manager"
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 360000
JobScheduler IDs demo = sos:products:joc_cockpit:jobscheduler_master:view, \ scheduler_1:sos:products, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_master:pause, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_master:continue, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_master:restart, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_universal_agent
Anchor | ||||
---|---|---|---|---|
|
The contents of this section depends on the authentication method used and whether or not Password Hashing has been implemented.
Shiro Simple Authentication
The only information required in the [main] section for Shiro simple authentication is a session timeout. The default session timeout setting is 15 minutes as shown in the listing below:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[main]
securityManager.sessionManager.globalSessionTimeout = 900000 |
Syntax
- Timeout is specified in milliseconds.
Anchor | ||||
---|---|---|---|---|
|
Password Hashing
Display feature availability | ||
---|---|---|
|
Password hashing is available from release 1.11.5 onward and is activated as part of a new installation of the JOC cockpit.
Note that password hashing will not be automatically activated when updating an existing JOC Cockpit installation to version 1.11.5 or newer - see the next section for more information.
Password hashing is activated by the following lines of code in the [main]
section of the shiro.ini
file:
Code Block | ||
---|---|---|
| ||
passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
iniRealm.credentialsMatcher = $passwordMatcher |
The default activated root user account is given the hash for the password root.
User account passwords set in the Account Manager view are then automatically hashed.
Changing the default hashAlgorithm and/or the hashIterations Parameters
The two lines of code in the previous code block implement the default hashAlgorithm and hashIterations Parameters.
- The default for hashAlgorithm is SHA-512
- The default for hashIterations is the default coming from
org.apache.shiro.authc.credential.DefaultPasswordService
= 500000.
However, individual hashAlgorithm and hashIterations Parameters can be set if required.
- For this you have to define a hashService and and a passwordService:
- the hashService must be assigned to the passwordService and
- the passwordService is to be assigned to the passwordMatcher.
- The hashService is:
org.apache.shiro.crypto.hash.DefaultHashService
- The passwordService is:
org.apache.shiro.authc.credential.DefaultPasswordService
Example Configuration with Custom hashAlgorithm and hashIterations Parameters
passwordService
and hashService
can be named as required.
Code Block | ||||
---|---|---|---|---|
| ||||
[main]
securityManager.sessionManager.globalSessionTimeout = 12000000
passwordService = org.apache.shiro.authc.credential.DefaultPasswordService
hashService = org.apache.shiro.crypto.hash.DefaultHashService
hashService.hashIterations = 25
hashService.hashAlgorithmName = md5
passwordService.hashService = $hashService
passwordMatcher |
It should only be necessary for system administrators to modify three parts of this section:
- the LDAP directory service information in lines 4 to 6 of the listing,
- the mapping of LDAP groups to roles - here occupying lines 13 to 16 and which is described in the next sub-section and
- the timeout setting for sessions as shown in the last line of the listing and which is specified in milliseconds.
Example Mapping LDAP Groups to Roles:
- In line 15 of the listing above members of the JobScheduler_it_operator LDAP group are assigned the it_operator role
- More than one role can be specified for members of an LDAP group - for example:
- in line 16 members of the LDAP jobscheduler_admin group are assigned the roles of administrator and application_manager.
Example LDAP Configuration with a public LDAP Server
There are many ways of configuring LDAP authentication and authorization. The method you use depends on the structure of groups and users in your LDAP Server. You will find a working example for use with a public LDAP Server described on:
We cannot guarantee that the public LDAP Server will always be online, however, if you struggle with LDAP configuration then you might want to give it a try to have a working example.
Code Block | ||||
---|---|---|---|---|
| ||||
[users] gauss=, all [main] # Public LDAP Server for testing purposes # see http://www.forumsys.com/en/tutorials/integration-how-to/ldap/online-ldap-test-server/ # Active Directory realm configuration # See http://shiro.apache.org/static/current/apidocs/org/apache/shiro/realm/activedirectory/ActiveDirectoryRealm.html ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm ldapRealm.userDnTemplate = uid={0},dc=example,dc=com ldapRealm.searchBase = dc=example,dc=com ldapRealm.contextFactory.url = ldap://ldap.forumsys.com:389 rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter rolePermissionResolver.ini = $iniRealm ldapRealm.rolePermissionResolver = $rolePermissionResolver securityManager.realms = $ldapRealm cacheManager = org.apache.shiro.cacheauthc.MemoryConstrainedCacheManager securityManager.cacheManager = $cacheManager # Session timeout in milliseconds securityManager.sessionManager.globalSessionTimeoutcredential.PasswordMatcher passwordMatcher.passwordService = 360000 [roles] # Permissions can be assigned to roles with a comma separated list of permissions. Permissions may have * as a wildcard all = sos:products$passwordService iniRealm.credentialsMatcher = $passwordMatcher |
Possible algorithms include:
- SHA-1
- SHA-384
- SHA-256
- SHA-512
- MD5
- MD2
Deprecated Parameters
Note that the following alternative values for the passwordMatcher parameter are deprecated:
Code Block | ||
---|---|---|
| ||
org.apache.shiro.authc.credential.Sha1CredentialsMatcher
org.apache.shiro.authc.credential.Sha256CredentialsMatcher
org.apache.shiro.authc.credential.Sha384CredentialsMatcher
org.apache.shiro.authc.credential.Sha512CredentialsMatcher
org.apache.shiro.authc.credential.Md2CredentialsMatcher
org.apache.shiro.authc.credential.Md5CredentialsMatcher |
Setting a Private Salt
When using the Shiro1CryptFormat (which is the default, you can set a private salt value).
The public salt is a random value. The random value can be combined with a private salt.
Example with Private Salt Setting
The following configuration example uses a private salt with the md5 algorithm and 25 iterations.
Note that value for the private salt must be Base64 encoded. In this example the value is "sos".
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[main]
securityManager.sessionManager.globalSessionTimeout = 12000000
passwordService = org.apache.shiro.authc.credential.DefaultPasswordService
hashService = org.apache.shiro.crypto.hash.DefaultHashService
hashService.hashIterations = 25
hashService.hashAlgorithmName = md5
hashService.privateSalt = c29z
passwordService.hashService = $hashService
hashFormatFactory | ||||||||
Code Block | ||||||||
| ||||||||
[main] # Public LDAP Server for testing purposes # see http://www.forumsys.com/en/tutorials/integration-how-to/ldap/online-ldap-test-server/ # Active Directory realm configuration # See http://shiro.apache.org/static/current/apidocs/org/apache/shiro/realm/activedirectory/ActiveDirectoryRealm.html ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm ldapRealm.userDnTemplate = uid={0},dc=example,dc=com ldapRealm.searchBase = dc=example,dc=com ldapRealm.contextFactory.url = ldap://ldap.forumsys.com:389 ldapRealm.groupNameAttribute=ou ldapRealm.userNameAttribute=uid ldapRealm.userSearchFilter=(uniqueMember=uid=%s,dc=example,dc=com) # Mapping of a LDAP group to roles. You can assign more than one role with separator sign | ldapRealm.groupRolesMap = \ "scientists":"it_operator", \ "mathematicians":"administrator|application_manager" rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter rolePermissionResolver.ini = $iniRealm ldapRealm.rolePermissionResolver = $rolePermissionResolver securityManager.realms = $ldapRealm cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager securityManager.cacheManagercrypto.hash.format.DefaultHashFormatFactory passwordService.hashFormatFactory = $cacheManager$hashFormatFactory #passwordMatcher Session timeout in milliseconds securityManager.sessionManager.globalSessionTimeout = 360000 |
Assigning roles in the shiro.ini when using LDAP
It is possible to mix LDAP authentication with local authorization from a shiro.ini file.
- In the
[users]
section- specify the user name but do not specify a password for the user.
- specify the list of roles that are assigned to this user.
- Important: The assignment must start with a comma to skip the password assignment.
- In the
[main]
section- you do not have to specify the LDAP group mapping to roles.
The roles specified with the user assignment and the roles retrieved from the
ldapRealm.groupRolesMap
mapping will be added to the user.
Example LDAP Configuration for a public LDAP Server with local roles
Code Block | ||||
---|---|---|---|---|
| ||||
[users]
gauss=, application_manager, my_role
newton=, incident_manager, my_role
[main]
# Public LDAP Server for testing purposes
# see http://www.forumsys.com/en/tutorials/integration-how-to/ldap/online-ldap-test-server/
# Active Directory realm configuration
# See http://shiro.apache.org/static/current/apidocs/org/apache/shiro/realm/activedirectory/ActiveDirectoryRealm.html
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},dc=example,dc=com
ldapRealm.searchBase = dc=example,dc=com
ldapRealm.contextFactory.url = ldap://ldap.forumsys.com:389
ldapRealm.groupNameAttribute=ou
ldapRealm.userNameAttribute=uid
ldapRealm.userSearchFilter=(uniqueMember=uid=%s,dc=example,dc=com)
# Mapping of a LDAP group to roles. You can assign more than one role with separator sign |
# In this example the LDAP group mapping is commented out. The user gauss will have the roles application_manager and my_role.
# You can mix both role sources, the shiro.ini file and the LDAP group mapping.
# ldapRealm.groupRolesMap = \
# "scientists":"it_operator", \
# "mathematicians":"administrator|application_manager"
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 360000
[roles]
# Permissions can be assigned to roles with a comma separated list of permissions. Permissions may have * as a wildcard
all = sos:products
administrator = sos:products:joc_cockpit:jobscheduler_master:view, \
sos:products:joc_cockpit:jobscheduler_master:execute:pause, \
sos:products:joc_cockpit:jobscheduler_master:execute:continue, \
sos:products:joc_cockpit:jobscheduler_master:execute:restart, \
sos:products:joc_cockpit:jobscheduler_master:execute:terminate, \
sos:products:joc_cockpit:jobscheduler_master:execute:abort, \
sos:products:joc_cockpit:jobscheduler_master_cluster, \
sos:products:joc_cockpit:jobscheduler_universal_agent
application_manager = sos:products:joc_cockpit:jobscheduler_master:view, \
sos:products:joc_cockpit:jobscheduler_master:manage_categories, \
sos:products:joc_cockpit:jobscheduler_master:execute:pause, \
sos:products:joc_cockpit:jobscheduler_master:execute:continue, \
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, \
sos:products:joc_cockpit:job_chain, \
sos:products:joc_cockpit:job, \
sos:products:joc_cockpit:process_class, \
sos:products:joc_cockpit:schedule, \
sos:products:joc_cockpit:lock, \
sos:products:joc_cockpit:event, \
sos:products:joc_cockpit:event_action, \
sos:products:joc_cockpit:holiday_calendar:view:status, \
sos:products:joc_cockpit:maintenance_window:view, \
sos:products:joc_cockpit:maintenance_window:enable_disable_maintenance_window, \
sos:products:joc_cockpit:audit_log:view:status, \
sos:products:joc_cockpit:customization:share
it_operator = sos:products:joc_cockpit:jobscheduler_master:view, \
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, \
sos:products:joc_cockpit:job_chain, \
sos:products:joc_cockpit:job, \
sos:products:joc_cockpit:process_class, \
sos:products:joc_cockpit:schedule, \
sos:products:joc_cockpit:lock, \
sos:products:joc_cockpit:event, \
sos:products:joc_cockpit:event_action, \
sos:products:joc_cockpit:holiday_calendar:view:status, \
sos:products:joc_cockpit:maintenance_window:view, \
sos:products:joc_cockpit:audit_log:view:status, \
sos:products:joc_cockpit:customization:share:view
incident_manager = sos:products:joc_cockpit:jobscheduler_master:view, \
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, \
sos:products:joc_cockpit:order:remove_setback, \
sos:products:joc_cockpit:job_chain:view, \
sos:products:joc_cockpit:job:view, \
sos:products:joc_cockpit:process_class:view, \
sos:products:joc_cockpit:schedule:view, \
sos:products:joc_cockpit:lock:view, \
sos:products:joc_cockpit:event:view, \
sos:products:joc_cockpit:event_action:view, \
sos:products:joc_cockpit:holiday_calendar:view:status, \
sos:products:joc_cockpit:maintenance_window:view, \
sos:products:joc_cockpit:audit_log:view:status, \
sos:products:joc_cockpit:customization:share:view
business_user = 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:order:view:status, \
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
api_user = sos:products:commands:jobscheduler_master:view:status, \
sos:products:commands:history:view, \
sos:products:commands:order, \
sos:products:commands:job_chain, \
sos:products:commands:job, \
-sos:products:commands:job:view:configuration, \
-sos:products:commands:job_chain:view:configuration, \
-sos:products:commands:order:view:configuration, \
-sos:products:commands:order:remove_setback, \
sos:products:commands:process_class:view:status, \
sos:products:commands:schedule:view:status, \
sos:products:commands:lock:view:status, \
sos:products:commands:holiday_calendar:view:status, \
sos:products:commands:maintenance_window:view:status, \
sos:products:joc_cockpit:history:view, \
sos:products:joc_cockpit:order:view, \
sos:products:joc_cockpit:customization:share
my_role = sos:products:commands:jobscheduler_master:view:status, \
sos:products:joc_cockpit:history:view, \
sos:products:joc_cockpit:order:view:status |
Database Authentication
System administrators can implement database authentication manually, using a separate database to the JobScheduler(s) and, if required, a separate DBMS.
The JOC Cockpit configuration required to use database authentication is described in this section along with an example set of database tables. System administrators have to configure and maintain the database and tables manually as well as their query strings - there is neither a GUI available for this nor is batch support provided.
The [users] and [roles] sections of the shiro.ini
file can be deleted or completely commented out when database authentication is to be used.
The information required in the [main] section for database authentication is shown in the following listing:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[main]
hibernateRealm = com.sos.dialog.auth.SOSHibernateAuthorizingRealm
hibernateRealm.hibernateConfigurationFile=C:\Users\userName\Documents\sos-berlin.com\jobscheduler\scheduler_current\config\hibernate.cfg.oracle.xml
securityManager.realms = $hibernateRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
securityManager.sessionManager.globalSessionTimeout = 900000 |
Hibernate is used to access the database - in the example listed above an Oracle database is specified. System administrators must organize the necessary configuration information to address the database to be used to store authentication information themselves.
It should only be necessary for system administrators to modify two parts of this section of the shiro.ini
file:
- the location of the Hibernate configuration file in line 3 of the listing,
- the default timeout setting, which is in the example is 15 minutes (specified in milliseconds as shown).
Maintenance and Security Considerations
While access in order to manipulate authentication information a database requires the database password, a system administrator still has to manually enter and modify user passwords with the associated security risks and maintenance costs.
...
= org.apache.shiro.authc.credential.PasswordMatcher
passwordMatcher.passwordService = $passwordService
iniRealm.credentialsMatcher = $passwordMatcher |
Setting the Hash Format
The default hash format is org.apache.shiro.crypto.hash.format.Shiro1CryptFormat
.
However, the hash format can be changed to HEX or BASE64. Please note that in this case neither can a private salt be set nor can generatePublicSalt be set to true. The reason for this is that Shiro always adds a random public salt when a private salt is given.
Example with Hash Format Setting
The following configuration example uses Hex format, the default SHA-512 algorithm and the default value for iterations=1.
Note that the default for iterations when using the format org.apache.shiro.crypto.hash.format.Shiro1CryptFormat
is 500000.
Code Block | ||||
---|---|---|---|---|
| ||||
[main]
securityManager.sessionManager.globalSessionTimeout = 12000000
passwordService = org.apache.shiro.authc.credential.DefaultPasswordService
hashService = org.apache.shiro.crypto.hash.DefaultHashService
passwordService.hashService = $hashService
#hashFormat = org.apache.shiro.crypto.hash.format.Base64Format
#hashFormat = org.apache.shiro.crypto.hash.format.Shiro1CryptFormat
hashFormat = org.apache.shiro.crypto.hash.format.HexFormat
passwordService.hashFormat = $hashFormat
hashFormatFactory = org.apache.shiro.crypto.hash.format.DefaultHashFormatFactory
passwordService.hashFormatFactory = $hashFormatFactory
passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
passwordMatcher.passwordService = $passwordService
iniRealm.credentialsMatcher = $passwordMatcher |
Anchor | ||||
---|---|---|---|---|
|
Activating Password Hashing for Configurations with Plain Text Passwords
JOC Cockpit Installations using plain text passwords - for example, systems using releases 1.11 to 1.11.4 - can be readily modified to use password hashes after the JOC Cockpit has been updated to release 1.11.5 or newer. Note that password hashing is not automatically activated when updating to release 1.11.5 or newer of the JOC Cockpit. Activation is a separate step that can be carried out by system administrators as required.
The shiro.ini
file is a configuration file and is not updated - i.e. overwritten - during an update of the JOC Cockpit. However, the shiro.ini-example
file, which is to be found in the same folder as the shiro.ini
file, will be updated with new configuration information. Default password hashing configuration information (shown in the code block in the Activation Procedure section below) can be copied from the shiro.ini-example
file to the shiro.ini
file.
Activation Procedure
- Update the JOC Cockpit to release 1,11.5 following the procedure described in the JOC Cockpit - Installation article.
- Start the Jetty Web Server / check that the Web Service is running.
- Log into the JOC Cockpit with a user account that has edit permissions for the Manage Accounts view. (In the default configuration root and administrator accounts have the necessary permissions.)
- Go to the Manage Accounts view in the JOC Cockpit. Ensure that the Accounts tab is selected, showing the current user accounts.
Copy and uncomment the following two lines from the
[main]
section of theshiro.ini-example
file to the [main] section of theshiro.ini
file:Code Block language text passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher iniRealm.credentialsMatcher = $passwordMatcher
- Delete all user accounts from the
shiro.ini.active
file (they will not be lost from the JOC Cockpit). - Save the
shiro.ini.active
file. - Open the Edit Account modal window for any user.
- Click on Submit.
- All user accounts (Account Names, Passwords and Roles) will now be written back into the
shiro.ini
file by the JOC Cockpit and the Passwords will now be saved as hashed values. Users will be able to log in as before the update and new Passwords can be entered in plain text and will be saved as hashed values. - Save the
shiro.ini.active
file under the nameshiro.ini
- logout
- login
Activating Password Hashing in Releases 1.11.0 to 1.11.4
To use SHA512 hashed passwords in the shiro.ini
file without updating to Release 1.11.5 or newer:
- Download the CLI tool for hashing passwords from the Shiro download page
- For each user account that is saved in the
shiro.ini
file:- Use the CLI tool to generate a hashed password for the account:
- Do this using:
java -jar shiro-tools-hasher-1.3.2-cli.jar --algorithm SHA-512 -p
- Do this using:
- Save the password in the
[users]
section of theshiro.ini
file (instead of the plain text password).
- Use the CLI tool to generate a hashed password for the account:
- Add the following lines to the
[main]
section of theshiro.ini
file:Code Block language text passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher iniRealm.credentialsMatcher = $passwordMatcher
- Save the
shiro.ini
file. It is not necessary to restart the Jetty web service if modifications in the[users]
section for hashed passwords are performed. - Note that for releases 1.11.0 to 1.11.4 the JOC Account Management does not support hashed passwords and will overwrite a hashed password with any new plain text password if you change a password. As a consequence you can not use the JOC Account Management to change passwords after hashed passwords have started to be used.
Anchor | ||||
---|---|---|---|---|
|
LDAP Authentication
The configuration of the shiro.ini
file for use with LDAP Authentication is described in the LDAP Configuration article.
Anchor | ||||
---|---|---|---|---|
|
Clustering
Multiple instances of the JOC Cockpit can be configured to operate as an active cluster. This requires a load balancer and session sharing between the JOC Cockpit instances. See the JOC Cockpit - Clustering article for more information.
Anchor | ||||
---|---|---|---|---|
|
Database Authentication
System administrators can implement database authentication manually, using the tables stored in the reporting database.
The JOC Cockpit configuration required to use database authentication is described in this section along with an example set of database tables. System administrators have to configure and maintain the database and tables manually as well as their query strings - there is neither a GUI available for this nor is batch support provided. The user management in the JOC Cockpit can not be used, when users and roles are stored in the database.
The [users] and [roles] sections of the shiro.ini
file can be deleted or completely commented out when database authentication is to be used. Please note that until 1.13.4 there must be empty sections for users and roles.
The information required in the [main] section for database authentication is shown in the following listing:
Hibernate is used to access the database - in the example listed above an Oracle database is specified. System administrators must organize the necessary configuration information to address the database to be used to store authentication information themselves.
It should only be necessary for system administrators to modify two parts of this section of the shiro.ini
file:
- the location of the Hibernate configuration file in line 3 of the listing,
- the default timeout setting, which is in the example is 15 minutes (specified in milliseconds as shown).
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[main]
hibernateRealm = com.sos.auth.shiro.SOSHibernateAuthorizingRealm
securityManager.realms = $hibernateRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
securityManager.sessionManager.globalSessionTimeout = 900000 |
Maintenance and Security Considerations
While access in order to manipulate the authentication information a database requires the database password, a system administrator still has to manually enter and modify user passwords with the associated security risks and maintenance costs.
Example Database Tables
Code Block | ||||
---|---|---|---|---|
| ||||
create table sos_user(
id number(9) not null ,
sos_user_name varchar2(250),
sos_user_password varchar2 (250),
PRIMARY KEY ( "ID" )
)
create table sos_user_role(
id number(9) not null ,
sos_user_role varchar2(250),
PRIMARY KEY ( "ID" )
)
create table sos_user2role(
id number(9) not null ,
role_id number(9) null ,
user_id number(9) null ,
PRIMARY KEY ( "ID" )
)
create table sos_user_permission(
id number(9) not null ,
role_id number(9) null ,
user_id number(9) null ,
sos_user_permission varchar2(250),
PRIMARY KEY ( "ID" )
) |
The following table names and structure have to be used when configuring database authentication:
Table of User Names and Passwords (SOS_USER) - Structure
...
COLUMN_NAME | DATA_TYPE | NULLABLE | DATA_DEFAULT | COLUMN_ID | COMMENTS | |
---|---|---|---|---|---|---|
1 | ID | NUMBER(9,0) | No | (null) | 1 | (null) |
2 | SOS_USER_NAME | VARCHAR2(250 BYTE) | Yes | (null) | 2 | (null) |
3 | SOS_USER_PASSWORD | VARCHAR2(250 BYTE) | Yes | (null) | 3 | (null) |
Table of User Names and Passwords (SOS_USER) - Contents
...
The password is stored MD5 encrypted. E.g. secret is 5ebe2294ecd0e0f08eab7690d2a6ee69
ID | SOS_USER_NAME | SOS_USER_PASSWORD | |
---|---|---|---|
1 | 1 | administrator |
...
5ebe2294ecd0e0f08eab7690d2a6ee69 | ||
2 | 2 | application_manager |
...
5ebe2294ecd0e0f08eab7690d2a6ee69 | ||
3 | 3 | it_operator |
...
5ebe2294ecd0e0f08eab7690d2a6ee69 | ||
4 | 4 | incident_manager |
...
5ebe2294ecd0e0f08eab7690d2a6ee69 | ||
5 | 5 | business_user |
...
5ebe2294ecd0e0f08eab7690d2a6ee69 | ||
6 | 6 | api_user |
...
5ebe2294ecd0e0f08eab7690d2a6ee69 | ||
7 | 7 | root |
...
63a9f0ea7bb98050796b649e85481845 |
Table of Roles (SOS_USER_ROLE) - Structure
COLUMN_NAME | DATA_TYPE | NULLABLE | DATA_DEFAULT |
---|
...
ID |
...
NUMBER(9,0) | No | (null) |
...
SOS_USER_ROLE | VARCHAR2(250 BYTE) | Yes | (null) |
...
Table mapping users to roles
COLUMN_NAME | DATA_TYPE | NULLABLE | DATA_DEFAULT |
---|---|---|---|
ID | NUMBER(9,0) | No | (null) |
ROLE_ID | NUMBER(9,0) | Yes | (null) |
...
USER_ID | NUMBER(9,0) | Yes |
...
(null) |
...
Table of Roles (SOS_USER_ROLE) - Contents
ID | SOS_USER_ROLE |
---|---|
1 | administrator |
2 | application_manager |
3 | it_operator |
4 | incident_manager |
5 | business_user |
6 | api_user |
7 | all |
Table Mapping
...
users and roles to Permissions (SOS_USER_PERMISSION) - Structure
COLUMN_NAME | DATA_TYPE | NULLABLE | DATA_DEFAULT |
---|
...
ID |
...
...
NUMBER(9,0) | No | (null) |
...
...
ROLE_ID | NUMBER(9,0) | Yes |
...
(null) | |||
USER_ID | NUMBER(9,0) | Yes | (null) |
...
SOS_USER_ |
...
PERMISSION | VARCHAR2(250 BYTE) | Yes | (null) |
...
Table Mapping Roles to Permissions (SOS_USER_PERMISSION) - Contents
ID | ROLE_ID | USER_ID | SOS_USER_PERMISSION |
---|---|---|---|
1 | 1 | 7 | (null) |
2 | 2 | 1 | (null) |
3 | 1 | (null) | sos:products |
4 | 2 | (null) | sos:products:joc_cockpit:jobscheduler_master:view |
...
5 | 2 | (null) | sos:products:joc_cockpit:jobscheduler_master:pause |
6 | 2 | (null) | sos:products:joc_cockpit:jobscheduler_master:continue |
7 | 2 | (null) | sos:products:joc_cockpit:jobscheduler_master:restart |
8 |
...
2 | (null) | sos:products:joc_cockpit:jobscheduler_master: |
...
terminate |
...
9 | 2 | (null) | sos:products:joc_cockpit:jobscheduler_master: |
...
abort |
...
10 | 2 | (null) | sos:products:joc_cockpit:jobscheduler_master |
...
_cluster |
...
11 | 2 | (null) | sos:products:joc |
...
Shown are the default permissions for user root (ID=7) mapped to role all (ID=1) and user administrator (ID=1) mapped to role administrator (ID=2).
_cockpit:jobscheduler_universal_agent |
Shown are the default permissions for user root (ID=7) mapped to role all (ID=1) and user administrator (ID=1) mapped to role administrator (ID=2).
[folders] Configuration
Display feature availability | ||
---|---|---|
|
This feature is available from the following issues:
Jira server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-137 Jira server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-155
Administrators
[folders] Configuration
System Administrators can add a [folders] section to the shiro.ini file to define the folders that can be accessed by a role within the live folder of a JobScheduler configuration.
...
- The
shiro.ini
file is not validated by the JOC Cockpit. This means that a configuration error will lead to that entry not being implementedprocessed.- For example, a spelling error in a permission will lead to that permission not being set.
- The permissions granted for an account can be inspected in the JOC Cockpit interface by logging into the interface using that account and checking the Permissions section of the User Profile view
Logging
Logging of user Authentication can be configured in the $JETTY_BASE/resources/joc/log4j.properties
file. See the JOC Cockpit - Logging article for more information.
Additional Information
Jetty has does not have to be restarted after changes are made to the [main]
section of the shiro.ini
file.
References
- For detailed information about the complete permission set see
...