Understanding OAM Security Provider Use Cases

With the OAM Security Provider, you can use Oracle Access Manager to protect JavaEE Web Application resources. You can configure single sign-on for Web applications, such that a user who has authenticated to GlassFish Server can access Oracle Access Manager-protected resources without re-authentication. You can also configure single sign-on such that a user who has authenticated to Oracle Access Manager can access GlassFish Server Web resources without re-authentication. The OAM Security Provider can also be optionally configured to perform resource authorization using policies configured at the Oracle Access Manager PolicyManager.

You can use the provider in the following ways:

• To provide authentication for Web resources via an AccessGate.

• To provide authentication (Identity Assertion) for Web resources using a proxy server with a WebGate installed.

• To indicate that authorization checks are based on Policy Manager.

Uses cases for each scenario are described next.

Use Case: Authentication for Web Resources Via Access Gate

The OAM Security Provider uses Oracle Access Manager authentication services to authenticate users who access JavaEE applications deployed on GlassFish Server. This method can be used to protect HTTP resources deployed on GlassFish Server. Users are authenticated based on their credentials, such as user name and password (BASIC/Form) and client certificate.

The OAM Security Provider uses an AccessGate to consult an AccessServer configured at the Oracle Access Manager instance to do authentication. Upon successful authentication, the OAM Security Provider sets a cookie (ORA_GF_ObSSOCookie) to represent the single sign-on (SSO) session created by Oracle Access Manager.

Consider the flow of control shown in Figure 7-1.

Figure 7-1 Authentication (FORM/BASIC) for Web resources Via AccessGate

The flow of control shown in Figure 7-1 is as follows:

1. A user attempts to access an Oracle Access Manager-protected GlassFish Server resource.

2. The GlassFish Server challenges the user for a username and password using a predefined login form in the case of FORM authentication (or a challenge in the case of BASIC authentication) because the application's deployment descriptor requires authentication from the container. You can use your own login form, which can be specified as an option to the OAM Security Provider.

3. The GlassFish Server forwards the username and password to the OAM Security Provider for authentication and authorization.

4. The OAM Security Provider uses the AccessGate to communicate with the Access Server to verify the user's identity. If authentication is successful, the Access Server generates a session token with a URL that contains the ORA_GF_ObSSOCookie.

5. If authentication is successful, the OAM Security Provider creates a Subject with the authenticated principal and also sets the cookie in the response.

   The ORA_GF_ObSSOCookie is set so that when the user attempts to access additional Oracle Access Manager-protected non-GlassFish Server resources, authentication is not performed. That is, if the ORA_GF_ObSSOCookie is already set and the user has logged in using form-based authentication, the user is logged in without being challenged.

6. The control returns to the GlassFish Server authorization mechanism, which checks if the user has permission to access the requested resource. The policies that protect resources are specified in the Policy Manager application in Oracle Access Manager. Policies that are defined in web.xml and glassfish-web.xml are honored by default and authorization based on policies at the Policy Manager can be configured as an option. When the OAM Security Provider is configured to do additional authorization checks based on policies at the Policy Manager, the resource access is disallowed if the policies defined in web.xml are not also satisfied.

7. If authorization is successful, the GlassFish Server allows the user to access the requested resource.

Use Case: Identity Assertion for Web Resources via WebGate

This use case occurs when GlassFish Server is behind an Oracle HTTP Server proxy that has an installed WebGate, and there is a connector to the GlassFish Server Web container from the proxy.

The WebGate is responsible for challenging the user requests for resources, and it is assumed that all requests to the Web container have to come through the configured proxy. The Web resources are protected using authentication schemes such as FORM, BASIC, or CLIENT-CERT supported by the WebGate. The WebGate protects only Web resources (HTTP).

Consider the flow of control shown in Figure 7-2.

Figure 7-2 Identity Assertion via WebGate

The flow of control shown in Figure 7-2 is as follows:

1. A user attempts to access an Oracle Access Manager-protected Web application that is deployed on the GlassFish Server. (The WebGate protects only Web resources (HTTP). )

2. The WebGate intercepts the request and queries the Access Server to check if the resource is protected.

3. If the resource is protected, the WebGate challenges the user for credentials based on the type of Oracle Access Manager authentication scheme configured for the resource, which is CLIENT CERT in this use case.

4. The user presents a certificate.

5. If the user authenticates successfully, the Oracle Access Manager sets the OAM_REMOTE_USER header in the request. Note the following cookie and header use:

   • For a 10g WebGate:

     • The ObSSOCookie is always propagated.

     • The OAM_REMOTE_USER header is always set by an OAM 11g server.

   • For an 11g Webgate:

     • A cookie is not propagated.

     • The OAM_REMOTE_USER header is always set by an OAM 11g server

6. The request is redirected to the GlassFish Server via the Oracle HTTP Server (OHS) redirect directive.

7. The OAM Security Provider looks at the OAM_REMOTE_USER header and gets the authenticated user identity.

8. The OAM Security Provider creates a Subject with the authenticated principal.

9. Authorization based on policies at the Policy Manager in Oracle Access Manager can be configured as an option.

10. (Not shown.) If authorization is successful, the GlassFish Server enables the user to access the requested resource.

Use Case: Authorization Checks Based on Policy Manager

The oam.check.resource.access parameter to the OAM Security Provider (see Table 7-2) indicates whether Oracle Access Manager should perform authorization checks for the resource.

This authorizer function is optional.

By default, GlassFish Server uses its container authorization mechanisms to make the final resource access decision. GlassFish Server uses the Subject set by the OAM Security Provider (after successful authentication) to perform the authorization step.

If you set the oam.check.resource.access parameter for the OAM Security Provider to true, the Oracle Access Manager policies that protect the resources are invoked. (You specify these policies in the Policy Manager application in Oracle Access Manager.)

The authorization flow of control is as follows:

1. A user attempts to access an Oracle Access Manager-protected GlassFish Server resource.

2. The GlassFish Server challenges the user for a username and password using a predefined login form in the case of FORM authentication (or a challenge in the case of BASIC authentication) because the application's deployment descriptor requires authentication from the container. You can use your own login form, which can be specified as an option to the OAM Security Provider.

3. The GlassFish Server forwards the username and password to the OAM Security Provider for authentication and authorization.

4. The OAM Security Provider uses the AccessGate to communicate with the Access Server to verify the user's identity and to see if the user has access to the protected resource, as determined by a policy in the Policy Manager. (The policies that protect resources are specified in the Policy Manager application in Oracle Access Manager. ) If authentication is successful and the user has access to the resource, the Access Server generates a session token with a URL that contains the ORA_GF_ObSSOCookie.

5. If authentication is successful, the OAM Security Provider creates a Subject with the authenticated principal and also sets the cookie in the response.

   The ORA_GF_ObSSOCookie is set so that when the user attempts to access additional Oracle Access Manager-protected resources, authentication is not performed. That is, if the ORA_GF_ObSSOCookie is already set and the user has logged in using form-based authentication, the user is logged in without being challenged.

6. The control returns to the GlassFish Server authorization mechanism, which checks whether the user has permission to access the requested resource. When the OAM Security Provider is configured to do additional authorization checks based on policies at the Policy Manager, final access to a resource is allowed only when Policy Manager policies and web.xml policies are both satisfied.

7. If authorization is successful, the GlassFish Server allows the user to access the requested resource.