Knowledge Center

How to deploy OAM and WebGates in Production
View More

Summary:

                   Oracle Access Manager (OAM) can be deployed in many ways. Every enterprise has different network setup. Based on many considerations like network architecture, DMZ setup, if OAM is used for external users or internal users or combination of both, OAM should be deployed that takes care of security requirements and also gives optimal performance by avoiding any unwanted hops.

Deployment Architecture-1:

  1.  Many organizations start thinking deploying OAM as mentioned in the below diagram but as complexities increases, they will have to consider other architectures.
  2.  In this architecture all your applications are front ended by a Web Server. In the same Web Server say OHS or similar you will deploy WebGate also. You also configure the same Web Server to front end OAM as well

Pros:

  1.  Architecture is very simple, no additional hardware required for WebGate
  2.  If there are only limited applications which all need to be protected by OAM and if there are no mission critical applications, then this architecture can be considered if there are limitations to invest in additional compute for WebGate

Cons:

  1. If you have one Web Server front ending all applications and OAM as well, it may not scale up beyond a point
  2. In this architecture all applications by default will get protected by OAM, though there are configuration you can do to avoid this
  3. If Web Server is down due to any one application server setting changes all applications including OAM will become inaccessible
  4. If configurations are not done properly, there might be unnecessary hops and performance degradation

Deployment Architecture-2:

  1.  In this architecture all applications are put behind one Web Server and user interacts with OAM without Web Server either via Load Balancer directly
  2.  In this architecture all your applications are front ended by a Web Server. In the same Web Server say OHS or similar you will deploy WebGate also.

Pros:

  1.  Architecture is very simple, no additional hardware required for WebGate
  2.  If there are only limited applications which all need to be protected by OAM and if there are no mission critical applications, then this architecture can be considered if there are limitations to invest in additional compute for WebGate

Cons:

  1. If you have one Web Server front ending all applications, it may not scale up beyond a point. You can have slight variation to this architecture; every application can have its own Web Server and you can setup WebGate on each of the Web Server to avoid below issues.
  2. In this architecture all applications by default will get protected by OAM, though there are configuration you can do to avoid this
  3. If Web Server is down due to any one application server setting changes all applications will be in accessible.
  4. If configurations are not done properly, there might be unnecessary hops and performance degradation.

Deployment Architecture-3:

  1.  In this architecture all applications are put behind their own respective Web servers with WebGates configured on each Web Server
  2. OAM is also front ended by another Web Server (without WebGate)

Pros:

  1.  This is the most scalable architecture.
  2.  Any issue in one application or Web Server won’t impact any other application
  3. Security also can be properly handled without exposing OAM to outside world directly

Cons:

  1. WebGate needs to be configured on each web server, so more effort for setup and maintenance
  2. Need additional hardware

Conclusion:

                           Though Architecture-3 is one of the best approach, you need to carefully understand the existing network architecture, future planning and other aspects to finalize any one of the above approach or you can have slight variations in the deployment depending upon your requirements. Also, note that, for representation only one server is shown, for High Availability you need to deploy multiple servers as per the need.