Page History
...
- All network connections make use of HTTP:
- Connections by users to the JS7 - Browser User Interface
- Connections by the PowerShell CLI to the JS7 - REST Web Service API
- Connections by the JOC Cockpit REST Web Service API to the JS7 Controller
- Connections by the JS7 Controller 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 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 are operated for. Use of self-signed certificates is a no-go as they cannot be verified to a trusted source.
- As HTTPS is limited to secure connections, additional authentication is required, for example, when using HTTPS. 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.
- JS7 - Secure Connections explains the use of the built-in certificate authority and use with external certificate authorities.
- For detailed instructions for the configuration see:
- JS7 - JOC Cockpit Configuration ItemsHTTPS Connections explains HTTPS configuration for the JOC Cockpit and connection to the JS7 Controller.
- JS7 - Controller Configuration ItemsHTTPS Connections
- JS7 - Agent Configuration ItemsHTTPS 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 JS7 - Controller - Command Line Operation. - The JS7 Agent can be configured to use the
--http-port
and--https-port
options to specify network interfaces, see JS7 - Agent Command Line Operation. - JOC Cockpit has to be configured with corresponding port settings:
...
- JS7 ships with JDBC Drivers that are open source or that are free for distribution with JS7.
- The JOC Cockpit installer allows
- specifcation of to specify alternative JDBC Drivers that can be downloaded from the relevant vendor's web site.
- specifcation ofindividual to specify individual Hibernate configuration files with security related settings.
- For details see JS7 - Database.
...
- Consider the hints provided in the JS7 - JOC Cockpit - Security articleSecure Operation article
- The 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.
- use of local role assignment,
- the following default values for accounts, passwords and assigned roles (see JOC Cockpit - Authentication and Authorization for more information):
- Active Accounts:
root=root, all
- Deactivated Accounts (passwords are presented in plain text and are hashed in the
shiro.ini
configuration file:# administrator=secret, administrator
# application_manager=secret, application_manager
# it_operator=secret, it_operator
# incident_manager=secret, incident_manager
# business_user=secret, business_user
# api_user=secret, api_user
- Active Accounts:
- The JS7 Controller is not accessed by users directly but exclusively via the JS7 - REST Web Service API.
- Default authentication
- for the connection from JOC Cockpit to the Controller is provided from symmetric passwords available with
- the JOC Cockpit Settings page with the settings
controller_connection_joc_password
andcontroller_connection_history_password,
- the Controller's
private.conf
file that holds thepassword
setting optionally as a hashed value.
- the JOC Cockpit Settings page with the settings
- It is recommended to use certificate based authentication by HTTPS connections with mutual authentication, see JS7 - Controller HTTPS Connections.
- JS7 Agents are not accessed by users directly but exclusively by a JS7 Controller. Default authentication is not provided.
...
- Using the default accounts that ship with JOC Cockpit is not recommended. The default accounts are intended to enable initial login only.
- A fine-grained set of permissions is available that can be applied to any operation in JOC Cockpit and in the REST Web Service. Such permissions can freely be grouped to roles.
- LDAP Directory Services should be used when ever possible to establish role assignment for users based on membership in LDAP security groups.
- For the connection from JOC Cockpit to Controllers certificate based authentication by HTTPS connections with mutual authentication should be used, see JS7 - Controller HTTPS Connections.
LDAP Directory Service
Default Configuration
...
- Database credentials are specified during installation and are added to the following Hibernate configuration files:
- JOC Cockpit: for access to the reporting database:
.JETTY_BASE/resources/joc/reporting.hibernate.cfg.xml
- For details see JS7 - Database.
- JOC Cockpit: for access to the reporting database:
- 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 perfectly contribute perfectly to obfuscation.
- There is one way only how to handle passwords: not to use them.
- Use Integrated Security
- This authentication scheme is based on the fact that the account which that a component is operated for is already 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 How to connect to an SQL Server with a domain account article.
- Oracle® that includes support for Oracle® Wallet, see see the JS7 - How to connect to an Oracle database without using passwords article.
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.
- By default jobs are executed in the context of the account that the JS7 Controller or JS7 Agent are is operated with.
Secure Configuration
- It is 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 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 (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
- Your job scripts can switch to a different user context by use of
sudo
orsu
commands.sudo
is the preferred option as this the standard Unix tool that allows secure configuration of the users that are allowed to execute certain commands (sudoers
file). In additionsudo
provides reporting capabilities about (ab)use of commands.
- Your job scripts can switch to a different user context by use of
- In Windows environments
- You can use the Windows Credential Manager to safely store credentials of the user account that a job should be executed for. The JobScheduler will then read the credentials and create a new process to run a job in the target user context. This is the preferred solution as it does not store credentials in the JobScheduler configuration.
- You will find detailed information in the JobScheduler Universal Agent - Running jobs as a different user article.
- For all environments
- You can run a number of Agents in parallel using different user accounts.For details see the JS7 Installation: How to install the JS7 Agent on premises using the Windows Graphical Installer article.
- In Unix environments
- A credential store can be used for jobs that require credentials, e.g. to access a database: see the Using a JS7 - Credential Store for Jobs article 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.
...
Overview
Content Tools