...
- The JOC Cockpit accepts the user name and password from the login screen and, depending on the configuration in the
shiro.ini
file, either:- tries to verify the credentials against information stored in the
shiro.ini
file, - tries to login to the LDAP directory service with the given credentials ,or
- 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.ini
configuration file 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 plain text in an unencrypted the
shiro.ini
file that is saved locally, which is unencrypted, in plain text.
- 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.
- 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.
- 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.ini
configuration 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.
...
- 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 a database tabletables.
- Configuration of the
shiro.ini
file is described in detail in the Authentication and Authorization Configuration article.
...
Office Excel | ||||
---|---|---|---|---|
|
Additional Information
Roles and permissions are configurable to the following extent:
...
- The number and type of permissions is fixed.
...
- 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.
...