Anytime users interact with a web service, there are risks. With OpenAM, you can reduce those risks by deploying different parts of OpenAM in appropriate parts of an enterprise network.
To minimize risks, deploy only the core OpenAM server on systems directly connected through a firewall. As a start, deploy only the core server (and the protected web application) on Internet-facing servers. For instructions, see the following section from the OpenAM Installation Guide, Determine Which War File to Deploy.
You can further limit what is exposed through the firewall by using one of two strategies:
-
Set up a distributed authentication user interface (UI) in a DMZ between firewalls.
The distributed authentication UI is essentially a small subset of the OpenAM server with just enough login logic to receive user authentication requests. Those requests are forwarded to the core OpenAM servers.
See Installing OpenAM Distributed Authentication for installation instructions. The following figure shows the recommended architecture.
-
Alternatively, use a reverse proxy in front of OpenAM to allow access only to the necessary URLs. The following figure shows the recommended architecture with a reverse proxy.
For access to the console, deploy the full OpenAM application[10] on a separate system that is reachable only from internal systems. Do not include the full OpenAM server in the load-balanced pool of OpenAM servers serving applications.
-
Leave
ssoadm.jspdisabled in production. (Advanced property:ssoadm.disabled=true) -
If possible in your deployment, control access to OpenAM console by network address, such that administrators can only connect from well-known systems and networks.
-
Restrict access to URIs that you do not use, and prevent internal endpoints such as
/sessionservicefrom being reachable over the Internet.For a full list of endpoints, see the OpenAM Reference Guide Chapter on Service Endpoints.
