Page History

...

• All network connections make use of HTTP:
  • Connections by users to the JS7 - Browser User Interface
  • Connections by the Unix Shell ClI and 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 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.

...

• Refer to the hints provided in the JS7 - JOC Cockpit - Secure Operation article.
• The JOC Cockpit by default ships with the JOC-INITIAL Identity Service, see JS7 - Identity Services which includes:
  
  • use of 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 account, password and assigned roles (see JS7 - Manage User Accounts for more information):
    • Active User Account:
      • user account: root
      • password: root
        • Users are required to modify the initial password on first login.
    • Active Role:
      • all
    • Available Roles:

      • administrator

      • all

      • api_user

      • application_manager

      • business_user

      • incident_manager

      • 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 by asymmetric passwords available with:
    • the 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 by default as a hashed value.
  • It is recommended 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.

...

Secure Configuration

• 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 product that makes use of it. Encrypted passwords correspond to the "key under the mat". They do not provide additional security. However, they perfectly contribute to obfuscation.
  • There is one way only how to securely handle passwords: not to use them.
• Use Integrated Security
  • This authentication scheme is based on the fact that the account which a product 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.
• Encrypt passwords
  • For details see Users can encrypt database credentials from assymetric keys, for details see JS7 - How to encrypt and decrypt Database Credentials. 

...

• 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, 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.
  • 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 accounts that are allowed to execute certain commands (sudoers file). In addition sudo provides reporting capabilities about the (ab)use of commands.
      • Find details from the JS7 - Running Jobs as a different User on Unix article.
    • 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 from the JS7 - Running Jobs as a different User on Windows article.
    • For all environments:
      • You can run a number of Agents Agent instances 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, 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.
  • Use the the feature of JS7 - Encryption and Decryption, for encryption of order variables and job arguments see JS7 - Encryption - Integration with Workflows - Jobs - Orders

...