Securing Your DMZ Deployments with Oracle Access Manager 11gR2

Want to deploy an important application in DMZ? Not too sure about the security of the application and worry that current deployment techniques may not be sufficient? You may be right!!

Some of the packaged and legacy business applications were designed for internal users and sometimes do not meet modern security requirements. However, you would want to expose a portion of these internal applications outside your enterprise for your non-employee users like customers and vendors. For example, Oracle E-Business Suite (flagship Oracle ERP application) has some of the modules like iRecruitment, iSupplier, iStore etc. that are designed to be available outside company firewalls. Traditionally enterprises have been deploying these applications using standard architectural designs, like DMZs, reverse proxies, external web tiers, etc. However, current industry security standards are becoming more stringent and traditional deployment techniques sometimes may not comply with the new IT security standards.

Security teams inside enterprises are getting more involved in the design and deployment of applications, and they are placing some fundamental architectural requirements for externally facing applications. In this blog we will discuss some new enhancements that Oracle made to its flagship product for access management known as Oracle Access Manager that can help in deploying an application on the public network and meet these security requirements.

How OAM works – Typical OAM/Webgate with default Embedded Credentials Collector setup

Let us take a simple example of deploying an application in the public network and some important security considerations that need to be addressed.

Standard Business Requirements:

1. Business wants to expose all or a portion of an important financial application outside of the company firewall. All the intended functionality should be available.
2. Access to this application should only be available to an authenticated user, that is, a user who has a valid username and password and is registered with the company. For example, users in AD or some kind of database.
3. Once the user is authenticated, they should not be asked for a password again if they move to other areas of the application.

Security Requirements:

1. No access to any internal applications, servers or other assets.
2. Any access to this financial application outside the company firewall has to be authenticated.
3. Authenticated users can only access the applications, areas which they are authorized.
4. In case of any security compromise, there is limited exposure to internal IT resources (applications, servers etc.)

Let us see how we can utilize Oracle Access Manager to securely provide access in this scenario.

Assuming the application is accessible via some kind of webserver like apache or IIS. In a typical OAM setup, a piece of software known as webgate is installed on the webserver (OHS, apache, IIS). Webgate is an out-of-box client which enforces OAM policies on HTTP resources. Typically, it is installed on the webserver like apache and traps all incoming http traffic before it hits core apache. In this fashion, webgate can enforce OAM policies on the http resources residing on the http server.

Below is a typical setup of webgate/OAM. Resources (in this case application) behind the webservers are protected by OAM policies which are enforced by webgate software installed on the webservers. Webgates know which OAM server to talk to via their configuration setups. OAM software contains the policy-based model which authenticate and authorize the user who wants to access the application via webserver. There are various options available in OAM via which user can be authenticated. You can define various authorization rules based on your needs.

Expanding on the example above, let’s say the security team has enforced a resource on this webserver for example accounts site is protected and it is only available for authorized employees. We will setup OAM policies for “/accounts” on this http server and enforce authentication via LDAP lookup to corporate AD. The flow will look like this:

1. Client requests access to a resource. The request is trapped by webgate software installed on webserver.
2. Webgate checks whether the resource is protected per OAM. The resource is protected and the user has not yet authenticated.
3. Webgate sends 302 redirect to the client so that the client will be redirected for authentication.
4. The user will follow the redirect to OAM 11g server for authentication. In this example, the user has never been authenticated and form-based authentication is the authentication scheme of the OAM policy protecting the original requested resource.
5. OAM server sends a login page to client
6. User submits credentials which come to OAM server where the user’s credentials will be validated against corporate AD. In this case, it is assumed valid credentials are submitted.
7. After user credentials are successfully validated on the OAM server, the server will send another 302 redirect so that the user will be redirected back to original request.
8. Resource request goes back to OAM server for authorization.
9. OAM verifies the user’s original request again using ObSSOCookie passed from the OAM 11g server. Upon successful authorization, the user is allowed to access the resource.
10. The protected resource will be presented to the user.

In this example, we achieved the fundamental requirement of protecting the internal resource and only allowing valid users to gain access. However, in doing so exposed another internal resource, OAM server, to the outside world. In step 5 above, the OAM login page needs to accessible to the outside world, un-authenticated. This presents the chance that any rogue user will send direct requests to the OAM server inside the network. Needless to say, this will not pass the security requirements laid out above.

New Feature in OAM 11gR2 – Detached Credentials Collector

The Detached Credentials Collector (DCC) feature was introduced in OAM 11gR2  – 11.1.2.0.0 and it brought some interesting changes in the way webgate client and OAM server authenticates a user session. Instead of presenting a login page from OAM server, in DCC model the login credentials are submitted directly to the webgate and the webgate communicates back to the OAM server over OAP (Oracle Access Protocol) backend tunnel, which mitigates any direct access to the OAM server inside the network.

This feature is only available for 11g webgates with the OAM 11gR2 server. As of the writing of this blog, default login pages in DCC webgates do not support multi languages, however Oracle provides instructions on how to customize these pages and also make them available for required languages.

The install process of DCC webgate is the same as standard webgate. During the configuration of webgate and OAM server, you will need to make sure webgate has been setup as DCC webgate. Below is an example showing how DCC webgate works based on the example provided above.

1. Client requests access to protected resource. This sequence is pretty normal and looks exactly the same as the example above.
2. Webgate checks whether the resource is protected per OAM. The communication webgate and OAM happens over OAP secure tunnel. The resource is protected and the user has not yet authenticated.
3. Webgate sends 302 redirect to login page hosted locally on the webgate webserver. It also sets DCCtxCookie to save context information during authentication, more details on this cookie can be found here: http://docs.oracle.com/cd/E27559_01/admin.1112/e27239/sso.htm#CHDDDBID
4. The default login.pl page hosted on webgate webservers is presented to the user.
5. User submits the credentials. Notice that username/password combination is sent to webgate instead of directly to OAM server. Hence the name Detached Credential Collector.
6. Webgate server sends the credentials to the OAM server over OAP on default port 5575, this communication can be further secured using default SSL certificate or user provided valid SSL certificate. OAM server authenticates the user credentials.
7. DCC webgate server also checks if the resource is authorized for the authenticated user. The success is sent back to DCC webgate so it can continue to finish setting the next cookie and redirecting the browser back to the original requested URL.
8. DCC webgate then sets the OAMAuthCookie for the acme.domain.com domain. We now finally have SSO and webgate then grants access to the content requested.
9. The protected resource will be presented to the user.

Which is more secure?

As you can see in the DCC setup, there is no direct access to internal resources including OAM server to an un-authenticated user. The important internal resource is further shielded from any outside attack vectors and only limited resources in DMZ are exposed. This setup can be further strengthened by using commercial application delivery controllers like Oracle’s Traffic Director or appliance-based products like BIG-IPs F5 Traffic Manager or Citrix’s NetScaler Traffic Manager. These commercial ADC appliances can act as reverse proxy and provide SSL termination which can further secure the DMZ servers and provide better SSL traffic performance.

The default login pages on the DCC webgate can be further customized for the look and feel as per the requirement. For more information refer to: http://docs.oracle.com/cd/E40329_01/dev.1112/e27134/custpages.htm#AIDEV340

Conclusion

The Detached Credentials Collector feature provided in OAM 11gR2 version provides a more secure and flexible way to secure your internal IT assets and provide secure authenticated access for your customers. It eliminates some of the drawbacks of default OAM webgate configurations and prevents any un-authorized access to important internal resources. All the communication traffic should be further secured with SSL encryption, and in the eventuality the DMZ servers are compromised there is minimal exposure to important enterprise resources.

Oracle supports implementing OAM for EBS and there are various ways to implement OAM for Oracle E-Business Suite. Oracle recommends deploying DCC webgates if you are exposing your EBS instance in the DMZ. There are some typical architectural requirements that have to be met which will ensure secure and working setup of DCC webgates in an OAM and EBS setup. At Centroid, our team has designed and implemented DCC webgates for various customers which have met some complex security and functional requirements for EBS “iModules”. We can help anyone who is contemplating EBS DMZ deployments and worry about security considerations.