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.
- 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.