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

In this example, the Enterprise Java application is deployed with security constraints in its application deployment descriptor (web.xml) that require the web client to provide basic authentication credentials and to use HTTPS. SAF role authorization is used to verify that the clientUserid is a member of the authorized EJBROLE profile. An authorization constraint is configured in the web.xml so that users must be in the security role myRole to run the application.

For more information about configuring for this scenario, see Configuration example: Securing a web application with basic authentication and SAF role authorization.

Figure 1 shows an overview of the scenario.

1. The web client sends an HTTPS request with the clientUserid and password in the HTTP Authorization header to the Liberty JVM server.
   Important: It is recommended to use HTTPS because the basic authentication credentials are not signed or encrypted.
2. To authenticate the request, the Liberty server validates the clientUserid and password against the configured RACF® user registry and uses this to set the Java security subject.
3. The Liberty server checks that the clientUserid is authorized to access the web URL defined in the constraint. The verification is done by calling RACF to verify that the user ID has READ access to the profile safProfilePrefix.application.myRole in the class EJBROLE or its corresponding resource group class.
4. The CICS® transaction (including the Java™ application code) runs using the security context of the clientUserid. No URIMAP is defined for the request so the transaction runs with the CICS Liberty default transaction ID CJSA.