Configuration differences between the WebSphere Application Server traditional and Liberty: security

The configuration differences in the security capability between Liberty and WebSphere® Application Server traditional indicates the items that you might need to know during applications migration.

Liberty security supports only a subset of security features in the WebSphere Application Server traditional. Unless the support is explicitly mentioned in the Liberty documentation, you must assume that the support is not available yet.

The following security features are not included in Liberty:
  • Not all public APIs and SPIs are supported. The Java™ API documentation for each Liberty API is detailed in the Programming interfaces (Javadoc) section of the online IBM® documentation, and is also available as a separate .zip file in one of the javadoc subdirectories of the ${wlp.install.dir}/dev directory.
  • Horizontal propagation.
  • SecurityAdmin MBean support, as a result, methods such as clearing the authentication cache are not available.
  • Java 2 Connector (J2C) principal mapping modules support.
  • Multiple security domain support.

In Liberty, you can configure user-to-role mappings and RunAs users in the application-bnd element of the server.xml file. For a Run-As entry, the password is optional. In the WebSphere Application Server traditional, you can configure only the Run-AS entry in the ibm-application-bnd.xml/xmi file. For a Run-As entry, the password is required. See Configuring authorization for applications in Liberty.

In Liberty, role names can be referenced by the HttpServletRequest.isUserInRole and EJBContext.isCallerInRole APIs, or by elements in the deployment descriptor, without first declaring the role names by using the @DeclareRoles annotation or the <security-role/> element in the deployment descriptor. However, roles must be declared before being used in WebSphere Application Server traditional.