Introduction
The JOC Cockpit brings user authentication and authorization to the JobScheduler. Authentication can either take place against an Apache ShiroTM compliant configuration file, an LDAP compliant directory service or information stored in a database. Authorization is defined in roles - an example set of roles is provided with the JOC Cockpit installation archive and users are able to define their own roles. The JOC Cockpit is able to handle authentication of multiple users and their authorization for multiple JobSchedulers simultaneously.
Authentication and Authorization
- The JOC Cockpit uses Apache Shiro to authenticate and authorize users.
- Authentication and Authorization information can be read by Shiro from a number of separate resources. These are:
- a local configuration (
shiro.ini) file that may include both authentication and authorization information, depending on the methods of authentication and authorization configured; - a authentication service that provides an LDAP interface such as Microsoft Active Directory and
- a database containing both authentication and authorization information and which complies with the Shiro data model requirements. This database will be managed (and populated) by a system administrator.
- a local configuration (
Authentication
- The JOC Cockpit accepts the user name and password from the login screen and, depending on the configuration in the
shiro.inifile, either:- tries to verify the credentials against information stored in the
shiro.inifile, - tries to login to the LDAP directory service with the given credentials or
- checks the credentials against information stored in a Shiro compliant database.
- tries to verify the credentials against information stored in the
- The authentication credentials are subsequently used for HTTP Authentication with each HTTP request that is created by the JOC Cockpit for the JobScheduler Web Services.
- Browsers may cache credentials during a session, i.e. they are re-used for single sign-on when opening the JOC Cockpit in a new browser tab. The credentials cache is cleared on termination of the browser.
- This behavior might vary depending on the browser and version.
- The configuration of the local
shiro.inifile is described in detail in the Authentication and Authorization - Configuration article.
Authentication Methods
The intended purposes of the authentication methods available are:
- Shiro Authentication:
- Intended for development and use where security is of relatively low importance.
- User passwords are saved in the
shiro.inifile, which is unencrypted, in plain text.
- LDAP Authentication:
- Intended for use in production environments where LDAP is already in use.
- The
shiro.inifile contains information specifying the LDAP service.
- Database Authentication:
- Intended for use in production environments.
- The
shiro.inifile contains information specifying the database authentication service. - Authentication information is entered manually in the database by a system administrator.
Authorization
After successful authentication the JOC Cockpit will check the assignment of roles to the given user against a mapping of user role(s) against permissions. The method used to specify this mapping depends in the method used for user authentication:
- Shiro Authentication:
- Using a mapping of roles to permissions stored in the local
shiro.iniconfiguration file.
- Using a mapping of roles to permissions stored in the local
- LDAP Authentication:
- Using a configurable LDAP query that checks membership of the user with a number of Active Directory groups. An LDAP query is configured for each role and in case of a positive match for group membership the user is assigned a relevant role. This role is then mapped onto a set of permissions using information stored in the local
shiro.iniconfiguration file.
- Using a configurable LDAP query that checks membership of the user with a number of Active Directory groups. An LDAP query is configured for each role and in case of a positive match for group membership the user is assigned a relevant role. This role is then mapped onto a set of permissions using information stored in the local
- Database Authentication:
- Using a Hibernate query to check the user's role(s) against a table of roles and permissions stored in the same database as used for authentication.
By default the shiro.ini configuration file contains an example mapping of roles and permissions. This mapping can be used with Shiro and LDAP authentication and is shown in the Matrix of Roles and Permissions section below.
- System administrators can:
- add additional roles of their own to the mapping and
- change the permissions assigned to roles.
- System administrators wishing to use database authorization can copy this mapping into database tables.
- Configuration of the
shiro.inifile is described in detail in the Authentication and Authorization - Configuration article.
Viewing User Profile and Roles
A user can check the permissions they are currently allocated in the JOC Cockpit. This is done in the User Profile view, which is opened via the user menu in the top right of the JOC Cockpit window. The following screenshot shows the User Details and Roles information for a user SOS:
This view is read-only for all users - changes can only be made by a system administrator modifying the authentication and authorization configuration as described in the the Authentication and Authorization - Configuration article.