Authorizing users to run applications in a Liberty JVM server

You can use Java EE application security roles to authorize access to Java EE applications. Additionally, in a Liberty JVM server you can further restrict access to transactions (run as part of the application) by using CICS transaction and resource security.

About this task

Your application is secured by providing an authorization constraint, the <auth_constraint> element, in the deployment descriptor (web.xml). If present, this ensures that access to your application is achieved only by a user that is a member of an authorized role. User or group membership to a Java EE role is determined in one of two ways:
  • Use an <application-bnd> element in the <application> element of your server.xml to describe the user/group to role mappings directly in XML.
  • Use <safAuthorization> in your server.xml to allow users/groups role membership to be mapped by SAF (typically using EJBROLES).
For more information, see Authorization using SAF role mapping.

Using CICS security allows you to re-use existing security procedures but requires that individual web applications are accessed from different URIMAPs. Using role-based security allows you to use existing standard Java EE security definitions from another Java EE application server. For more information, see Authenticating users in a Liberty JVM server.

If you want to use CICS transaction and resource authorization exclusively, or prefer to use finer-grained annotation-based role checking in code, you can defer the authorization decision to those components by using the special subject ALL_AUTHENTICATED_USERS role, as shown in the following example. If you deploy a Liberty application in a CICS bundle, CICS automatically configures this for you.
Note: Access checks are performed for the declarative security annotations and CICS transaction and resource security only after the configured constraints (web.xml) are verified
<application id="com.ibm.cics.server.examples.wlp.tsq.app" 
    name="com.ibm.cics.server.examples.wlp.tsq.app" type="eba" 
    location="${server.output.dir}/installedApps/com.ibm.cics.server.examples.wlp.tsq.app.eba">
	<application-bnd>
		<security-role name="cicsAllAuthenticated">
			<special-subject type="ALL_AUTHENTICATED_USERS"/>
		</security-role>
	</application-bnd>
</application>

Using this special subject, and giving the cicsAllAuthenticated role access to all URLs in your web applications deployment descriptor (web.xml), allows access to the web application using any authenticated user ID and authorization to the transaction must be controlled using CICS transaction security. If you deploy your application directly to the dropins directory, it is not configured to use CICS security as dropins does not support security.

If you are using safAuthorization then the <application-bnd> no longer acts as the source of user ID to role mapping. Instead, EJBROLEs in SAF determine which SAF users are in which roles (EJBROLEs). With safAuthorization the <application-bnd> is ignored. To achieve the same effect and allow all authenticated users to be authorized to run your application, the <auth-constraint> in web.xml must use the special role **, for example:
<auth-constraint>
        <description>special role for all authenticated users</description>
        <role-name>**</role-name>
</auth-constraint>
  • The special role name ** is a shorthand for any authenticated user independent of role.
  • The special role name * is a shorthand for all role names defined in the deployment descriptor.
When the special role name ** appears in an authorization constraint, it indicates that any authenticated user, independent of role, is authorized to perform the constrained requests. Special roles do not need an additional <security-role> declaration in web.xml.

To use CICS transaction or resource security you should follow the following steps:

Procedure

  1. Define a URIMAP of type JVMSERVER for each web application. Typically, you might specify a URIMAP to match the generic context root (URI) of a web application to scope the transaction ID to the set of servlets that make up the application. Or you may choose to run each individual servlet under a different transaction with a more precise URI.
  2. Authorize all users of the web application to use the transaction specified in the URIMAP using CICS transaction or resource security profiles.