Protecting Intranet and Extranet Applications with a Single OAM 11g Deployment

I frequently get asked how to setup a single OAM deployment to protect both intranet and extranet apps. Today I’d like to explore the issues and solutions around such a setup.

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

The Requirement

So the specific request is how to set up OAM so that it can protect intranet applications that can be accessed only from within the corporate network and extranet applications that can be accessed from the public internet.

The “Problem”

The issue (or apparent issue) that people see with creating such a solution is that OAM 11g is configured with a single “front end host” configured through a global setting that governs what protocol (HTTP/HTTPS), hostname, and port are used when users must be redirected to the OAM managed server.

If you go back and look at Chris’s post on the OAM 11g login flow and cookies then you’ll see that there are points in the flow where the user is redirected to the OAM managed server. This redirect can be to a load balancer or HTTP server fronting a managed server or cluster of OAM managed servers. So, OAM allows you through the “load balancer” settings to specify the interface that is fronting the OAM manage server(s).

The issue is that there is only a single global setting for defining the front end host for OAM. So people ask how can we protect intranet and extranet applications with one OAM deployment?

There are in fact two solutions to meeting this requirement.

An Extranet Front End Host for OAM

The first solution is to simply specify an extranet (externally accessible) host as the front end host for OAM. This way both intranet users accessing internal applications and extranet users accessing external applications from the internet can access the OAM server through the same front end host.

OAM Deployment with External Front End Host

This architecture is the recommended reference architecture for supporting this requirement. It is also the simplest solution to implement. The idea that you need to wrap your head around here is that even though your application may be accessible only from within the corporate network, that does not mean that your users cannot be sent at times (during login and initial SSO) to an externally accessible web server.

I do sometimes hear objections to this solution from customers who say that they want to keep their intranet users on the internal network. I have to admit that I don’t fully understand this objection. When I inquire as to what specifically they are concerned about I usually get a fairly vague response. In addition, it should be noted that on many if not most corporate networks, the user wouldn’t be sent all the way out to the internet to access the OAM front end host but rather just to the DMZ.

That being said, for customers that really want to keep intranet users on the internal network there is another solution.

Split DNS

I found a really good article by Thomas Schinder that explains split DNS. You can read it here.

The basic idea specific to an OAM deployment is that you setup your DNS so that your front end host for OAM as defined in the load balancer setting (say sso.mycompany.com) resolves to an externally accessible load balancer or web server when users query the host from the public internet but resolves to an internal load balancer or web server when users query the host from the internal network.

OAM Deployment with Split DNS

Split DNS works really well with OAM and is a completely viable option for enabling OAM to protect both extranet and intranet solutions simultaneously.

Identity Stores

There is a second unrelated issue that sometimes faces people wanting to do a single OAM deployment for external and internal applications and that is how their users are stored.

There are many variations on identity store requirements for hybrid internal/external deployments and I will save this discussion for another day but I wanted to mention it now as something to consider if you are planning such a deployment.