You can provide different levels of CAS server authentication support, from a non-secure
connection to a secure connection with a signed certificate.
In addition to the basic security SSL provides, Guardium® provides CAS Server authentication support on the CAS client that runs on the
database server. Authentication guarantees that CAS client communicates only with Guardium's CAS
server. Unauthenticated connections and Common Name (CN) mismatches are reported in the CAS log
file.
After the CAS client is configured, when the CAS server starts it loads a signed certificate as
well as a private key. The server assigns the certificate and the key to a server socket on which it
accepts connections. You can choose to provide authentication from either the CAS client side or
server side.
The CAS client supports authentication with the following connection modes. Depending on your
requirements, set the following parameters in the guard_tap.ini file.
- Non-secure connection
- Set use_tls='0'.
- Secure connection without authentication (without FIPS mode)
- Set use_tls='1' and
guardium_ca_path=NULL.
- These settings force CAS to use SSL to communicate with the CAS server (that is, CAS uses SSL
without server authentication) and disables FIPS mode.
- Secure connection with server authentication (FIPS mode)
- Set use_tls ='1' and
guardium_ca_path=<public key location>.
- The CAS client uses the public key in a certificate to authenticate the CAS server.
- To prepare the custom certificate,
- Create a custom certificate by using the create csr alias CLI command and
have it signed by a certificate authority (CA) such as Verisign as described in Certificate CLI commands.
Note: When you create the
certificate, enter cas as the response to Please enter a one-word
alias to uniquely identify this certificate.
- Add the custom certificate to tomcat keystore: After you have the signed certificate (or
certificates), use the store certificate keystore alias console CLI command to
store the certificates starting from the last certificate to the root certificate in the
chain.
Note: Enter cas as the response to Please enter a one-word alias
to uniquely identify this certificate.
- Copy the certificate in PEM format (for example, ca.cert.pem) to the CAS
client machine, in the <public key location> described in the
guardium_ca_path parameter of the guard_tap.ini file.
-
On the CAS client machine, you can either set
guardium_ca_path in
guard_tap.ini to,
- The full path, including the actual public key file name.
- A directory name, where all of the public keys within this directory are used to authenticate
the server.
If
guardium_ca_path is set to a file or directory that doesn't contain
the public key, the connection attempt fails.
The CAS server supports secure connection with server authentication and common name
verification. The common name (CN) verification provides an additional check-in which the
certificate CN from the server is compared with the certificate CN set in the
sqlguard_cert_cn parameter in guard_tap.ini. If
sqlguard_cert_cn is NULL or empty, this check is disabled. Otherwise, the value
of sqlguard_cert_cn must be the same as the CN of the custom certificate stored
in CAS server tomcat keystore.