Access Policy Manager can provide the same functionality as an Oracle 10g WebGate. Access Policy Manager native OAM integration is built on top of Oracle 10g's latest Access Manager SDK. When you deploy Access Policy Manager with an OAM 10g or 11g server and OAM 10g WebGates, you no longer need to deploy a WebGate proxy or WebGate agent for each OAM-protected web application.

Access Policy Manager supports multiple WebGates and can function as an Authentication WebGate (when deployed with Oracle 10g server) as well as a Resource WebGate (when deployed with either Oracle 10g or 11g server).

Authentication WebGate (AWG)

The front-end agent of the OAM server that provides the interface of authentication and authorization for the user's access request to specific web resources.

Resource WebGate (RWG)

The front-end agent of protected web servers; the RWG validates the OAM session cookie (ObSSOCookie) to determine whether the user has been authenticated and can be authorized to access the requested web resources.

Although the Oracle 11g server is backward compatible with Oracle 10g WebGates, with Oracle 11g, Access Policy Manager acts in place of OAM 10g resource webgates, but cannot act as a authentication webgate. This is because a new architecture was introduced with OAM 11g in which the OAM 11g server becomes the central management point for everything including authentication, that is, the role of AWG. Refer to Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager 11g for a comparison of OAM 10g and 11g architectures.

Because the Oracle 11g server handles all user authentication requests, you should take steps to prevent and mitigate Layer 7 Denial of Server (DoS) and brute force attacks by installing a Web Application Firewall in front of the Oracle 11g server. BIG-IP Application Security Manager can provide you with intelligent Layer 7 protection in this case. For more information, refer to Configuration Guide for BIG-IP Application Security Manager.

You can achieve SSO functionality with OAM for HTTP/HTTPS requests passing through a virtual server to the web application. With OAM support enabled on a Local Traffic Manager (LTM) virtual server, Access Policy Manager will be the OAM policy enforcement point (PEP) on the BIG-IP system, while the OAM server is still the policy decision point (PDP) in the overall system architecture. When a user requests access to a protected web resource, Access Policy Manager communicates with the OAM server to determine whether the user can be authenticated/authorized for the request, and enforces the policy evaluation decision (made by OAM server) on the BIG-IP device.

The figures that follow show a typical configuration before and after OAM native integration is enabled.

Typical configuration before OAM native integration is enabled on the BIG-IP system

In this figure individual WebGates, installed on each webserver, interact with the OAM Access Server.

Typical configuration after OAM native integration is enabled on the BIG-IP system

In this figure WebGates are no longer required on the webservers, and, even if they are installed, they are not used. Access Policy Manager acts in place of the WebGates, contacting the OAM Access Server for policy information, and enforcing the policies.

Let's walk through an example deployment with Oracle 11g. You can integrate Access Policy Manager with a Oracle 11g server whether it is configured for single sign on (SSO) single domain or SSO multi-domain. To keep this example simple, we will assume that Oracle 11g server is configured for SSO single domain. The Oracle 11g server performs all authentication. A single Resource WebGate is configured in OAM.

In Access Policy Manager on the BIG-IP system, a AAA OAM server has been configured and includes the details of the OAM Access Server and one AccessGate. One virtual server has been configured with OAM native integration enabled. BIG-IP Application Security Manager (ASM) is installed in another virtual server as a web application firewall configured to prevent DoS and mitigate brute force attacks.

This figure depicts the traffic flow for the example.

Accessing a protected resource using Access Policy Manager deployed with OAM 11g

1. Client requests access to a resource. The request comes to the Resource Webgate (RWG).
2. RWG checks whether the resource is protected per OAM. The resource is protected and the user has not yet authenticated.
3. RWG sends a 302 redirect to the client so that the client will be redirected to the OAM 11g server for authentication.
4. 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 user-requested resource.
   Note: Before going to OAM, traffic is checked against security policies that are configured with anomaly protection on ASM, provided that the ASM module is enabled to protect the OAM 11g server on the BIG-IP system.
5. OAM sends a login page to the client.
6. User submits credentials which come to OAM server where the user's credentials will be validated. In this example, it is assumed that the user submitted valid credentials.
7. After user credentials are successfully validated on the OAM 11g server, the server will send another 302 redirect, so that the user will be redirected back to the original RWG.
8. Resource request comes to RWG.
9. RWG verifies the user's original request again using the ObSSOCookie passed from the OAM 11g server. Upon successful authorization, the user will be allowed to access the resource.
10. The protected resource behind VIP1 will be sent back to the user.

Let's walk through an example deployment. An Oracle 10g server is configured for SSO multi-domain; an Authentication WebGate is configured and, in another domain, a Resource WebGate is configured.

In Access Policy Manager, an AAA OAM server has been configured and includes the details of the OAM Access Server and the two AccessGates. Two virtual servers have been configured with OAM native integration enabled.

This figure depicts the traffic flow for the example.

Accessing a protected resource via Access Policy Manager native integration with OAM 10g

1. Client requests access to a resource. The request comes to the RWG (Access Policy Manager AccessGate at VIP2).
2. RWG checks whether the resource is protected per OAM. The resource is protected and the user has not yet authenticated.
3. RWG sends a 302 redirect to the client so that the client will be redirected to the AWG for authentication.
4. Authentication request comes to the AWG (Access Policy Manager AccessGate at VIP1).
5. AWG validates user authentication status with OAM and obtains policy. In this case, the policy calls for form-based authentication and gives the location of the form.
6. For the form-based authentication scheme, AWG allows the user to access the login page hosted on a webserver behind the AWG.
7. The webserver returns the login.html file to the AWG, which sends it to the client.
8. Via login.html, the user submits credentials.
9. The AWG uses the credentials to authenticate the user with the OAM 10g server.
10. With user authentication successful, the AWG sends a 302 redirect to the client so that the client will be redirected to the original RWG.
11. Request for resource comes to the RWG again.
12. The RWG validates user access to the resource with OAM.
13. The protected resource behind VIP2 will be sent back to the user.