Introduction

• Identity Services implement authentication methods and access to Identity Providers, for example, credentials such as account/password, are used as an authentication method to access an LDAP Directory Service as the Identity Provider, see JS7 - Identity and Access Management.
• JOC Cockpit implements a pluggable architecture that allows to add Identity Service products with future JS7 releases.
• For compatibility reasons early releases of JS7 include the Shiro Identity Service, see  JOC-1145 - Getting issue details... STATUS
  • FEATURE AVAILABILITY ENDING WITH RELEASE 2.3.0

Matrix of Identity Services

Identity Services can be used in a number of flavors depending on the fact 

• which application manages user accounts/passwords:
  • a specific application of the Identity Service,
  • JOC Cockpit that propagates user accounts/passwords to the Identity Service but does not store such credentials with its database.
• where assignments of roles to user accounts are stored
  • with the Identity Service
  • with the JS7 database
    
    

Manage Identity Services

The operation to manage Identity Services is available from the user menu in the right upper corner of any JOC Cockpit page:

This operation brings forward the list of available Identity Services.

• By default the built-in JOC Identity Service is available.
• The Shiro Identity Service is available for migration purposes up to release 2.3.0.
  
  

Add Identity Service

To add an Identity Service use the respective button from the list of Identity Services:

Explanation:

• The Name of the Identity Service can be freely chosen.
• The Identity Service Type can be selected as available from the above matrix.
• The Ordering specifies the sequence in which a login is performed with available Identity Services.
• The Required the attribute specifies if login with the respective Identity Service is required to be successful.

Manage Settings

Settings are available at a global level and per Identity Service.

Global Settings

Global settings are applied for all Identity Services.

• At the time of writing a single setting for the max. idle timeout of user sessions is applied.
  
  • Should the lifetime of a token provided by an external Identity Service be different from the max. idle-timeout then JOC Cockpit will try to renew the token with the Identity Service. Renewal of a token does not require the user to repeatedly specify credentials for login.
  • Identity Services can restrict the lifetime of tokens and they can deny renewal of tokens. If a token cannot be renewed then the user session is terminated and the user is required to perform a login.
    
    

Vault Identity Service Settings

For use of the HashiCorp® Vault Identity Service

• the Vault product has to be installed and accessible for JOC Cockpit,
• the following settings have to be specified: 
  
  

Explanation:

• Vault URL: the base URL for which the Vault REST API is available
• Vault Keystore Path:  Should the Vault REST API be configured for HTTPS Mutual Authentication then the indicated keystore has to include the private key specified for the extended key usage of Client Authentication. 
• Vault Keystore Password: Should the Vault REST API be configured for HTTPS Mutual Authentication and the indicated keystore be protected by a password then the password has to be specified.
• Vault Key Password: Should the Vault REST API be configured for HTTPS Mutual Authentication and the indicated private key be protected by a password then the password has to be specified.
• Vault Keystore Type: Should the Vault REST API be configured for HTTPS Mutual Authentication then the type of the indicated keystore has to be specified being either PKCS12 or JKS.
• Vault Truststore Path:  Should the Vault REST API be configured for HTTPS then the indicated truststore has to include an X.509 certificate specified for the extended key usage of Server Authentication. This can be a self-signed server certificate or a CA-signed certificate (typically the Root CA certificate is used as otherwise the complete certificate chain involved in signing the server certificate has to be available with the truststore).
• Vault Truststore Password: Should the Vault REST API be configured for HTTPS and the indicated truststore be protected by a password then the password has to be specified.
• Vault Truststore Type: Should the Vault REST API be configured for HTTPS then the type of the indicated truststore has to be specified being either PKCS12 or JKS.
• Vault Application Token: The application token has to be created by Vault for JOC Cockpit. It allows to access the Vault REST API and e.g. to renew tokens for user sessions.

JOC Identity Service Settings

The built-in Identity Service does not require any settings.

The built-in Identity Service does not require any settings.

After installing the JOC Cockpit, log in with the default root:root user name and password which comes under the Shiro identity service.

The Manage Accounts section of the JOC Identity is then accessed via the Profile Menu as shown in the screenshot below. Select Identity Management Service.

The Identity Management Service window has the list of the available Identity Services which is previously created or you can also create a new Identity service. From here you can select the Identity Services to manage the accounts inside it. Select the JOC from the list.

The JOC Identity Service window has the three main section which can managed via the tabs:

• Accounts: for the configuration of User Accounts. Accounts configured in the Database and access from there only.
• Manage Roles: for configuring Roles and the Controller that can be accessed by a Role.
  • Permissions: a sub-view for configuring access to Folders and Role Permissions.
• Profile: from this view user can check the last login detail.

These tabs will be described in the following sections.

The Accounts Tab

The Accounts tab is opened first when a user selects the Identity Service from the Identity Management Service window and lists all the User Accounts that have been configured along with the Roles they have been assigned.

The above screenshot shows the test User Account which is manually created with the role. Currently, JOC Identity Service does not contain any default account and roles inside it. 

• The Create Account button is used to open a window to add a new User Account with name, password, and Roles.
• The additional options (ellipsis) symbol allows an Account to be edited (change the Account Name and/or Password, select/deselect Roles) and to be copied or deleted.
• Clicking on the Account Name brings the user to the Manage Roles tab (described below) where the Controllers and Role(s) allocated for the User Account can be edited.

The Manage Roles Tab

The main purpose of the Manage Roles tab is to allow Controller Roles and any Controller which these Roles will be restricted to be configured. 

When the tab is first opened after installation of the JOC Cockpit it will be blank and no roles are created by default. In the below screenshot you can see test-role created manually.

Roles contain default in the controller which means the role is available for all the Controllers - the default setting.

If the Manage Roles tab is opened by clicking on an Account Name in the Accounts tab (described in the previous section), the Manage Roles Tab will show those Roles that have been assigned to that Account. The Account that is active is shown in the Account button, which can also be used to select and deselect Accounts.

Positioning the mouse over a role name blends in two links as shown in the screenshot above:

• the pencil link allows the role to be edited and
• the X link allows the role to be deleted.

A set of Permissions is configured for each role. Each Permissions set can be inspected by clicking on the default from the list of roles, which will open the Permissions tab for the Role. An example Permissions set is described in the next section. A matrix showing the default Roles and their Permissions along with a description of the Permission is provided in the JS7 - Permissions article.

The Permissions Sub-View

The main purpose of the Permissions view is to allow Folders and Permissions to be configured for each Role.

Folder Selection

Folders are added using the Add Folder button shown in the background of the screenshot below, at the top right.

Folders themselves are selected from a simple tree view of the folders. This tree view is opened by clicking on the folder symbol shown in the screenshot.

Permissions Configuration

Two editors are available for the configuration of the Permissions granted for a Role:

• A graphical editor as shown in the next screenshot:
  
• Changes to the Permissions tree are saved in the database.
• The Undo button allows the last 10 changes made to be undone stepwise.
  • The states saved in the Undo button will be deleted when the Permissions tab is left.
• The Redo button changes the Permissions tree back to the initial state when the Permissions Tab was opened.
  • The state stored in the Redo button will be deleted when the Permissions tab is left.
• Clicking on the middle of a Permission icon will grant the Permission for the current Role.
  
  • Granted Permissions have a blue background and are by default recursive.
• The "+" and "-" symbols at the right of each Permission icon open and close child branches.
• The "-" and "+" symbols at the left of each Permission icon are used to revoke a higher Permission and are by default recursive.
  • Permission icons affected by revoked Permissions are shown with a gray background 
    
    
• A list editor as shown in the next screenshot:
  
  
  • Individual Permissions can be modified and removed from the Role using the pencil and X symbols that are blended in when the user's mouse is moved over a Permission:
  • The Edit function allows the Permission to be made subtractive - i.e. for permission granted at a higher level to be removed.
  • The Folder part of the view is for restricting the Role to accessing particular Folders - and thereby particular workflow.

Initial Configuration

Creating and Configuring User Accounts and Roles

System administrators will likely want to create and configure their own User Accounts and Roles, for example, limiting access to resources such as JobScheduler objects and logs.

It is often easier to create Manage new Roles, assign Permissions or Folders to these Roles and then create new User Accounts and assign Roles to them.

Creating a new Role

• New Roles are created in the Manage roles tab using the Add Role button:
  
• Once a new Role has been created it will be automatically added to the list of Roles shown in the background of the screenshot above.

Configure Permissions and/or Folders for the Role

• Now expand the Role using the arrow button click on the default (blue link) to add Permissions and/or Folders in the Permissions tab. The Procedures available for adding and editing Permissions and Folders are described in the Editing User Permissions and Folders sections below.
  • Note that Roles that neither have Permissions or Folders assigned to them are deleted automatically when the Manage Identity Service view is left.

Create a new User Account

• After Permissions / Folders have been configured select the Accounts tab to create a new User Account and allocate one or more Roles to this Account.
  
  
• The Edit Account function is accessed by clicking the relevant Action symbol (ellipsis) in the  Actions column of the User Accounts list (visible in the background of the above screenshot). This can be used to change the Password, the Account name and add or remove Roles. 
  
  • Note that deselecting a Role in this modal window 'uncouples' the Role from the User Account - it does not delete the Role. 

Editing User Permissions

Permissions Structure

Permissions are strictly hierarchical:

• A Role with the Permission sos:products:controller:view 'only' allows a User to view Controllers, while a User with the 'higher' sos:products:controller Permission is able not only to view Controllers but able to carry out other operations - in this case, view, restart, terminate, and switch_over.
• The JS7 - Permissions article contains a link to a full list of all Permissions that can be granted.

Editing Permissions

Consider any user have a role(demo-role) with the following permission:

sos:products:controller:view

This permission does not allow the demo-role to perform the operation on the Controllers. These Permissions could be granted individually with the following:

sos:products:controller:restart
sos:products:controller:terminate

The following Permissions can be set to allow the demo-role Role to view, restart and terminate the Controller, but not Switch_over:

sos:products:controller:view
sos:products:controller:restart

Alternatively, it may make sense in some situations to grant the Role a higher level of Permission and then remove one or more specific Permissions. This approach is shown in the following combination:

sos:products:controller
-sos:products:controller:switch_over

where the ...sos:products:controller Permission is an overall 'Controller' Permission covering view, restart and terminate, and the -sos:products:controller:switch_over Permission is removed from the demo-role Role.

Caution

Users should have Role with the following Permission - or higher - before they are able to log into the JOC Cockpit:

sos:products:joc:administration:controller:view

Shiro Identity Service Settings

The Shiro Identity Service does not require any settings.