This blog post was first published @ www.fedji.com, included here with permission.
Let me start with a word of caution. I made a screen-cast to demonstrate the Distributed Authentication in ForgeRock OpenAM and you’ll find the same embedded on this post. Some of my actions in there are questionable and should never be attempted even in a development environment, such as setting a URL in the OpenAM Administration Console to redirect to after a Successful Authentication. This video demonstration is solely intended to give a hint on the positioning of Distributed Authentication UI in OpenAM Deployment Topology, but several other things like Network/Firewall configuration, Post Authentication Processing that goes hand in hand with the Distributed Authentication in OpenAM was beyond the scope of this short screen-cast. I really hope you get an idea on what the Distributed Authentication in OpenAM is expected to achieve.
The following illustration might give you an idea on what’s demonstrated in the video. We have a client network who cannot (or who is not supposed to) access the OpenAM Server in a different Network directly (say for Security reasons). So in a Demilitarized Zone (DMZ) or Perimeter Network, we have a Server that offers a Distributed Authentication UI to the clients from the ‘untrusted network’. That way, the clients get to see the UI of OpenAM by access the Server in DMZ, who would in turn talk to the OpenAM Server through a trusted channel. As one can imagine, Network Configuration like Firewall plays an important role in a deployment scenario, but sadly that’s all beyond the scope in our mini demonstration.