Page History

...

• Configure network connections to use HTTPS:
  • Use of HTTPS includes providing valid certificates for the hosts that JS7 components are operated for. Use of self-signed certificates is not recommended as they cannot be verified to a trusted source.
  • 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:
    • JS7 - JOC Cockpit HTTPS Connections, which explains HTTPS configuration for the JOC Cockpit and connection to the JS7 Controller.
    • JS7 - Controller HTTPS Connections
    • JS7 - Agent HTTPS Connections
• Restrict use of network interfaces:
  • Consider restricting JS7 components to only listen to specific network interfaces.
  • The JS7 Controller can be configured by use of the --http_port and --https_port command line options to specify network interfaces, see the JS7 - Controller - Command Line Operation article for details.
    
  • The JS7 Agent can be configured by use of the --http-port and --https-port options to specify network interfaces, see JS7 - Agent Command Line Operation.
  • The JOC Cockpit can be similarly configured to only use specific network interfaces, see:
    • JS7 - JOC Cockpit Configuration for Docker Containers
    • JS7 - JOC Cockpit Configuration Items

...

• Depending on the DBMS version in use it is preferable to download and 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 users have to download a current JDBC Driver from the vendor's site.
  • For use with Oracle® newer JDBC Driver versions might be available from the vendor's web site.
• Vendor-specific JDBC Drivers include support for specific authentication mechanisms. For example
  • the use of JDBC with Oracle Wallet, see JS7 - How to make JOC Cockpit connect to an Oracle database using Wallet®,
  • the use of JDBC with Integrated Security, see JS7 - How to connect to an SQL Server database without using passwords.
• Consider additional security related settings that apply to your DBMS in the Hibernate configuration file. For the location of this file see the JS7 - Database article.

...

• Refer to the hints provided in the JS7 - JOC Cockpit - Secure Operation article.
• The JS7 - REST Web Service API ships with a default configuration in ./joc/resources/joc/shiro.ini The JOC Cockpit by default ships with the JOC-INITIAL Identity Service, see JS7 - Identity Services which includes:
  
  • use of local the JS7 - JOC Identity Service for authentication with user accounts and passwords stored as hash values in the JS7 - Database.
  • use of local role assignment,
  • the following default values for user accounts, passwords 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

• 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 by symmetric 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 which holds the password setting optionally by default as a hashed value.
  • It is recommended that certificate JS7 - Certificate based authentication 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.
• LDAP Directory Services should The JS7 - LDAP Identity Service should be used whenever possible to establish role assignment for users based on membership in LDAP Directory Service security groups.

LDAP Directory Service

...

• LDAP Directory Service integration is available from the JS7 - LDAP Identity Service, but is not in placeactive.
• Using the default configuration with local authentication from the JS7 - JOC Identity Service for access to the JOC Cockpit is not recommended.

...

• LDAP 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 for any LDAP compliant product such as Microsoft Active Directory®, OpenLDAP etc.
• For details about LDAP support see the JS7 - LDAP Identity Service article.

...

• 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 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 that makes use of it. Encrypted passwords correspond to the "key under the mat". They do not provide additional security. However, they contribute perfectly to obfuscation.
  • There is one way only how to securely handle passwords: do not use them.
• Use Integrated Security
  • This authentication scheme is based on the fact that the account which a component is operated for has already been authenticated and therefore can access a database without specifying user/password credentials.
  • This feature is available for a number of DBMS such as:
    • Microsoft SQL Server®, see the JS7 - How to connect to an SQL Server database without using passwords article.
    • Oracle® including support for Oracle® Wallet, see the JS7 - How to make JOC Cockpit connect to an Oracle database using Wallet® article.

Job Credentials

Default Configuration

...

• 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 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 which allows secure configuration of the users accounts that are allowed to execute certain commands (sudoers file). In addition sudo provides reporting capabilities about the (ab)use of commands.
  • 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 JS7 - Running Jobs as a different User article.
  • For all environments:
    • You can run a number of Agents in parallel using different user accounts.
• A credential store can be used for jobs that require credentials, e.g. for example to access a database: see the JS7 - Credential Store article for more information.
  • Credentials are not provided from parameters (that could be logged in clear text), instead an interface is provided that allows on demand access to the credential store. 
  • This feature is available for Shell jobs and for JVM jobs, for example JS7 - JITL Database Jobs, JS7 - JITL SSH Jobs etc.

File Transfer Credentials

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

...

• By default any accounts/passwords that are used for source connections, target connections and proxy connections are stored in clear text.
• See the YADE - Reference Documentation - Parameter Reference for more information.

Secure Configuration

• Use the YADE Credential Store to manage credentials centrally in a store which is referenced by YADE configuration items. See the How to set-up the Credential Store and YADE Parameter Reference - CredentialStoreFragment articles for more information.
• Should you use FTP connections then consider switching to using SFTP.
• SFTP connections can be used with private/public key files - there is no need to use passwords for such connections.

...