Oracle Access Manager has an interesting problem. There’s no way to clearly separate your internal webgate traffic from your external, DMZ, user traffic…. until now. I figured out a hack to get it to work =)
This is an in-depth write-up on the configuration, but it is a hack. Oracle Support literally laughed at me on the phone with an added “oh my god, I can’t believe you got this to work”, so don’t expect to see this in a fix / bundle patch any time soon.
There seems to be a major configuration flaw within OAM 11g for the setup of a reverse proxy for all the OAM traffic. This is a generalized write-up on how to configure OAM to partition its internal and external traffic.
The problem: In Oracle Access Manager 11g, you can configure your access server with a single hostname and a single port. This works fine for a completely internal OAM environment. If you have external applications, you will want to setup a reverse proxy that sits in the DMZ and routes the traffic to your internally protected OAM servers and then install a single webgate on this reverse proxy. This has been standard practice for 10g / Oblix / CoreID. When a user makes a request to the webgate, the webgate intercepts and in some cases redirects the user to the OAM server (port 14100 by default) for the login and logout mechanisms. Oracle states that we should open port 14110 to the DMZ to allow users direct access to the server for these processes. This is a bad security practice. You should never allow an external user access to an intranet server. The configuration for the webgate on where to redirect the user comes from OAM server configuration. You cannot manually update the hostname and port to the proxy server in the webgate configuration. All you can do is select an OAM server from a drop down. This will allow you an either / or situation. You can either open port 14100 into your DMZ, or your webgate will be unable to contact the access server. Both of these options are unacceptable.
The disclaimer: Although this will get the traffic split, and is done completely through the OAM console using out-of-the-box functionality, it is a VERY fragile setup. You will need to explain to everyone that has access to configuring your webgates how to put this configuration back in place, or not to touch it at all.
The solution: To start out, setup your OAM server with the hostname and port of the actual OAM server. Let’s say this is oamserver:14100 for this scenario. Then go into the webgate configuration and setup your webgate to point to the OAM server as the primary server. So far, this is pretty standard stuff and for most, this is the starting point of a working environment. Our first change will be to change the Logout Redirect URL to use the reverse proxy hostname and port. For this example, we’ll use oam.revproxy.com:7777. Apply your new settings. This will send all of your logout traffic from this webgate through the reverse proxy. Your webgate is now done. This only fixes half of the problem. If we stopped here, all login requests, would still take place through oamserver:14100. To fix this we need all our regular traffic to go through the proxy server as well. So next, expand “Server Instances” and open the configuration for your primary OAM server. Change the Host to the hostname of your reverse proxy (oam.revproxy.com) for all of your OAM requests and change the port to the port your reverse proxy is listening on (7777). Apply your configuration, and restart all of your OAM servers / Admin Servers / web servers / reverse proxies. We have to clear out all the caches of the OAM server configurations. When all of the servers come up, all of your user traffic will now be routed through your reverse proxy, and your webgate / internal OAM traffic will go directly to the OAM server… like it’s supposed to.
The kicker: Here’s why this is an unstable configuration. If you now go and pull up the configuration of your webgate, scroll down and look at the Primary Server List. You’ll see that the Server Name is empty, but there is a Host Name (oamserver) and a Host Port (5575). This is because OAM doesn’t update the webgate configuration with the new OAM server info automatically. It’s still populated with the old hostname and the proxy port. The proxy port is not your reverse proxy port. It is the port that all internal communication (webgate <-> oamserver) takes place over. You want this to be internal. Now, if you try to update any setting of this webgate, OAM will throw an error stating that there is no Primary Sever associated with this webgate, and it won’t save anything until you pick one. If you choose the server from the drop drown you will erase the good configuration of the webgate and all of your webgate traffic will now be run through port 5575 on your proxy server (oam.revproxy.com). This is bad. Mainly because you don’t want internal traffic going out into the DMZ. Also, because your reverse proxy is only listening to port 7777 and not 5575, so the traffic will drop, and your webgate will throw a 500 error about not being able to reach the Access Server.
If you ever need to update the configuration of the webgate, you will have to cycle the hostname and port of your OAM server configuration again to swap it out of the webgate configuration. Also, after you make the final changes to the OAM server, you should check the ObAccessClient.xml file on the reverse proxy (/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config/ObAccessClient.xml) to see if it has been updated with the correct internal OAM server settings for the primary server. Search for primaryServer for the correct node. If it’s not updated, you can update it manually. If OAM ever overwrites this file, it will be with the good configuration anyway.
If you’ve setup everything correctly, all of your external traffic that your users generate will now be routed through your reverse proxy (oam.revproxy.com:7777) and then the webgate will forward all the traffic to the internal OAM server (oamserver:14100).
Oracle said that they will turn this into an enhancement request since this is how the product is supposed to work in the first place. But with the 11g R2 (or 12c as their calling it now… c for cloud), I don’t see this happening any time soon.