You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

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 - a set of roles is provided with the JOC Cockpit 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 makes use of Apache Shiro to authenticate and authorize users.
  • Authentication and Authorization can be mapped to:
    • a local configuration (.ini) file that includes user names, roles and permission,
    • a directory service that provides an LDAP interface, e.g. Microsoft Active Directory,
    • database that complies with the Shiro data model requirements and that is managed (and populated) by an administrator.

Authentication

  • The JOC Cockpit accepts the user name and password from the login screen and:
    • either tries to verify the credentials from its local configuration file,
    • tries to login to the Active Directory service with the given credentials,
    • or checks the credentials in a Shiro compliant database.
  • The credentials are subsequently used for HTTP Authentication with each HTTP request that is created by the JOC Cockpit to 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.
  • Intended for development and use where security is of relatively low importance.
    • User passwords are saved in plain text in an unencrypted .ini file that is saved locally.
  • Intended for use in production environments where LDAP is already in use.
    • The JOC Cockpit configuration file contains information specifying the LDAP service.
  • Intended for use in production environments.
    • The JOC Cockpit configuration file contains information specifying the database authentication service.
    • Authentication information is entered manually in the database.

Authorization

  • After successful authentication the JOC Cockpit will check the assignment of roles to the given user:
    • either by 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 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.

User Profile and Roles

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

 

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

Error rendering macro 'viewxls'

com.atlassian.confluence.macro.MacroExecutionException: com.atlassian.confluence.macro.MacroExecutionException: The viewfile macro is unable to locate the attachment "joc-role-operation-permission.xlsx" on this page

Additional Information

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.
    • 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.

 

 

  • No labels