WebGates, Proxies and Apps OH MY! paraphrased from the Wizard of Oz.

I can understand why Dorothy was so worried.  Customers often struggle with the question of if they should integrate their OAM environment and applications with WebGates on each application, or use a general reverse proxy farm.  This question recently came up on a customer project, and the simple answer is: “It depends."

The below diagram shows how the reverse proxy model works:

When integrating with OAM using the reverse proxy model, a web server that is owned by the OAM team is used to do all OAM specific work.  This includes:

1. Intercepting requests and verifying authentication and authorization;
2. Redirecting users to the OAM login server for authentication; and,
3. Forwarding the user’s context to the application.

The primary advantage to this approach is that all hardware and software is owned by the OAM team.  Any issues with authentication or authorization that occur can be managed internally by the OAM team without direct interaction with the customer.  Issues with application integration may still require working with the customer.

The disadvantage to this approach is that all application traffic flows through ICAM servers, requiring the OAM team to manage enough hardware to handle the load of authentication traffic AND application traffic.  This model works well in scenarios that:

1. There is no application web server
2. The application has a single URL
3. The application does not need TLS/SSL or does not want to host a certificate
4. Applications that can accept an HTTP header to identify a user

In these scenarios an application can generally be integrated quickly into the environment.

Because there is no “phone-home” from the application to OAM to verify the security context (usually a header), it’s important that this method lock down connections from the reverse proxy to the application using firewall rules and/or SSL/TLS mutual authentication.  This will protect the application from spoofing attempts.

The alternative to the reverse proxy model is to use a WebGate.  A WebGate, or Agent, is a component that runs in a webserver that acts as a “gate keeper” using OAM.  This component intercepts all requests, and will redirect the user to the OAM login server for authentication when needed.

WebGates offer several advantages over a reverse proxy hosted by the OAM Team:

1. The OAM team does not need to manage networking from the customer’s browser to the application;
2. Fewer network hops; and,
3. More direct integration with the application’s web server.

The main disadvantage to this model is that the WebGate needs to be installed onto the application’s web server.  This means the ICAM team will need to be available for installation and testing as well as trouble shooting when issues occur.

While the Reverse Proxy model offers more simplicity, the WebGate model offers more power and control.  This model is effective on applications with:

1. Complex URL structures;
2. Must host their own certificate for TLS/SSL;
3. High volume; and,
4. Applications that want “last mile” security contexts other then headers (ie and OAM Session Cookie).

Integrations using this method generally take longer but require less in the way of locking down connections between OAM and the application as there is built-in security in those connections.

The model used for an application should be determined on an application-by-application basis.  Simpler applications will often benefit from the speed of a rapid integration, whereas larger and more complex applications will often require the power and flexibility of a local Web Gate. 

Once you break down the requirements of an application and see that there are several options for handling them, neither WebGates nor proxies seem all that scary.