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.
- Java™ 2 security.
- 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 Knowledge Center, 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, therefore methods such as clearing the authentication cache are not available.
- Java 2 Connector (J2C) principal mapping modules support.
- Multiple security domain support.
- Security auditing subsystem that is part of the security infrastructure of the server.
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 only configure 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 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.