Additional configuration

Apart from the basic configuration you can make custom configurations in the sample deployment configuration file by editing the property settings of the respective sections as described in the examples below.

Ports

For configuring the port of CAQ endpoints update the following section of the configuration file:

server:
  port: <custom_port>

Configuring TLS

You can enable HTTPs in CAQ endpoints by configuring one of the following options:

One-way TLS

For enabling one-way TLS configuration, apply the below part to the configuration file:

server:
  ssl:
    enabled: true
    key-store: file:<path_to_file>/server-keystore.p12
    key-store-password: changeit
    key-store-type: PKCS12

Two-way TLS

For enabling two-way/mutual (with client certificates) TLS configuration, apply the below part to the configuration file:

server:
  ssl:
    enabled: true
    key-store: file:<path_to_file>/server-keystore.p12
    key-store-password: changeit
    key-store-type: PKCS12
    trust-store-type: JKS
    trust-store: file:<path_to_file>/server-truststore.jks
    trust-store-password: changeit
    client-auth: need

Advanced configurations

Advanced configurations

You can define a set of ciphers based on the key used, like the server.ssl.ciphers property.

In general, for the client auth the value need is used for mutually authenticated transport layer security and in that case application level authentication.type may be set to none.

Possible client auth values are:

need: Client authentication is needed and mandatory.

want: Client authentication is wanted but not mandatory.

none: Client authentication is not wanted, like one-way TLS.

For more advanced configurations please contact Customer Support.

note

Although the property's name is server.ssl, the default ssl protocol used is TLS.

Logging

The CAQ is bootstrapped with the logging enabled on WARN level at the console and the audit logging disabled. For updating the level of logs or enabling the audit logging, locate the logging section in the deployment configuration file and update it with the appropriate changes.

Enabling/Disabling audit logging

A configuration for audit logging is provided in the sample deployment configuration file. By default, it is disabled:

Audit logging disabled

logging:
  level:
    root: WARN
    com:
      axiomatics:
        audit: OFF

Audit logging disabled

Audit logging enabled

To enable audit logging in the sample deployment configuration file use the following:

logging: 
  level: 
    root: WARN 
    com: 
      axiomatics: 
        audit: INFO

Audit logging enabled

Extended logging configurations

For applying more complex logging related changes, such as updating the additivity property or the log format, you should use the Logback documentationOpens in a new tab to create a custom logback.xml file and apply the corresponding changes.

Add the following configuration to the deployment.yml file that the application is using:

logging:
  config: <path_to_file>/logback.xml

Further examples of logging configurations are available in the section below:

Logging configuration samples

For your convenience, some logback related settings for several modes of audit logging in CAQ are provided below.

Admin events

Admin events

For enabling the audit events and logging only the administrative events to a file named caq-admin-event.log, use the following part to the deployment file:

logging:
  config: <path_to_file>/logbackAdmin.xml
  level:
    com:
      axiomatics:
         audit: INFO

Eval events

Eval events

For enabling the audit events and logging only the evaluation events to a file named caq-eval-event.log, use the following part to the deployment file:

logging:
  config: <path_to_file>/logbackEval.xml
  level:
    com:
      axiomatics:
         audit: INFO

Both events to one single file

Both events to one single file

For enabling the audit events and logging both administrative and evaluation events to a file named caq-audit.log, use the following part to the deployment file:

logging:
  config: <path_to_file>/logbackBothAdminEval.xml
  level:
    com:
      axiomatics:
        audit: INFO

Both events to two separate files

Both events to two separate files

For enabling the audit events and logging both administrative and evaluation events to separate files named caq-admin.logand caq-eval.log respectively, use the following part to the deployment file:

logging:
  config: <path_to_file>/logbackSeparateAdminEval.xml
  level:
    com:
      axiomatics:
        audit: INFO

JSON format to console

JSON format to console

For enabling JSON format to console for all the logs:

logging:
  config: <path_to_file>/logbackJSON.xml
  level:
    root: INFO
    com:
      axiomatics:
        audit: INFO

For the detailed logging samples please refer to the Logback samples.

Conditional requests when polling a domain name using HTTP(S)

When Contextual Authorization Query retrieves a domain by name from ADM using an HTTP(S) endpoint, it sends conditional requests to indicate to the authorization domain server which authorization domain(s) it is already in possession of.

To do so, CAQ uses a header called "If-None-Match". The value of this header is the same as the "ETag" header value (entity tag) that CAQ received in the previous ADM response. When a "ETag" header has been received, CAQ will send the next request including the "If-None-Match" field with the value of the entity tag for the authorization domain present in CAQ.

If the "If-None-Match" and "ETag" values match, it means that authorization domain has not changed from the domain currently pointed to by the domain name. The authorization domain server can indicate this to CAQ in its response (using the "304 (Not Modified)" status code) and avoid including a complete representation of the domain in the response, thus reducing network load.

However, during a fresh start of the service, CAQ only performs the GET operation and looks for an "ETag" in the response. The server may or may not include the "ETag".

This implementation is compliant with IETF RFC 7232, §3.2Opens in a new tab, which delineates the name and semantics of the header information that clients must use for an "If-None-Match" header field, and IETF RFC 7232, §4.1Opens in a new tab, which describes the definition of the "304 (Not Modified)" status code and header information the authorization domain server will use in its response if the representation has not changed since the previous request.