JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 13

changes.mady.by.user Andreas Püschel

Saved on

compared with

New Version Current

changes.mady.by.user Andreas Püschel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Introduction

  • The JS7 components products are easy to install out-of-the-box. However, a number of configuration items have to should be considered when operating the JS7 for a secure environment.
  • Secure operation is applied to the following areas:
    • Connection Management
      • Network Connections
      • Database Connections
    • Access Management
      • Authentication
      • Authorization
    • Credentials Management
      • Database Credentials
      • Job Credentials
  • Secure operation includes users configuring JS7 components products in a compliance-conformant way.

Connection Management

JS7 components products use the following connections:Image Removed

Image Added

The above diagram suggests that the JOC Cockpit is the only JS7 product that is directly exposed to user access.

  • This allows to operate JS7 products in different network zones. JOC Cockpit can be located in a deployment zone from which users deploy workflows. Controllers and Agents can be operated in more secure network zones.
  • The underlying principle is to allow connections from a less secure deployment zone to more secure zones and to deny connections to go the opposite way.
  • If jobs are operated on JS7 Agents that require access to the JS7 REST Web Service API then it is recommended to set up additional JOC Cockpit API Server instances. Such instances do not include the user interface but serve the REST Web Service API only. Any number of API Server instances can be set up & operated in parallel and they can be located close to JS7 Agents.

Network Connections

All network connections are unidirectional, as indicated by the direction of the arrows in the diagram above diagram.

Default Configuration

The following default configuration is implemented by the installer if users do not modify settings during installation:

  • All network connections make use of HTTP:
    • Connections by users to the JS7 - Browser User Interface
    • Connections by the PowerShell CLI or external applications to the JS7 - REST Web Service API
    • Connections by the JOC Cockpit to the JS7 Controller using the JS7 REST Web Service API
    • Connections by JS7 Controller instances to Agents
  • Port Usage
    • The JOC Cockpit can be accessed at port 4446
    • The JOC Cockpit REST Web Service can be accessed at port 4446
    • The JS7 Controller uses port 4444
    • The JS7 Agent listens to port 4445
  • Network Interface Usage
    • By default JS7 components products will listen to the above mentioned ports on any available network interfaces.
  • Firewall Settings
    • Open ports in your firewall exclusively for the hosts, protocols and ports as specified above. Consider allowing connections only for the directions indicated in the diagram above.

...

  • Configure network connections to use HTTPS:
    • Use of HTTPS includes providing valid certificates for the hosts that JS7 components products are operated for. Use of self-signed certificates is not recommended as they cannot be verified to a trusted sourcePrivate CA-signed Certificates and Public CA-signed Certificates are both acceptable. For details see JS7 - How to create X.509 SSL TLS Certificates.
    • As HTTPS is limited to secure connections, additional authentication is required. In this case, a JS7 Controller instance is configured to authenticate with an Agent in order to guarantee that the Controller instance is in fact, what it claims to be and is entitled to access the Agent.
    • The JS7 - Secure Connections article explains the use of the built-in Certificate Authority and the use with external Certificate Authorities.
    • For detailed instructions for configuration see:
  • Restrict use of network interfaces:

Database Connections

The JOC Cockpit API Service is the only JS7 component product that uses a database.

Database connections are based on JDBC. If JDBC type 4 drivers are used then a DBMS client is not required for the operation of the JOC Cockpit. The Hibernate access layer is used for database access.

Consider DBMS vendor instructions how to set up secure connections to the database,

Default Configuration

  • JS7 ships with JDBC Drivers that are open source or that are free for distribution with JS7.
  • The JOC Cockpit installer allows:
    • to specify specification of alternative JDBC Drivers that can be downloaded from the respective vendor's web site.
    • to specify specification of individual Hibernate configuration files with security related settings.
  • For details see see the JS7 - Database article.

Secure Configuration

  • Depending on the DBMS version in use it is preferable to download and to apply the DBMS vendor's current JDBC Driver version:
    • For use with MySQL® the JDBC Driver is not included with JS7. Instead a MariaDB® driver is provided for access to MySQL® databases.
    • For use with SQL Server® the JDBC Driver is not included, instead . Instead users have to download a current JDBC Driver from the vendor's site.
    • For use with Oracle® newer the JDBC Driver is included. Newer JDBC Driver versions might be available from the vendor's web site.
  • Vendor-specific JDBC Drivers include support for specific authentication mechanisms, for . For example
  • Consider additional security related settings that apply to your DBMS in the Hibernate configuration file, for . For the location of this file see see the JS7 - Database article.

Access Management

Access to JS7 components products is centrally secured by the JS7 - REST Web Service API. This interface is used by the JS7 - Browser User Interface and by external applications using the REST API.

Roles and Permissions

Default Configuration

  • Consider Refer to the hints provided in the JS7 - JOC Cockpit - Secure Operation articleThe .
  • The JOC Cockpit by default ships with the JOC-INITIAL Identity Service, see JS7 - Identity Services which includes:
    JS7 - REST Web Service API ships with a default configuration in ./joc/resources/joc/shiro.ini that includes
    • use of local authentication with accounts and passwords stored as hash values in the JS7 - Database.
    • use of local role assignment,
    • the following default values for user accountsaccount, passwords password and assigned roles (see JS7 - Manage User Accounts for more information):
      • Active AccountsUser Account:
        • root=root, all
        • user account: root
        • password: root
      • Active Role:
        • all
      • Available Roles:

        • administrator

        • all

        • api_user

        Deactivated Accounts (passwords are presented in plain text for documentation purposes and are hashed in the shiro.ini configuration file:

        • # administrator=secret, administrator
          # application_manager=secret, application_manager# it_operator=secret, it_operator

        • business_user

        • # incident_manager=secret, incident_manager# business_user=secret, business_user
          # api_user=secret, api_user

        • it_operator

    • no other accounts are available by default.
  • The JS7 Controller is not accessed by users but exclusively by the JOC Cockpit via the JS7 - REST Web Service API.
    • Default authentication for the connection from the JOC Cockpit to the Controller is provided from symmetric by asymmetric passwords available with:
      • the JOC Cockpit JS7 - Settings page in section "joc" with the settings controller_connection_joc_password and controller_connection_history_password,
      • the Controller's private.conf file that which holds the password setting optionally by default as a hashed value.
    • It is recommended to use certificate based authentication by that JS7 - Certificate based Authentication using HTTPS connections with mutual authentication is implemented, see JS7 - Controller HTTPS Connections.
  • JS7 Agents are not accessed by users but exclusively by a JS7 Controller. Default authentication is not provided.

...

  • Using the default root user account that ships with the JOC Cockpit is not recommended. The default user account is intended to enable initial login only.
  • A fine-grained set of permissions is available that can be applied to any operation in the JOC Cockpit and in the JS7 REST Web Service API. Such permissions can freely be grouped to roles, see JS7 - Authorization.
  • JS7 - Identity Services offer a number of authentication methods that can be combined for single-factor and multi-factor authentication (MFA).
    LDAP Directory Services should be used when ever possible
    • to establish role assignment for users based on membership in LDAP Directory Service security groups.

...

Identity Services

Default Configuration

  • LDAP Directory Service integration is not in place.
  • Using the default configuration with local authentication for access to JOC Cockpit is not recommended.

Secure Configuration

  • JS7 - Identity Services offer a number of authentication methods such as LDAP, OIDC, FIDO2 etc.
  • By default access to the JOC Cockpit is ruled by local authentication management from the JS7 - JOC Identity Service. This Identity Services stores hashed credentials in the database.
  • No other Identity Service is active by default.

Secure Configuration

  • Users can switch to one of the supported Identity Services such asLDAP
      • Directory Services can be accessed for authentication and authorization:
        • users can connect by specifying their domain account.
        • membership in security groups can be optionally mapped to roles managed with JOC Cockpit.
      • The use of LDAP allows operation of a JOC Cockpit configuration that contains neither user account data, passwords nor user role assignments. 
      • This applies to any LDAP compliant product such as Microsoft Active Directory®, OpenLDAP etc.
    For details about LDAP support see JS7 - LDAP Identity Service
    • JS7 - OIDC Identity Service
      • OIDC offers token based authentication that includes a direct connection between the user and the Identity Provider.
      • JOC Cockpit has no access to passwords in this authentication scheme.
    • JS7 - Certificate Identity Service
      • Client Authentication certificates can act as a replacement for passwords.
      • The Identity Service can be used for single-factor authentication and for MFA.
    • JS7 - FIDO Identity Service
      • Public/private key authentication by use of a secure device eliminates the use of passwords.
      • The Identity Service can be used for single-factor authentication and for MFA.
  • A number of Identity Services can be combined to be optional or required. This allows to authenticate with one Identity Service from a list of available services and it allows to force authentication with all configured Identity Services.
  • Users should consider to disable the initial JOC Identity Service when more secure Identity Services are in place.

Credentials Management

Database Credentials

...

  • Database credentials are specified during installation and are added to the following Hibernate configuration filesfile:
    • JOC Cockpit: for access to the reporting database: JETTY_BASE/resources/joc/reporting.hibernate.cfg.xml
    • For details see see the  JS7 - Database article.
  • Default No default values are not provided by the installer.

...

  • Do not use passwords.
    • Users frequently ask if JS7 can encrypt credentials. The answer is "no" as it makes no sense to handle a symmetric key that is in reach of the component product that makes use of it. Encrypted passwords correspond passwords correspond to the "key under the mat", they . They do not provide additional security, however. However, they perfectly contribute to obfuscation.
    • There is one way only how to securely handle passwords: not to use them.
  • Use Integrated Security
  • Encrypt passwords

Job Credentials

Default Configuration

  • The Windows Service for the JS7 Controller and Agent runs in the system account. 
    • The installer allows specification of a different account and the addition of credentials for that account. The installer does not store passwords entered during installation.
  • By default jobs are executed in the context of the account that the JS7 Agent is operated with.

Secure Configuration

  • Use of Accounts
    • It is considered a bad idea to run a JS7 Controller or Agent using a Unix root account or Windows Administrator account.
      • Certainly this makes life easy when it comes to switching to other user accounts or for accessing directories and files.
      • However,
      you
      • users should not grant more permissions to a process than required.
    • Use specific user accounts to run JS7 Controllers and Agents:
      • Do not use the system account (Windows) or root account (Unix).
      • Create specific service accounts that are limited to the privileges that are required to execute jobs.
    Do not specify credentials for Windows Service accounts during installation:
    • The installer does not store such credentials but forwards them to the Windows Service interface, however, there is no guarantee that such credentials will be logged by some Windows mechanism.
    • Instead, use the Windows Service Panel to manually specify credentials for the service account.
    • There are a number of options when it comes to running jobs for different user accounts:
      • In Unix environments:
        • Job scripts can switch to a different user context by use of sudo or su commands. sudo is the preferred option as this is the standard Unix tool
        that
        • which allows secure configuration of the
        users
      • In Windows environments:
        • You can use the Windows Credential Manager to safely store the credentials of the user account that a job should be executed for. The Agent will then read the credentials and will create a new process to run a job in the target user account's context. This is the preferred solution as it does not store credentials in the Agent or workflow configuration.
        • Find detailed information
        with the 
      • For all environments:
        • You can run a number of Agents in parallel using different user accounts.
  • Use of Credentials
    • Do not specify credentials for Windows Service accounts during installation:
      • The graphical installer stores such credentials in binary format and forwards them to the Windows Service interface. There is no guarantee that such credentials will be logged by some Windows mechanism.
      • Instead, use the Windows Service Panel to manually specify credentials for the service account.
    • A credential store can be used for jobs that require credentials,
    e.g.

File Transfer Credentials

Such credentials are intended for use with the YADE file transfer utility, which is available from built-in job templates.

...

Secure Configuration

...

Resources