Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Introduction

  • When If JOC Cockpit is installed for a the high security level then deployment of scheduling objects forces workflows requires external signing.
    • For the low security level the private key of the root account available with the the JS7 database - Database is used for all users.
    • For the medium security level the user's individual private key available with the JS7 database is used.
    • For the high security level signing is performed outside of JOC Cockpit. No private keys are stored with JOC Cockpit and the JS7 database.
  • For details see JS7 - Security Architecture.

Prerequisites

Required: User Signing Certificate

Each user with the permission to deploy workflows has to add their X.509 signing certificate to JOC Cockpittheir profile like this:

Image Modified

Optional: Root CA Certificate

In addition, the X.509 certificate of the Root CA Certificate which signed the user's signing certificate can be added to JOC Cockpit. There is a single Root CA certificate Certificate for all user profiles.

Image Modified

  • Any user signing certificates have to be rolled out to available with the Controller instances and Agents. Certificates are stored in the the config/private/trusted-x509-keys folder sub-directory of Controller and Agent installations.
  • If a Root CA certificate Certificate is present in JOC Cockpit , then it is sufficient to add the Root CA certificate Certificate to the the config/private/trusted-x509-keys folder of  sub-directory of Controller and Agent installations.
    • No further user signing certificates have to be added to the Controller instances or Agents as long as the user signing certificates is are created by the given same Root CA.
    • This mechanism implies that any user signing certificate signed by the same Root CA certificate Certificate will be accepted.
    • Users who do not wish to use this implicit mechanism should not add the Root CA certificate Certificate to the Controller instances and Agents but should only add individual user signing certificates only.

Deployment Process Overview

  • The user has Users have to export the desired configuration of scheduling objects with workflows using the Export operation available from the JOC Cockpit's Configuration view.

    • Other deployable objects such as File Order Sources, Job Resources, Notice Boards, Resource Locks etc. do not require signing.
    • Releasable objects that are not digitally signed include Calendars, Schedules, Script Includes, Job Templates etc.
  • Deployment tasks include:
    • Exporting scheduling objects with workflows using the checkbox "for Signing" checked to an to a .tar.gz/.zip export archive file (.zip).

    • Unpacking Extracting the exported export archive file.
      • The export archive contains file includes a meta_inf file and the configurationsrelated folders and files for workflows.
    • Signing the extracted workflow files.
    • Storing the base64 encoded signature file for each workflow file in configuration files of scheduling objects and storing the signature - base64 encoded - in a file in the same folder.
    • Note that each signature file has to use the same name as the original configuration file of the scheduling object workflow with an additional filename file extension.
      • for X.509 RSA/ECDSA signatures signature files use the filename file extension " .pem" or ".sig" respectively.
      • for PGP signatures PGP signature files use the default filename file extension " .asc".
    • Packing the archive once again to add the signature files and make sure Adding signature files to a .tar.gz/.zip import archive file. This includes that the meta_inf file is still available with in the root top-level folder of the import archive file.
    • Uploading the import archive file using the Import And and Deploy button available from the JOC Cockpit's Configuration view..

Example for Deployment Process

Export

  • Click Export in in the context menu of the a folder to export or from use the Export button in the top right upper corner of the Configuration view:



  • In the Export popup window check the checkbox for Signing:



  • Select the scheduling objects workflows to deploy.

Signing

It is recommended essential that the signing procedure is performed on a secure device . It is essential that the signing process is performed and in a secure manner outside of the server running the host operating JOC Cockpit.

Extract the configuration from the archive and preserve export archive file and preserve the folder structure of the included scheduling object workflow files:


Signing Workflow Files

This example makes use of the configurationFor this example, we use OpenSSL to sign the configuration filea workflow file in two steps:

Code Block
languagebash
titleStep 1: Create binary signature file from signing a workflow file
openssl dgst -sha256 -sign c:\tmp\sos.private-ec-key.pem -out c:\tmp\example-wf.workflow.json.sha256sig.bin c:\tmp\example-wf.workflow.json
  • -sha256
    • the signer algorithm
  • -sign c:\tmp\sos.private-ec-key.pem
    • the private key file used to sign the content of the original configuration workflow file
  • -out c:\tmp\example-wf.workflow.json.sha256sig.bin
    • the path to the output file that contains the file containing the binary representation of the signature
  • c:\tmp\example-wf.workflow.json
    • the path to the original scheduling object file (in this example: workflow)workflow file.


Code Block
languagebash
titleStep 2: Convert binary signature file to base64 encoding
openssl base64 -in c:\tmp\example-wf.workflow.json.sha256sig.bin -out c:\tmp\example-wf.workflow.json.pemsig
  • base64
    • OpenSSL switch to encode base64to transform the signature file from binary encoding to base64 encoding
  • -in c:\tmp\example-wf.workflow.json.sig.sha256bin
    • the newly created binary encoded signature file as created in step 1)
  • -out c:\tmp\example-wf.workflow.json.pemsig
    • the base64 encoded text signature file according to the JOC Cockpit deployment naming conventionto be created that carries a .sig extension and that will be picked up later on by JOC Cockpit when importing workflows and signatures.

The procedure for adding scheduling object workflow files and signatures signature files to an import archive includes the following steps:

  • Copying the newly created text base64 encoded signature files have to be available in the same folders folder as the scheduling object files.workflow file.
  • Creating a .tar.gz/.zip import archive file that includes the workflow files and signature filesPacking the archive once again or adding the signature files to the existing archive.
    • The exported archive contains the meta_inf file. This file does not have to be signed. Make sure the file is However, it should be present in the root top-level folder of the target import archive file.
  • Importing /Deploying this archive with and deploying the archive file using the Import And and Deploy function operation of JOC Cockpit.



Enter the signature signing algorithm using the default Java names for the signature algorithm:


Supported signature signing algorithm names include:

OpenSSLJava with RSAJava with ECDSA
sha512SHA512withRSA-
sha256SHA256withRSASHA256withECDSA


During import, the scheduling object configuration any workflow files and the signature files from the import archive file will be forwarded to the Controller and will be validateddeployed to Controller instances & Agents. This includes validation by Controller instances and Agents independently. After successful validation by the Controller and by the Agent the scheduling object is deployedthe workflows will be available in a deployed state that is ready to accept orders for workflow execution.