JOC Cockpit Session Management for active clustering with load balancers

Current Situation

• JOC Cockpit can be operated in any number of instances that
  • connect to the same Reporting Database and JobScheduler Databases
  • connect to the same JobScheduler Master instances
  • can be used in parallel to control any Master.
• The current solution includes the follwing drawbacks:
  • A session that is started for a specific JOC Cockpit instance has to be continued with that instance. Switching to a different instance requires a new login.
  • The Shiro configuration with shiro.ini has to be synchronized across servers.

Desired Behavior

• JOC Cockpit should use the reporting database to manage user sessions.
  • The session object should be serialized in the Reporting Database.
  • Any JOC Cockpit instance can read the session object from the database and can continue a session that was started with a different instance.
  • Load balancers should be able to route http(s) requests from user browsers to any JOC Cockpit instance that would continue the user session.
• The configuration file shiro.ini is managed in the database and is automatically deployed to the file system when changes occur.

Clustered shiro session
To achieve the JOC cluster with clustered shiro sessions the sessions must be distributed with

sessionDAO = com.sos.auth.shiro.SOSDistributedSessionDAO
securityManager.sessionManager.sessionDAO = $sessionDAO

Sharing shiro.ini
The content of the shiro.ini will be stored in the JOC_CONFIGURATION table with

instance_id=0
account="."
object_name=INI-FILE
configuration_type=SHIRO
name=shiro.ini
shared=1
configuration_item=the content of the file as a clob
modified=date
scheduler_id=""

Login Process:

• When the record does not exist in the database
  • the shiro.ini file will be read from the file system
  • the content will be stored in the database
• When the record exists in the database
  • the content will be stored in the file in the file system

Change shiro.ini

• The login works with the file shiro.ini.active
• Direct changes in this file have no effect as it will be overwritten during the next login process
• Changes are made with JOC Cockpit
  • Changing the user, roles and permissions is already available
  • Editing the [main] section will be added
• Changes are directly stored into the database
• Changes are also stored in the shiro.ini.active file. This is not necessary as this will be done during the next login but it is good if users want to check the file.

Force a new File

• It should be possible to make a global change with a file from the file system.
• The import file function will check during the login process whether a file shiro.ini exists.
• If the file exists the content of the file will be stored in the database and the file shiro.ini will be deleted
• The existing file shiro.ini.active will be renamed to shiro.ini.backup before overwriting it with the new imported content.

Delimitation

• The sharing of sessions and Shiro configurations with the database does not apply to configuration files that are specific for an instance.
  • The ./jetty_base/resources/joc/joc.properties file is specific for a JOC Cockpit instances as it can include different paths per instance.
  • The /jetty_base/start.ini file is handled specifically for individual JOC Cockpit instances in the same way.