Child pages
  • Security Best Practices when deploying OpenAM
Skip to end of metadata
Go to start of metadata
  1. Deploy the OpenAMs that will be facing the Internet without the console functionality. (Even better, use DAS if possible!)
  2. Deploy the full OpenAM WAR in a separate box accessible only internally to access the admin console.
  3. If the OpenAM needs to be used by external users (Internet users), you can use a Reverse Proxy in front of the OpenAM, making available only the necessary URLs to the outside world. Or you can use also the Distributed Authentication User Interface (DAUI).
  4. Create a sub-realm for your business needs: URLs to gain access to the OpenAM console will then require a "realm=/" parameter, and thus, they'll be easier to control and isolate from your applications URLs. You can also create an FQDN alias for each realm, and control accesses to these realms thanks to rules enforced by an agent at the reverse proxy level.
  5. Do not enable ssoadm.jsp in the production environment (from OpenAM 9.5.1 this is disabled by default).
  6. Regarding Policy Agents, assign a different Agent Profile for each Policy Agent.
  7. Use SSL whenever/wherever is possible (LDAPS/HTTPS).
  8. When using https use secure cookies .
  9. For the DataStore, try not to use the RootDN if possible (this depends on the design of the Directory Information Tree).
  10. Change the name of the iPlanetDirectoryPro cookie ( to something different and reflect this change in your policy agents as well.
  11. Use something different than "opensso" or "openam" as the deploy URI.
  12. If possible configure the valid values of the goto parameter (valid goto URL domains) in the OpenAM.
  13. Use subdomain cookie if possible and if possible control this sub-domain in a different DNS master.
  14. Use anti-cookie-hijack mode (restricted tokens) where each agent has a different SSOToken for the same user.
  15. If using SAML2, sign the authentication request and response and the Single Logout Request.
  16. If using SAML2, use your own Key, do not use the "test" key that comes with OpenAM.
  17. Define a top-realm administrator different than the OpenAM default(amadmin). Create new administrators to better track configuration changes.
  18. If applicable, add a source IP address control rule (or such like) for OpenAM console accesses, to allow administrators to connect to the OpenAM UI only from well known workstations or networks.
  19. Make sure advanced property is set to true
  20. Restrict access to URIs not used by your use-cases: internal endpoints SHOULD NOT be reachable from the Internet (/sessionservice and accompanies).