Introduction
The central configuration of authentication and authorization for the JobScheduler Cockpit is an Apache ShiroTM .ini file. Three methods of authentication - Shiro, LDAP and Database - have been implemented for the JobScheduler Cockpit. These methods are described in the JOC Cockpit - Authentication and Authorization article. This article describes the configuration required to implement the three authentication methods.
Configuration File Structure
The Default Configuration
Shiro Authentication
The shiro.ini file is delivered with a full set of (default) information for Shiro authentication. This information includes an active profile for a default user (root) which has all permissions. This profile allows a system administrator to log onto the JOC Cockpit and access all of its features after installation. After installation a system administrator can modify the shiro.ini file to implement other user profiles and deactivate the root profile.
LDAP and Database Authentication
The information required for LDAP and Database authentication is described in this article.
Installation Directory Location
The location of the shiro.ini file is dependent on whether or not Jetty is installed with the JOC Cockpit.
If Jetty is installed with the JOC Cockpit then the shiro.ini file can be found in the jetty_base directory:
- On Windows systems the default location for the
jetty_basedirectory will be:C:\ProgramData\sos-berlin.com\joc
- On Unix systems it will be:
/home/[user]/sos-berlin.com/joc
If Jetty is not installed with the JOC Cockpit then the shiro.ini file can be found in the ... directory: < COMPLETE SECTION
- On Windows systems the default location
...will be:...
- On Unix systems it will be:
...
The File Structure
The shiro.ini file will have two or three sections, depending on the authentication method specified:
- [users]
- Contains the roles assigned to users.
- Contains authentication information when Shiro authentication is used.
Is not required for other authentication methods.
- [roles]
- Contains the permissions assigned to roles.
- Required for all authentication methods.
- [main]
- Contains timeout information and, if relevant, information for LDAP or Database authentication.
- Required for all authentication methods. < CHECK TIMEOUT FOR LDAP
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.
Default user information for seven users is delivered with the JOC Cockpit in this section as shown in the listing below, with a role 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 the configuration file (described below).
The default user information provided with the JOC Cockpit is shown in the listing below:
- "As delivered" only one role is active - root - and the others are commented out. System administrators can add and modify user configurations as required.
- In this default configuration user names and roles are identical. This is not necessary.
- Passwords are stored in open text. Password encryption is not available with Shiro authentication.
Syntax
user=password, role1, role2- Where:
- user is the user name.
- password is saved in open text .< CHECK
- role entries must be identical to roles specified in the [roles] section of the file. Multiple roles separated by commas can be specified for users.
- Each entry is specified on a new line, password and role are separated by a comma.MULTIPLE ROLES?
[roles] Configuration
This section contains the mapping of roles onto permissions. This section is required when either Shiro or LDAP authentication is used.
A default mapping for seven roles is delivered with the JobScheduler. The roles in this mapping correspond with the seven roles specified in the [users] section of the file. This mapping is shown in the listing below:
Syntax
role=permission1, \
permission2- where:
- each permission is shown in the ini file on a new line to ease readability
- a backward slash after each permission is used to mark the end of a line
- a wildcard ("*") can be used for all permissions
a minus sign ("-") can be used to disallow a user access to a resource that they would otherwise be able to use.
The following example shows the user demo is allowed access to all products but is not allowed to see ... < REPLACE EXAMPLE - SEEMS MEANINGLESSShiro Configuration - User Exclusiondemo = sos:products, \ -sos:products:joc_cockpit:jobscheduler_master_cluster:view:status, \ -sos:products:joc_cockpit:order
A JobScheduler ID can be used to disallow allow or restrict a user access to a particular JobScheduler.
The following example shows the user demo is allowed access to all products but is not allowed to see ... < REPLACE EXAMPLE - SEEMS MEANINGLESSShiro Configuration - User Exclusiondemo = sos:products, \ -sos:products:joc_cockpit:jobscheduler_master_cluster:view:status, \ -sos:products:joc_cockpit:order
Users can add additional user configurations.
[main] Configuration
This contents of this section depend on the authentication used.
Shiro Authentication
The only information required in the [main] section for Shiro authentication is a timeout. The default timeout setting is 20 minutes as shown in the listing below:
[main] securityManager.sessionManager.globalSessionTimeout = 1200000
Syntax
- Is required?
LDAP Authentication
The information required in the [main] section for LDAP authentication is shown in the listing below.
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = cn={0},CN=ur_dell_partition,DC=localhost
ldapRealm.searchBase = CN=ur_dell_partition,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=ur_dell_partition,DC=localhost":"it_operator", \
"CN=jobscheduler_admin,CN=Roles,CN=ur_dell_partition,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
securityManager.sessionManager.globalSessionTimeout = 360000
It should only be necessary for system administrators to modify three parts of this section:
- the LDAP service information in lines 4 to 6 of the listing,
- the mapping of LDAP groups to roles in lines 13 to 16, which id described in the next sub-section and
- the default timeout setting for LDAP of 6 minutes as shown in the last line. < CHECK TIMEOUT FOR LDAP
Example Mapping LDAP Groups to Roles < CORRECT SYNTAX FOR LDAP GROUP NAMES
- In line 15 of the listing above members of the JobScheduler_it_operator LDAP group are allocated the it_operator role
- More than one role can be specified for members of an LDAP group
- In line 16 members of the jobscheduler_admin group are allocated the roles of administrator and application_manager.
Database Authentication
The information required in the [main] section for database authentication is shown in the following listing:
[main] hibernateRealm = com.sos.dialog.auth.SOSHibernateAuthorizingRealm hibernateRealm.hibernateConfigurationFile=C:\Users\ur\Documents\sos-berlin.com\jobscheduler\scheduler_current\config\hibernate.cfg.oracle.xml securityManager.realms = $hibernateRealm cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager securityManager.cacheManager = $cacheManager
It should only be necessary for system administrators to modify two parts of this section:
- the LDAP service information in line 3 of the listing,
- the default timeout setting is 20 minutes as shown in the listing below: < WHERE IS TIMEOUT?
Syntax
- TODO
Note
Jetty has to be restarted after changes to the shiro.ini file.
Additional Information
Text to be added ....