Design example: Securing a Liberty web application with TLS client authentication and SAF role authorization

In this example, the Enterprise Java application is deployed with a security constraint in its application deployment descriptor (web.xml). This restraint requires the web client to provide a TLS client certificate. An authorization constraint is configured in the deployment descriptor so that authenticated users must be in role myRole to run the application. SAF role authorization is used to verify that the authenticated user ID is a member of the authorized role.

For more information about configuring this scenario, including the definition of role-mapping preferences, see the configuration task Configuration example: Securing a web application with TLS client authentication and SAF role authorization.

Figure 1 shows an overview of the scenario.

Figure 1. Securing a Liberty web application with TLS client authentication and SAF role authorization
A diagram showing the scenario where a Liberty web application is secured by TLS client authentication and SAF role authorization. Each step in the diagram is described in the following text.
  1. The web client sends an HTTPS request to the Liberty JVM server. A TLS handshake is performed. The Liberty JVM server sends its server certificate and asks the client to provide its certificate.
  2. The server validates the chain of trust by checking that the client certificate issuer (signer certificate) is in the RACF® keyring.
  3. To authenticate the request, the Liberty server also maps the web client certificate to a RACF user ID (the mappedUserid).
  4. The Liberty server checks that the mappedUserid is authorized to run the web request. This check is done by calling RACF to verify that the mappedUserid has READ access to profile safProfilePrefix.myApplication.myRole in the class EJBROLE or its corresponding resource group class.
  5. The CICS® task (including the Java™ application code and COBOL program) runs with the mappedUserid. No URIMAP is defined for the request so the task runs with the CICS Liberty default transaction ID CJSA.
Important: If you don't want to run tasks with the default transaction ID, you can define a single URIMAP for all requests to the Liberty JVM server. This URIMAP specifies another transaction ID (for example, BJSA). The BJSA transaction ID resource definition is created by copying the CJSA resource definition and changing the transaction name.