Page History

...

Authentication and Authorization

Architecture

The Authentication and Authorization provided by the JOC Cockpit is provided independently of any JobScheduler instances and this functional independence allows, for example, scalability (see the JOC Cockpit Clusters section below) as well as enabling individual JobScheduler Masters and/or Agents to be used for individual clients. A more detailed description of the JobScheduler / JOC Cockpit architecture is provided in the JOC Cockpit - Architecture article.

The JOC Cockpit Authentication and Authorization allows an extremely flexible set of permissions to be configured for Users:

• User Accounts are allocated one or more Roles, with each Role containing a set of predefined Permissions that specify the operations that can be carried out within the role.
• Roles can be configured for individual JobScheduler Masters.
• In addition, the objects within a JobScheduler Master configuration that can be accessed by a Role can also be configured. For example, one Role may be allowed to view the status of Jobs and Orders in Folders A and B, another Role may be allowed to change the state and modify the run times of the Jobs and Orders in all Folders. This approach may be contrasted with other systems that allocate rights and permissions purely according to resources such as files or folders.

This use of role-based permissions brings a number of significant advantages:

• It simplifies administration in complex environments. Whilst the administration of the permissions of several hundred folders in a multi-client system is manageable, the administration of several thousand requires brings an extremely high administrative requirement and error susceptibility.
• Role-based permissions allow the permissions for individual clients to be managed separately.
• The clear separation of permissions also simplifies meeting compliance requirements.

JOC Cockpit Clusters

Multiple instances of the JOC Cockpit can be synchronized to provide a high availability, active, cluster that is transparent to the user. Cluster members then share Authentication and Authorization information.

A more detailed description of JOC Cockpit clusters can be found in the JOC Cockpit - Clustering article.

Implementation

• The JOC Cockpit uses The JOC Cockpit makes use of Apache Shiro to authenticate and authorize users.
• Authentication and Authorization information can be mapped toread by Shiro from a number of separate resources. These are:
  • a local configuration (shiro.ini) file that includes user names, roles and permission,may include both authentication and authorization information, depending on the methods of authentication and authorization configured;
  • a authentication a directory service that provides an LDAP interface , e.g. such as Microsoft Active Directory ,and
  • database that a database containing both authentication and authorization information and which complies with the Shiro data model requirements and that is . This database will be managed (and populated) by an a system administrator.

Authentication

• The JOC Cockpit / Web services accepts the user name and password from the login screen and, depending on the configuration in the shiro.ini file, either:
  • either tries to verify the credentials from its local configuration against information stored in the shiro.ini file,
  • tries to login to the Active Directory LDAP directory service with the given credentials ,or
  • or checks the credentials against information stored in a Shiro compliant database.
• The authentication credentials are subsequently used for HTTP Authentication with each HTTP request that is created by the JOC Cockpit to 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.

Authentication

...

Methods

The authentication methods available are:

• Shiro Authentication:
  • Intended for development and use where security is
  of relatively low importance
  • important.
  • User passwords are saved in plain text in an unencrypted encrypted in the shiro.ini file

    Display feature availability
    StartingFromRelease 1.11.5

    . The shiro.ini file that itself is saved locallyunencrypted.
• LDAP Authentication:
  • Intended for use in production environments where LDAP is already in use.
  • The JOC Cockpit configuration The shiro.ini file contains information specifying the LDAP service.
  • Shiro and LDAP Authentication can be combined.
• Database Authentication:
  
  • Intended for use in production environments.
  • The JOC Cockpit configuration shiro.ini file 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.ini configuration file.
• LDAP Authentication:
  • Using
  :
  • either by using a configurable LDAP query that checks determines membership of the user with a number of an 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 the relevant role.
  • or by using its local configuration file that includes a assignment of users and roles.
• The assignment of permissions to roles is configured with the local shiro.ini configuration file.
  • By default the JOC Cockpit ships with a number of predefined roles and assigned permission, see the Matrix of Roles and Permissions below.
  • Users can:
    • add additional roles of their own,
    • change the permissions assigned to roles.
• Authorization is configured in an .ini file described in detail in the Authentication and Authorization Configuration article.

User Profile and Roles

The following screenshot shows the JOC Cockpit User Profile view with the User Details and Roles information:

Image Removed

• • group. The Active Directory group is then mapped onto one or more Shiro Roles. These Roles are then mapped onto a set of Permissions using information stored in the local shiro.ini configuration file.
• 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 by administrators as a basis for their own configurations with either Shiro or LDAP authentication. This mapping and the function of individual Permissions are described in the Matrix of Roles and Permissions section of the Authentication and Authorization - Permissions for the JOC Cockpit Web Service Article.

Configuration

Three methods are available for configuring Authentication and Authorization:

• A text editor can be used to directly edit the local shiro.ini file. This approach is described in detail in the Authentication and Authorization - Configuration article and can be used with Shiro and LDAP Authentication.
• The JOC Cockpit's Manage Accounts configuration editor can be used as described in the Authentication and Authorization - Managing User Accounts article.

  Display feature availability
  StartingFromRelease 1.11.2

  This editor can be used with Shiro and LDAP Authentication. Some the features of this editor are illustrated in the screenshot below:
  

  Image Added

• Database Authentication and Authorization requires that some configuration information is stored in the shiro.ini file using a text editor. In addition, database Authentication and Authorization involves administrators writing their own SQL Insert statements. We have neither a GUI for this nor is batch support provided. Example database tables are described in the Authentication and Authorization - Configuration article along with the example configuration information for the shiro.ini file.

Viewing a User Profile and its Roles and Permissions

Each user can check the permissions they are currently allocated in the JOC Cockpit. This is done in the lower part of 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 aa_s, that has two Roles, super and workingplan.

Image Added

  Show If

Matrix of Roles and Permissions

The document below shows the default roles and permissions delivered with the JOC Cockpit. System administrators can define additional roles and modify permissions as required.

Document: joc-role-operation-permission.xlsx

Additional Information

Roles and permissions are configurable to the following extent:

Note that this view shows the permissions for the operations that can be carried out within the Roles allocated to the user. The folders permissions allocated to these Roles can be easily viewed in the folder trees in the Job Chains and Jobs views

References

• For detailed information how to configure permissions see the Authentication and Authorization - Configuration article.
• For a complete list of permissions see the Authentication and Authorization - Permissions for the JOC Cockpit Web Service article
• 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.
  • A user can be assigned any number of the roles offered.
• Role/permissions configuration file:
• The configuration of the permissions for each role is stored in a shiro.ini file.
Users can be added to groups in an Active Directory for which queries have to be configured with shiro.ini.