Security known issues and limitations

Edit online

Known issues and limitations exist for security in a WebSphere® Application Server Network Deployment cell that includes IBM® Modernized Runtime Extension for Java™ (MoRE) .

Security

The following known issues and limitations are for security.

The following limitations pertain to logged-out cookie tracking:
- Logged-out cookies on a managed Liberty server are tracked separately from tWAS nodes.
- If a user logs out from a WebSphere Application Server traditional server, the logout only takes affect on that server. The Liberty server logout cache does not track logouts from WebSphere Application Server traditional servers.
- If a user logs out on a Liberty server, WebSphere Application Server traditional servers do not track the logout.
  - The default behavior on Liberty is to have only a local cache. If a user logs out on a server, only that server processes the logout. The cookie can be used on other servers until the cookie expires. A distributed JCache can be configured on Liberty so that a logout on one Liberty server is enforced on all other Liberty servers with the same JCache configured.
  - WebSphere Application Server traditional servers have a distributed cache that use the DynaCache / Data Replication Service (DRS) implementation.
FIPS 140-2 and FIPS 140-3 are not supported for managed Liberty servers.
Managed Liberty servers support only stand-alone Lightweight Directory Access Protocol (LDAP), federated LDAP registries, and the file-based registry.
- Only passwords that use the PBKDF2withHmacSHA1 or PBKDF2withHmacSHA512 message digest algorithms can be migrated to the managed Liberty server. If your passwords are digested by using an algorithm that is not supported, you must digest your passwords again by using a supported algorithm.
- Managed Liberty servers cannot be created when a local operating system or custom registry are in use. If you change your registry type to an unsupported type, all managed Liberty servers remain active, but do not start again.
For stand-alone LDAP, not all features that are supported on WebSphere Application Server traditional servers are supported on managed Liberty servers. Examples include the following ones:
- Reuse connections
- Some LDAP type presets
Security domains are not supported. Managed Liberty servers can be deployed to only node agents that are in the global security domain.
When application security is not enabled, managed Liberty servers enforce security constraints, unlike WebSphere Application Server traditional servers.
The custom WebSphere Application Server Network Deployment Authentication and Authorization Service (JAAS) login configuration is not supported.
A custom SSL profile is not supported. The Node Default profile is used instead.
Password encryption: The built-in AES-128 password encryption and the bring-your-own custom password encryption modes are not supported. Only the built-in AES-256 encrypted and XOR-based passwords are supported. When a cell uses AES-128 password encryption or custom password encryption, the managed Liberty server is not functional after it starts.
The following SSO methods are not supported:
- OpenId provider
- OpenId Connect provider
- SAML Web Inbound
- SPNEGO
Administrator roles are mapped as listed here:
- Administrator role for the managed Liberty server
  - Administrator
  - Operator
- Reader role for the managed Liberty server
  - Monitor
- Not mapped
  - Auditor
  - Configurator
  - Deployer
  - iscadmins
  - adminsecuritymanager
  - ALL_AUTHENTICATED special subject
A user might need to log in again if the user logged in by using identity assertion on one server type and the user sends a request to the other server type. Server types are either WebSphere Application Server or managed Liberty server.
- To prevent this issue from occurring, the username must be present in one of the configured user registries.