Product Knowledge Base

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Scope

  • The connection from the user's browser or any REST client to the JOC Cockpit can be secured by HTTPS. This includes that a client validates the JOC Cockpit SSL certificate for server authentication.
  • In addition the JOC Cockpit can be configured for mutual authentication, requiring in addition the client to present a certificate that is validated by the JOC Cockpit.
  • This article describes the steps required to set up secure JOC Cockpit for two-factor authentication including SSL mutual authentication and password authentication. For login to JOC Cockpit a client, i.e. a user browser or REST client,
    • is required to hold a certificate stored with the client's device that is validated by JOC Cockpit and
    • is required to specify a password.

Prerequisites

JOC Cockpit Configuration

JETTY_BASE is Jetty's base directory which is specified during the JOC Cockpit installation:

  • C:\ProgramData\sos-berlin.com\joc (default on Windows)
  • /home/<setup-user>/sos-berlin.com/joc (default on Linux)

Add the following entries to the JETTY_BASE/start.ini configuration file:

Add HTTPS mutual authentication to Jetty
## force use of client authentication certificates
jetty.sslContext.needClientAuth=true
jetty.sslContext.wantClientAuth=true
jetty.sslContext.endpointIdentificationAlgorithm=

Hints

Certificate Management

Mutual authentication is based on X509 compliant certificates. Self-signed certificates and CA signed certificates can be used.

Certificate Management with the JOC Cockpit

JOC Cockpit hold a certificate that allows validation of the clients' certificate in its truststore. The location of the Jetty truststore is specified with the JETTY_BASE/start.ini configuration file.

  • Self-signed Certificates
    • JOC Cockpit holds the client's certificate in its truststore. 
    • Each client's individual certificate is required to be in place.
  • CA signed Certificates
    • JOC Cockpit holds the CA certificate, i.e. the root certificate/intermediate certificate(s), in its truststore.
    • Connections from any clients that use a certificate signed by the CA will be accepted.
    • This approach is more flexible as it does not require to modify the Jetty truststore when adding/removing clients.

Certificate Management with the Client

The client holds its private key and certificate in its keystore. 

  • The private key is created by the client when generating a key pair for a self-signed certificate and respectively when creating a certificate signing request (CSR) for its CA.
  • For CA signed certificates the client's certificate store includes the certificate chain, i.e. client certificate and root certificate/intermediate certificate(s) that have been used to sign the client's certificate.
  • Frequently private key and certificate(s) are stored in a PKCS12 keystore that comes with a .pfx or .p12 file extension. However, other file formats for private key and certificate(s) are available.
  • The clients' keystore has to be imported into the client's certificate store. The location of the certificate store depends on the client application that is used to access JOC Cockpit:
    • The Internet Explorer, Edge and Chrome browsers are reported to use the Windows certificate store.
    • The FireFox browser makes use of its own certificate store.
    • REST clients implemented with programming languages or scripting languages follow individual approaches to manage a certificate store.

The JobScheduler PowerShell Modules for JobScheduler 1.x and for JobScheduler 2 (JS7) both support to specify client certificates from keystores and from the operating system certificate store.




  • No labels