Page History

...

• [users]
  • Contains authentication information when Shiro authentication is used.
  • Contains the roles assigned to users after authentication when Shiro authentication is used.
  • Is not required for other authentication methods.
• [main]
  •  If LDAP authentication is to be used:
    • contains configuration information for accessing the LDAP service;
    • contains a mapping of LDAP groups onto JOC Cockpit authorization roles.
  •  If Database authentication is to be used:
    • contains configuration information for accessing the database via Hibernate.
  • Contains session timeout information for the JOC Cockpit.
  • Required for all authentication methods.
• [roles]
  • Contains the JOC Cockpit authorization information - i.e. the permissions assigned to roles.
  • Required for all Shiro and LDAP authentication methods.

The order in which these sections are positioned in the shiro.ini file is not important.

...

A default mapping of seven roles is delivered with the JobScheduler. The roles in this mapping correspond with the seven roles specified in the [users] section of the file. This Users can add additional and modify role configurations as required. The default mapping is shown in the listing below:

...

• role=permission1, \
     permission2

• where:
  
  • permissions are separated by commas (","),
  • each permission is shown in the ini file on a new line to ease readability,
  • a backward slash after each permission is used to mark the end of a line in the .ini file,
  • individual permissions are specified hierarchically, with each "level" being separated by a colon (":"),
  • spaces (" ") are not allowed in user names,
  • a wildcard ("*") can be used for all permissions,

  • a minus sign ("-") can be used at the start of a permission to disallow a user access to a resource that they would otherwise be able to use (See, for example the permission set for the api_user in the listing above).
    The following example shows the role demo is allowed access to all products but is not allowed to see status of JobScheduler Master Clusters or any information related to Orders in the JOC Cockpit.

    Code Block
    language text title Shiro Configuration - User Exclusion
    demo = sos:products, \ -sos:products:joc_cockpit:jobscheduler_master_cluster:view:status, \ -sos:products:joc_cockpit:order

• The ID of a JobScheduler can be used to allow or disallow access a particular JobScheduler or Master cluster

  • The following example shows the JobScheduler "scheduler_1" is allowed access to all SOS products but "scheduler_2" is only allowed limited permissions for JobScheduler Masters and all permissions on JobScheduler Universal Agents.

    Code Block
    language text title Shiro Configuration - JobScheduler IDs
    demo = scheduler_1:sos:products, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_master:view, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_master:pause, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_master:continue, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_master:restart, \ scheduler_2:sos:products:joc_cockpit:jobscheduler_universal_agent

• The full default matrix of permissions is shown in the Matrix of Roles and Permissions section of the JOC Cockpit - Authentication and Authorization article.

Users can add additional and modify role configurations as required.

[main] Configuration

This contents of this section depend on the authentication method used.

...

Database Authentication

The [users] section and [roles] sections of this file can be deleted or completely commented out. 

...