Skip to main content
Version: 1.1

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:

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
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:

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

    Audit logging disabled

    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​

    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

    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.