Page History

...

• 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).
  
  • The JS7 - LDAP Identity Service
   should
  • can be used
  whenever possible
  • to establish role assignment for users based on membership in LDAP Directory Service security groups.
  • The JS7 - Certificate Identity Service and JS7 - FIDO2 Identity Service can be used for MFA.

LDAP Directory Service

Default Configuration

• LDAP Directory Service integration is available from the JS7 - LDAP Identity Service, but is not active by default.
• Using the default configuration with local authentication from the JS7 - JOC Identity Service for access to the JOC Cockpit is not recommended as it stores hashed passwords in the database.

Secure Configuration

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

...

• 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 passwords correspond to the "key under the mat". They do not provide additional security. However, they perfectly contribute perfectly to obfuscation.
  • There is one way only how to securely handle passwords: do 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.

...

• 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 graphical installer does not store stores such credentials but in binary format and forwards them to the Windows Service interface. However, there 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 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 with the from the JS7 - Running Jobs as a different User on Windows 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, 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 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 use of SFTP.
• SFTP connections can be used with private/public key files - there is no need to use passwords for such connections.

...