Page History

...

• HTTPS Server Authentication is preferably used in combination with Client Authentication (mutual authentication) as this allows a secure configuration without the use of passwords.
  • The purpose of Server Authentication is to secure the identity of an HTTP server and to encrypt the communication between client and server.
  • The purpose of Client Authentication is to prove the identity of a client. Without proof of identity any http client could perform a man-in-the-middle attack e.g. by pretending to be a Controller that connects to an Agent.
• Consider the communication scheme between JS7 components as explained from in the JS7 - System Architecture article:
  
  • User browsers acting as HTTP clients establish connections to the JOC Cockpit as an HTTP server.
  • The JOC Cockpit acting as an HTTP client establishes connections to Controller instances acting as HTTP servers.
  • Controller instances acting as HTTP clients establish connections to Agents acting as HTTP servers.

...

• The configuration file is located with in the sos-berlin.com/js7/controller/config/private folder.
• Consider Note that the above configuration has to be deployed to both Controller instances should if a Controller Cluster be is being used.
• Find below explanations about The configuration items from the above example relevant to mutual authentication from the example above are described below.

Authentication with pairing Controller instances and JOC Cockpit instances

...

js7 {
    auth {
        # User accounts for HTTPS connections
        users {
            # Controller ID for connections by primary/secondary controller instance
            Controller {
                distinguished-names=[
                    "DNQ=SOS CA, CN=controller-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
                ]
            }
        }
    }
}

Explanation:

• This The setting listed above applies if for a Controller Cluster is used. In this situation a Primary Controller requires the above setting to allow access from a Secondary Controller and vice versa.
• Consider Note that the Controller element name Controller name is an example that has to be replaced by the Controller ID that is specified with the same value during installation of both Controller instances in a cluster.
• This setting specifies the distinguished-names indicated with the partner Controllers' Client Authentication certificate. The distinguished name is given with the subject attribute of a Client Authentication certificate. The distinguished name is considered a replacement for a password.
  • A Primary Controller configuration specifies the distinguished name of the Secondary Controller's Client Authentication certificate.
  • A Secondary Controller configuration specifies the distinguished name of the Primary Controller's Client Authentication certificate.
  • Consider Note that the common name (CN) attribute of the distinguished name has to match the fully qualified domain name (FQDN) of the partner Controller's host.

...

js7 {
    auth {
        # User accounts for HTTPS connections
        users {
            # History account (used to release events)
            History {
                distinguished-names=[
                    "DNQ=SOS CA, CN=joc-2-0-primary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE",
                    "DNQ=SOS CA, CN=joc-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
                ]
                password="sha512:B793649879D61613FD3F711B68F7FF3DB19F2FE2D2C136E8523ABC87612219D5AECB4A09035AD88D544E227400A0A56F02BC990CF0D4CB348F8413DE00BCBF08"
            }
            # JOC account (requires UpdateRepo permission for deployment)
            JOC {
                distinguished-names=[
                    "DNQ=SOS CA, CN=joc-2-0-primary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE",
                    "DNQ=SOS CA, CN=joc-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
                ]
                password="sha512:3662FD6BF84C6B8385FC15F66A137AB75C755147A81CC7AE64092BFE8A18723A7C049D459AB35C059B78FD6028BB61DCFC55801AE3894D2B52401643F17A07FE"
                permissions=[
                    UpdateItem
                ]
            }
        }
    }
}

Explanation:

• This The setting listed above applies to for the connection established from one or more JOC Cockpit instances to a Controller. The JOC Cockpit can be used with as a cluster including comprising two or more instances.
• This setting specifies the distinguished-names indicated with the respective relevant JOC Cockpit's Client Authentication certificate. The certificate is considered a replacement for a password. For each JOC Cockpit instance, the distinguished name is specified that which is stated with in the JOC Cockpit's certificate.
• Two entries are available for js7.auth.users.History and js7.auth.users.JOC:
  • History represents the JS7 - History Service that receives state transition events for orders and log output of jobs and adds them to the JS7 database.
  • JOC represents the JOC Cockpit Proxy Service that establishes the connection to a Controller and that which is used to provide current information about orders to the JOC Cockpit GUI. In , in addition to e.g. , for examplethe deployment of workflows and submission of orders.
  • For both History and JOC services a hashed password is specified by the JOC Cockpit. The password has no relevance for the security of the connection, instead . Instead it is used to distinguish the services that both are running with the same JOC Cockpit instance and therefore use the same Client Authentication certificate.
• In addition permissions are specified for JOC Cockpit services that indicate with the UpdateItem setting that the JOC Cockpit service is allowed to add/update/delete deployable objects such as workflows.

...

• The Controller verifies the signature of deployable objects such as workflows. This can be performed for PGP signatures and X.509 signatures. 
• The trusted-signature-keys setting specifies the location locations for PGP public keys and for X.509 certificates.
• If no either PGP public keys are used or if no X.509 certificates are not used then the respective relevant setting should not be used specified as it expects implies that the indicated directory to will be populated with public keys or certificates respectivelyaccordingly.

Services entitled to release the Controller Journal

...

• The journal holds e.g. information about order state transitions. This information is consumed by the JS7 - History Service that updates the JS7 database from this information.
• The Controller's journal would grow if entries that have been consumed by the History Service could not be released. The users-allowed-to-release-events setting specifies the names, e.g. History, of the accounts for which authentication settings are indicated from the js7.auth.users section.
• For use A single History account is used with any number of JOC Cockpit instances a single account History is used. Should . If more than one consumer account was to be specified then all consumers would have to confirm having received order transition events before such events can could be removed from the journal.

...

js7 {
    web {
        # keystore and truststore location for https connections
        https {
            client-keystore {
                # Default: ${js7.config-directory}"/private/https-client-keystore.p12"
                file=${js7.config-directory}"/private/https-client-keystore.p12"
                key-password=jobscheduler
                store-password=jobscheduler
            }
            keystore {
                # Default: ${js7.config-directory}"/private/https-keystore.p12"
                file=${js7.config-directory}"/private/https-keystore.p12"
                key-password=jobscheduler
                store-password=jobscheduler
            }
            truststores=[
                {
                    # Default: ${js7.config-directory}"/private/https-truststore.p12"
                    file=${js7.config-directory}"/private/https-truststore.p12"
                    store-password=jobscheduler
                }
            ]
        }
    }
}

Explanation:

• HTTPS keystore keystores and truststore truststores are used to hold private keys and certificates
  • The A keystore holds the Controller instance's private key and certificate. This information is used for:
    • Server Authentication with JOC Cockpit and for
    • Client Authentication with Agents.
  • The A truststore holds the certificate(s) used to verify:
    • Client Authentication certificates presented by JOC Cockpit and
    • Server Authentication certificates presented by Agents.
• Optionally a separate HTTPS client keystore can be used:
  • The client keystore is used for HTTPS mutual authentication and holds a private key and certificate created for the Client Auth extended key usage Client Auth. 
  • When using HTTPS mutual authentication then:
    • a single certificate can be used that is generated for both extended key usages Server Auth and Client Auth extended key usages. In this case do not use the HTTPS client keystore but use the HTTPS keystore to hold the certificate.
    • separate certificates can be used with the certificate for key usage for Server Auth being key usage being stored with in the HTTPS keystore and the certificate for Client Auth key usage Client Auth being stored with in the HTTPS client keystore.
  • For details see 

    Jira
    server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JS-1959

• Keystore and Truststore locations are specified. In addition for:
  • the keystore a password for the private keys included in the keystore and a password for access to the keystore can be specified,
  • the truststore a password for access to the truststore can be specified.
• Passwords for keystores and truststores have no tendency do not tend to improve security of the configuration security: the passwords have to be specified as plain text and have to be in reach of the Controller. This mechanism is not too different from hiding the key under your doormat. In fact limiting ownership and access permissions for keystore and truststore files to the JS7 Controller's run-time account are more important than using a password.
  • The key-password setting is used for access to a private key in a keystore.
  • The store-password setting is used for access to a keystore or to a truststore.
  • For PKCS12 (*.p12) keystores both settings have to use the same value. The settings can be omitted if no passwords are used.

...

• The configuration file is located with in the sos-berlin.com/js7/agent/config_<port>/private folder.
• Consider Note that the Controller element name Controller is name is an example that has to be replaced by the Controller ID that which is specified with the same value during installation of both Controller instances in a cluster.
• Consider Note that the above configuration has to be deployed to any all Agent instances.
• Find below explanations about above The configuration items relevant to mutual authentication from the example above are described below.

Client Authentication

Controller Connections

For explanations see see the JS7 - Agent Configuration Items#js7-auth-users-Controller article.

js7 {
    auth {
        # User accounts for https connections
        users {
            # Controller ID for connections by primary/secondary Controller instance
            Controller {
                distinguished-names=[
                    "DNQ=SOS CA, CN=controller-2-0-primary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE",
                    "DNQ=SOS CA, CN=controller-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
                ]
            }
        }
    }
}

...

HTTPS Keystore and Truststore Locations

For explanations see See the JS7 - Agent Configuration Items#js7-web-https-keystore article for a explanation of the setting.

js7 {
    web {
        # keystore and truststore location for https connections
        https {
            keystore {
                # Default: ${js7.config-directory}"/private/https-keystore.p12"
                file=${js7.config-directory}"/private/https-keystore.p12"
                key-password=jobscheduler
                store-password=jobscheduler
            }
            truststores=[
                {
                    # Default: ${js7.config-directory}"/private/https-truststore.p12"
                    file=${js7.config-directory}"/private/https-truststore.p12"
                    store-password=jobscheduler
                }
            ]
        }
    }
}

...

Locations of Public Keys and Certificates for Signature Verification

For explanations see See the JS7 - Agent Configuration Items#js7-configuration-trusted-signature-keys article for a explanation of the setting.

# Security configuration
js7 {
    configuration {
        # Locations of certificates and public keys used for signature verification
        trusted-signature-keys {
            PGP=${js7.config-directory}"/private/trusted-pgp-keys"
            X509=${js7.config-directory}"/private/trusted-x509-keys"
        }
    }

Script Execution from Signed Workflows

For explanations see See the JS7 - Agent Configuration Items#js7-job-execution-signed-script-injection-allowed article for a explanation of the setting.

# Allow http connections without authentication
js7.job.execution.signed-script-injection-allowed = yes

...