Manual Chapter :
APM Integration with Oracle Access Manager
Applies To:
Show Versions
BIG-IP APM
- 17.0.0, 16.1.0, 16.0.1, 16.0.0, 15.1.0
APM Integration with Oracle Access Manager
APM Integration with Oracle Access ManagerAbout integration with supported Oracle Access Manager
versions
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 Service (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
BIG-IP
Application Security Manager:
Implementations
.How does native integration with OAM work?
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.
These figures 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 web server, 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 web servers, 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.
Oracle Access Manager relies on synchronized time on all Oracle Identity
Management systems and BIG-IP systems. Thus, a reliable source is used on all components of a
deployment. It is also recommended to use NTP servers. OAM Access Server time can be ahead of
BIG-IP system time by fewer than 60 seconds, while BIG-IP system time should never be ahead of
OAM Access Server time. Differences in system clocks can cause the system to reject all requests
to the Identity Server.
OAM 11g SSO integration example
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
- Client requests access to a resource. The request comes to the Resource Webgate (RWG).
- RWG checks whether the resource is protected per OAM. The resource is protected and the user has not yet authenticated.
- RWG sends a 302 redirect to the client so that the client will be redirected to the OAM 11g server for authentication.
- 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.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.
- OAM sends a login page to the client.
- 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.
- 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.
- Resource request comes to RWG.
- RWG verifies the user's original request again using theObSSOCookiepassed from the OAM 11g server. Upon successful authorization, the user will be allowed to access the resource.
- The protected resource behind VIP1 will be sent back to the user.
OAM 10g SSO integration example
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
- Client requests access to a resource. The request comes to the RWG (Access Policy Manager AccessGate at VIP2).
- RWG checks whether the resource is protected per OAM. The resource is protected and the user has not yet authenticated.
- RWG sends a 302 redirect to the client so that the client will be redirected to the AWG for authentication.
- Authentication request comes to the AWG (Access Policy Manager AccessGate at VIP1).
- 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.
- For the form-based authentication scheme, AWG allows the user to access the login page hosted on a webserver behind the AWG.
- The webserver returns the login.html file to the AWG, which sends it to the client.
- Via login.html, the user submits credentials.
- The AWG uses the credentials to authenticate the user with the OAM 10g server.
- With user authentication successful, the AWG sends a 302 redirect to the client so that the client will be redirected to the original RWG.
- Request for resource comes to the RWG again.
- The RWG validates user access to the resource with OAM.
- The protected resource behind VIP2 will be sent back to the user.
