Security considerations

Consider the following when you configure Security for Liberty.

LTPA

  • Protect file access to the LTPA keys file because it contains the cryptographic material that is used to encrypt and decrypt the user data. Ensure that only the server and administrators have access to this file.
  • Ensure that all servers use the same LTPA keys. In addition, make sure that the all the servers have their time and date synchronized.
  • When you specify a password, ensure that it is the same password for all servers that use the same set of LTPA keys. The password is not used to generate the keys, but rather it is used to encrypt the LTPA keys file to prevent the keys from being read. If you copy the LTPA keys file to another Liberty server to achieve Single Sign-On (SSO), the password is required to gain access to the keys in the LTPA keys file. For more information about LTPA, see Configuring LTPA on Liberty topic.

Passwords

  • Encrypt passwords by using the securityUtility encode command.
  • If you override the default encryption key with the wlp.password.encryption.key property, set the property in a separate configuration file that is stored outside the normal configuration directory for the server.

Authorization

  • If you specify an auth-constraint with no roles in an application, then no one is allowed to access the resource.
  • Be cautious when you specify the EVERYONE special subject, as this specification is equivalent to not protecting a resource.

Authentication

  • The timeout value for the authentication cache that is specified in the <authCache> element must be smaller than the expiration value for the LTPA token that is specified in the <ltpa> element.

POST data

If you handle POST data during SAML, OAUTH, or OIDC login, or any kind of form or social login, be aware of the following considerations.

  • If you are handling any login that temporarily redirects an original request when it receives a POST request from a client, do not trust the header information in the received http request. The header information that a target servlet receives after the login process might not be the same as the original request. For example, content-length can be inaccurate. This behavior can vary for each client.
  • During redirection, the posted data is preserved by a cookie. Since there is a limitation on the size of the cookie, there is also a limitation on any posted data that is preserved by using that cookie. This limitation is usually around 4 KB, depending on the client implementation, and posted data is preserved by cookie by default. There is no fixed number and the limitation depends on the contents of the data. However, a cookie might not be suitable to preserve a large amount data, such as an image or a binary file.
  • If user data is accepted before authentication and authorization, it must then be preserved during these processes. This configuration puts a strain on resources and creates the potential for a denial of service attack. To protect against this vulnerability, do not accept any user data before authentication and authorization are complete.