Additional customization of the Liberty server for CC CAT

Substitute server.env CC CAT parameters

Adjust the server.env section for CC CAT. In particular, pay attention to the following parameters:

configDropins for CC CAT

CC CAT needs cat-core.xml and cat-api.xml. The easiest way to enable them is by creating symbolic links to the corresponding files in the ${SERVER_INSTALL_DIR}/configDropins/options/ folder.

cd ${WLP_USER_DIR}/servers/${SERVER_STC_NAME}
ln -s ${SERVER_INSTALL_DIR}/configDropins/options/cat-core.xml configDropins/overrides/cat-core.xml
ln -s ${SERVER_INSTALL_DIR}/configDropins/options/cat-api.xml configDropins/overrides/cat-api.xml

Setup of mTLS (optional)

Using mTLS it is possible for a client to utilize APIs using a certificate. The certificate presented in the TLS handshake maps to a RACF user ID which is then authorized to resources in the same manner as a client from a browser.

The Liberty server supports mTLS in 2 ways:

1. You can enable mTLS for ALL communications, so that each user MUST present a trusted certificate when accessing the server via a browser on port https.port. To configure that, set TLS_CLIENT_AUTHENTICATION=true in server.env
2. You can enable mTLS support without requiring it. To configure that, set TLS_CLIENT_AUTHENTICATION=false and TLS_CLIENT_AUTHENTICATION_SUPPORTED=true in server.env

The CA certificate that issued the mTLS client certificate must be added to RACF as CERTAUTH, and defined in the key ring identified by TLS_TRUST_STORE_KEY_RING in server.env.

The client certificate must either be imported to RACF with a specific RACF user ID as owner, which will then be the user ID that is authorized to the appropriate roles, or the client certificate can be mapped to an existing RACF user ID.

Note: The workflow provides optional steps to create test certificates for mTLS. These are suitable for development and testing only. For production environments, use certificates signed by your enterprise Certificate Authority. See Production client certificate practices for production certificate guidance. {: note} For complete mTLS setup instructions including certificate generation, mapping, and API usage, see Configuring mutual TLS (mTLS) authentication.

Verify the GraphQL endpoint

After starting the server, the CC CAT graphQL interface will be available at https://hostname:${HTTPS_PORT}/graphql which is the end point you need to supply to IBM Z Crypto Discovery and Inventory.

If you configure CC CAT for use with zCDI, pass this parameter to the zCDI administrator.

You can verify the endpoint by navigating to https://hostname:${HTTPS_PORT}/graphiql?path=/graphql which opens GraphiQL, an in-browser tool for writing, validating, and testing GraphQL queries.

You can also use curl to verify your endpoint.

curl -X POST 'https://hostname:${HTTPS_PORT}/graphql' \
     -H "Content-Type: application/json"  \
     -d '{"query":"query {\n  getKeystores(limit: 10, offset: 0){\n    keystores{\n      id\n      plex\n      systemId\n      type\n    }\n  }\n}"}'

When you require a client certificate, the sample command looks as follows.

curl -X POST 'https://hostname:${HTTPS_PORT}/graphql' \
     -H "Content-Type: application/json"  \
     --cert mtls-client.crt \
     --key mtls-client.key \
     --header 'ekmf-mtls: true' \
     -d '{"query":"query {\n  getKeystores(limit: 10, offset: 0){\n    keystores{\n      id\n      plex\n      systemId\n      type\n    }\n  }\n}"}'

If your server certificate is self signed, either specify the -k option to ignore it, or add your server CA to the request using the --cacert option.

Parameters required for using zCDI

The following parameters are required for using zCDI:

• the graphQL endpoint
• the client certificate
• the server CA certificate

Note that zCDI, opposed to other GraphQL clients, requires a client certificate.

Kafka security setup

Refer to the Kafka Security chapter to setup security for Kafka.