Versions Compared

Key

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

Table of Contents

Introduction

  • If JOC Cockpit is installed for the high security level then deployment of workflows requires external signing.
    • For the low security level the Private Key of the root account available with the JS7 - 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.

Users have a choice how to perform signing and deployment of workflows:

Prerequisites

Required: User Signing Certificate

Each user Users with the permission to deploy has to publish his own workflows have to add their X.509 signing certificate to JOC.Signing Certificate to their profile like this:

Image Modified

Optional: Root CA Certificate

In addition a , the X.509 certificate of the CA Root CA Certificate which signed the user signing certificates were generated from 's signing certificate can be published added to JOC alsoCockpit. There is only one CA certificate a single Root CA Certificate for all user profiles.

Image Modified

  • Each user certificate has to be published to the controller/agents Any user signing certificates have to be available with the Controller instances and Agents. Certificates are stored in the config/private/trusted-x509-keys folder also sub-directory of Controller and Agent installations.
  • If a Root CA certificate Certificate is present in JOC Cockpit then it is sufficient to publish add the Root CA certificate only Certificate to the controller/agents config/private/trusted-x509-keys folder sub-directory of Controller and Agent installations.
    • No further user signing certificates are needed have to be published to the controller/agents added to Controller instances or Agents as long as they were created by the given CA.

Deploy Process Overview

  • The user has to export the desired configurations with the checkbox "forSigning" checked.
  • unpack the exported archive
    • The archive contains a meta_inf file and the configurations.
  • sign the configurations and store the signature - base64 encoded - in the same folder.
  • Each signature file has to be named the same like the original configuration with an additional filename extension.
    • for RSA/ECDSA signatures use the filename extension ".pem" or ".sig" respectively.
    • for PGP signatures use the default filename extension ".asc".
  • pack the archive again and make sure the meta_inf file is still contained in the root folder of the archive.
  • upload the archive using the Import And Deploy button.

Example

Export

  • Click on export either in the context menu of the folder you want to export or in the top right corner.
  • Image Removed
  • Check the checkbox "forSigning"
  • Image Removed
  • Select the configuration meant to deploy.

Signing

Extract the configuration with their folder structure from the archive.

Image Removed

Sign the configuration.

For this example we use OpenSSL to sign the configuration file.

Code Block
languagebash
openssl dgst -sha256 -sign c:\sp\devel\js7\keys\sos.private-ec-key.pem -out C:\sp\devel\js7\example\Example\example-wf.workflow.json.sha256 
  • -sha256
    • the signer algorithm
  • -sign c:\sp\devel\js7\keys\sos.private-ec-key.pem
    • the private key file to sign the content of the original configuration file
  • -out C:\sp\devel\js7\example\Example\example-wf.workflow.json.sha256
    • the path to the output file
    • the file contains the binary representation of the signature
  • C:\sp\devel\js7\example\Example\example-wf.workflow.json
    • the path to original configuration file
Code Block
languagebash
openssl base64 -in C:\sp\devel\js7\example\Example\example-wf.workflow.json.sha256 -out C:\sp\devel\js7\example\Example\example-wf.workflow.json.pem
  • base64
    • openssl switch to encode base64
  • -in C:\sp\devel\js7\example\Example\example-wf.workflow.json.sha256
    • the newly created binary signature file
  • -out C:\sp\devel\js7\example\Example\example-wf.workflow.json.pem
    • the base64 encoded signature text file according to the JOC deploy naming standard

Copy the newly created signature text file to the same folder like the original file.

Pack the file again or insert it into the existing archive.

The exported archive also contains a meta_inf file. This file does not need to be signed. Make sure the file is present in the root folder of the target archive.

Import/Deploy this archive with the Import And Deploy function.

Image Removed

Enter the signature algorithm using the default Java names for the signature algorithm.

Image Removed

e.g.

...

    • user signing certificates are created by the same Root CA.
    • This mechanism implies that any user signing certificate signed by the same Root CA Certificate will be accepted.
    • Users who do not wish to use this implicit mechanism should not add the Root CA Certificate to the Controller instances and Agents but should add individual user signing certificates only.

Deployment Process Overview

  • Users have to export 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 workflows using the checkbox for Signing to a .tar.gz/.zip export archive file.

    • Extracting the export archive file.
      • The export archive file includes a meta_inf file and related folders and files for workflows.
    • Signing the extracted workflow files.
    • Storing the base64 encoded signature file for each workflow file in same folder.
    • Note that each signature file has to use the same name as the original workflow with an additional file extension.
      • for X.509 RSA/ECDSA signature files use the file extension .sig.
      • for PGP signature files use the file extension .asc.
    • Adding signature files to a .tar.gz/.zip import archive file. This includes that the meta_inf file is available in the top-level folder of the import archive file.
    • Uploading the import archive file using the Import and Deploy button available from the JOC Cockpit's Configuration view..

Resources

...