7 Integrating Oracle Access Manager

Obtaining Oracle Access Manager Group Information

In the authentication function, the OAM Security Provider also tries to obtain group membership information for the authenticated user from the Oracle Access Manager backend. This information is set in a SecurityContext, which is then passed to the GlassFish Server authorization system to determine if access to the resource should be allowed.

The backend query is integrated into the JSR-196 CallerPrincipal Callback handling in the container and is transparent to the OAM Security Provider.

To obtain the group information, you configure an LDAPRealm in GlassFish Server to point to the OAM backend where the group information is stored. For example, you can use the Administration Console or the create-auth-realm command to add the following entry to the domain-specific domain.xml file:

<auth-realm classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm
 name="ldaprealm">
<property name="jaas-context" value="ldapRealm" />
<property name="base-dn" value="o=company,c=us" />
<property name="directory" value="ldap://140.87.134.98:1389" />
<property name="search-bind-dn" value="cn=Directory Manager" />
<property name="search-bind-password" value="welcome1" />
</auth-realm>

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

Description of "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

Description of "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.

Integrating OAM Security Provider with Oracle Access Manager 10g

This procedure explains how to integrate the OAM Security Provider with Oracle Access Manager 10g.

See the Oracle Access Manager Installation Guide for detailed instructions on Access Manager tasks.

The procedure was tested on Microsoft Windows and the file names are those of the Windows version.

1. Install and configure Oracle Access Manager.

   To do this, install Oracle Identity Server, the Policy Manager, and the Oracle Access Server component. You need to obtain all of the required Oracle Access Manager components before you begin the installation procedures.

2. Log in to Administration Console.

   After the successful installation, access the Administration Console from http://host:port/access/oblix and log in.

   The administrative interface for managing core access server components, policy manager, and identity console is displayed.

3. Create users.

   From the User Manager tab of the Identity System Console, create the users who will have access to the protected resource. For example, you might create the user Glassfish, as shown in Figure 7-4.

   Figure 7-4 Glassfish User

   
   Description of "Figure 7-4 Glassfish User"
   
   

4. Create the group.

   From the Group Manager tab of the Identity System Console, create the group to which you will grant access and add users to the group. For example, you might create the group Glassfish_group, and add the user Glassfish to this group, as shown in Figure 7-5.

   Figure 7-5 Glassfish Group

   
   Description of "Figure 7-5 Glassfish Group"
   
   

5. Create Access Server configuration.

   From the Access System Configuration tab of the Access System Console, create an Access Server Configuration.

   Provide the required parameters including Name and Hostname, and enable it.

   When you configure an Access Server, you specify the transport security mode to use between an Access Gate/WebGate and this Access Server, from the following choices:

   • Open mode means no encryption.

   • Simple mode means encryption through SSL and a public key certificate provided by Oracle.

   • Cert mode means encryption through SSL and a public key certificate provided by an external CA.

   For example, a sample Access Server configuration, GlassfishAS, is shown in Figure 7-6.

   Figure 7-6 Sample Access Server Configuration (Partial Screen)

   
   Description of "Figure 7-6 Sample Access Server Configuration (Partial Screen)"
   
   

6. Create Access Gate configuration.

   From the Access System Configuration tab of the Access System Console, create an Access Gate configuration.

   Provide the required parameters including Name, Hostname (name of the system that will host the AccessGate), and enable it. For example, a sample AccessGate configuration, GlassfishAG, is shown in Figure 7-7.

   Figure 7-7 Sample AccessGate Configuration (Partial Screen)

   
   Description of "Figure 7-7 Sample AccessGate Configuration (Partial Screen)"
   
   

7. Associate Access Gate and Access Server.

   From the Access System Configuration tab of the Access System Console, associate the Access Gate and the Access Server.

   To do this, from the AccessGate configuration page, click List Access Servers and then add the Access Server you previously created.

   Figure 7-8 Associating Access Server with Access Gate

   
   Description of "Figure 7-8 Associating Access Server with Access Gate"
   
   

8. Add Host Identifiers.

   From the Access System Configuration tab of the Access System Console, add one or more host identifiers.

   You use Host identifiers to simplify the identification of a Web server that hosts resources you want to protect with Access Manager.

   For example, when you added the configuration for the AccessGate, assume that you used the hostname of the system hosting the AccessGate. You might want to add a host identifier for the IP address or the fully-qualified domain name of the system hosting the AccessGate.

   Figure 7-9 Adding a Hostname Identifier for the AccessGate System

   
   Description of "Figure 7-9 Adding a Hostname Identifier for the AccessGate System"
   
   

9. Create an Authentication Scheme.

   From the Access System Configuration tab of the Access System Console, create an authentication scheme for each login mechanism.

   Create an authentication scheme for each login mechanism (BASIC, Form, client cert) that you want to use to protect the resource, save it, and then add a credential mapping plug-in (from the Plugins tab) for the authentication scheme.

   For BASIC authentication, the credential mapping plug-in maps the LDAP attributes of the user (shown in the figure as genuserid=%userid% and obCredentialPassword) with the challenge parameters (shown in the figure as realm:LDAP User Name/Password) of the authentication scheme, and they must match.

   Figure 7-10 and Figure 7-11 show a sample BASIC over LDAP authentication scheme, and the respective plug-ins.

   Figure 7-10 BASIC Authentication Scheme

   
   Description of "Figure 7-10 BASIC Authentication Scheme "
   
   

   Figure 7-11 Plug-Ins for BASIC Authentication Scheme

   
   Description of "Figure 7-11 Plug-Ins for BASIC Authentication Scheme"
   
   

   For client cert authentication, a sample authentication scheme is shown in Figure 7-12.

   In this mapping, the LDAP attribute employeetype is mapped to the certificate subject certSubject.CN.

   Figure 7-12 Client Cert Authentication Scheme

   
   Description of "Figure 7-12 Client Cert Authentication Scheme"
   
   

   For client cert authentication, the associated plug-in configuration is shown in Figure 7-13.

   Figure 7-13 Plug-Ins for Client Cert Authentication Scheme

   
   Description of "Figure 7-13 Plug-Ins for Client Cert Authentication Scheme"
   
   

10. Create a Policy Domain.

    From the Policy Manager, create a policy domain.

    The Policy Manager application allows you to create, remove and manage policies and resources and test policy enforcement.

    Before a policy domain can control access to your resources, you must:

    1. Add a resource to be protected.

       From the Resources tab, click Add. Select the host identifier for the system that hosts the AccessGate and the resource to be protected.

       The URL prefixes provide the pathway to your Web resources. A policy domain can contain one or more URL prefixes. The available URL prefixes depend on the resource type you selected. You can also specify a unique URL prefix in the associated text field; for example, glassfish-default.

       If you want to use the Policy Manager authorization function to protect resources, you can configure the resources individually. If you want to use GlassFish Server for authorization, and use Oracle Access Manager only for authentication

    2. Add an authentication rule.

       From the Default Rules tab, select the Authentication Rule tab and add enter an authentication rule. Choose the authentication scheme you configured in Step 9. For example, Basic Over LDAP.

    3. Create one or more authorization rules.

       From the Authorization Rules tab, click Add and enter an authorization rule. Save the change. Then, from the Allow Access tab, add the user or group you created in Step 3 and Step 4.

    4. Create an authorization expression.

       From the Default Rules tab, select the Authorization Expression tab. Click Add to add an authorization expression.

    5. Optionally, create one or more policies to fine-tune access control for the resource.

       Provide a name, choose the operations for the policy, and choose the configured resource (Host Identifier and URL Prefix).

11. Download and unzip the Oracle Access Server SDK.

    You can download the SDK from Oracle Identity Management 10g (10.1.4.x) Downloads.

    Select Oracle Access Manager Core Components (10.1.4.3.0) (Disk1).

    The Access Server SDK allows Java, C++, and C applications to use the services of the Oracle Access Manager , including user authentication and authorization of user requests to access resources protected by Oracle Access Manager.

    The following components are installed from the zip file:

    • oamcfgtool_10_1_4_3_0.zip

    • Oracle_Access_Manager10_1_4_3_0_Win32-dotnet20_AccessServerSDK.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_AccessServerSDK.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_Access_Server.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_Identity_Server.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_OHS11g_Policy_Manager.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_OHS11g_WebPass.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_Snmp_Agent.exe

12. Run the installation wizard.

    Run Oracle_Access_Manager10_1_4_3_0_Win32_AccessServerSDK.exe on the system from which you intend to run the GlassFish Server hosted application and follow the installation wizard.

    Note:

    Depending on the platform, additional steps may be required to configure the AccessServerSDK, such as setting LD_LIBRARY_PATH and so forth. Please consult the ASDK_README.htm file under installdirectory\AccessServerSDK for more details.

13. Configure the AccessServer SDK.

    Configure the AccessServer SDK to facilitate the handshake between the AccessGate you created and Oracle Access Manager.

    To do this, run the utility configureAccessGate.exe, located in installdirectory\AccessServerSDK\oblix\tools\configureAccessGate, where installdirectory is the root folder for your Access Manager SDK installation.

    configureAccessGate -i <AccessServerSDK-install-dir> 
    -t AccessGate -w GlassfishAG -m open -h access-server-host-name -p 6021 -a GlassfishAS
    
    Please enter the Password for this AccessGate :
    
    Preparing to connect to Access Server.  Please wait.
    
    AccessGate installed Successfully.
    

    The command line parameters shown are as follows:

    Parameter	Description
    -i	Installation directory for AccessServerSDK.
    -t	AccessGate keyword. Enter as shown.
    -w	AccessGate name you specified when you created the AccessGate entry in Oracle Access Manager.
    -m	Oracle Access Manager intercomponent mode. This is the security mode you specified between the WebGate/Access client and the Access Server. The valid values are open, simple, or cert. Open mode means no encryption. Simple mode means encryption through SSL and a public key certificate provided by Oracle. Cert mode means encryption through SSL and a public key certificate provided by an external CA.
    -h	Fully-qualified name of the host on which you installed the Access Server.
    -p	Port on which the Access Server is running.
    -a	The Access Server name you created in Oracle Access Manager.

    
    

    You may also need to enter an Access Server password (-r AccessServerpassphrase) and an AccessGate password (-P AccessGatePwd) if you created them in Oracle Access Manager.

14. Add JVM Options.

    In the GlassFish Server JVM options, add the following entry:

    <jvm-options>-DOBACCESS_INSTALL_DIR=<AccessServerSDK-install-dir></jvm-options>
    

    You can use the create-jvm-options command to do this. Consider the following example:

    asadmin --port 4848 --host localhost create-jvm-options
     -DOBACCESS_INSTALL_DIR=D\:\\\\"program files"\\NetPoint\\AccessServerSDK
    

15. Copy jobaccess.jar.

    Copy jobacces.jar from from installdirectory\AccessServerSDK\oblix\lib into <Glassfish>\lib.

16. Verify the location of the OAM Security Provider.

    Ensure that the OAM Security Provider, oam-integration.jar, is in <Glassfish>\lib.

17. Configure the OAM Security Provider.

    1. Define your SAM as a message-security-provider.

       You can use either the Administration Console or the create-message-security-provider command to do this. Consider the following example:

       <message-security-config auth-layer="HttpServlet">
       <provider-config provider-type="server" provider-id="mysam" 
       class-name="com.sun.glassfish.oamsam.OAMAuthenticatorSAM">
       <property name="oam.resource.hostid.variation" value="your-system.com" />
       <!--property name="form.login.page" value="" /-->
       </provider-config>
       </message-security-config>
       

    2. Bind the OAM Security Provider.

       Bind the OAM Security Provider for use with your application. You do this by defining the httpservlet-security-provider attribute in the glassfish-web.xml file corresponding to your application.

       Set the value of the attribute to the name you assigned to the OAM Security Provider in Step a. For example, MySAM.

       The group name you specify must match the group name you specified in Oracle Access Manager.

       <?xml version="1.0" encoding="UTF-8"?>
       <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application 
       Server 9.0
       Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/
       sun-web-app_2_5-0.dtd">
       <sun-web-app error-url="" httpservlet-security-provider="MySAM">
       <context-root>/BasicAuthen</context-root>
       <security-role-mapping>
       <role-name>glassfish</role-name>
       <group-name>Glassfish_group</group-name>
       <group-name>cn=Glassfish_group,ou=groups,ou=myrealm,dc=oam_domain</group-name>
       </security-role-mapping>
       <class-loader delegate="true"/>
       <jsp-config>
       <property name="keepgenerated" value="true">
       <description>Keep a copy of the generated servlet class' java code.</description>
       </property>
       </jsp-config>
       </sun-web-app>
       

18. Deploy the application.

    Deploy the application you want to protect in GlassFish Server.

19. Add SDK_install_dir\oblix\lib to the Path.

20. Configure LDAPRealm.

    Configure the LDAPRealm in GlassFish Server to point to Oracle Access Manager backend, as described in Obtaining Oracle Access Manager Group Information. For example, you can use the Administration Console or the create-auth-realm command to add the following entry:

    <auth-realm 
    classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm" name="ldaprealm">
              <property name="jaas-context" value="ldapRealm" />
              <property name="base-dn" value="o=company,c=us" />
              <property name="directory" value="ldap://140.87.134.98:1389" />
              <property name="search-bind-dn" value="cn=Directory Manager" />
              <property name="search-bind-password" value="welcome1" />
            </auth-realm>
    

21. Make the LDAPRealm the default realm in GlassFish Server.

    <security-service default-realm="ldaprealm">
    

22. Restart GlassFish Server.

    Restart GlassFish Server and access the protected resource from a browser, such as http://hostname.domainname:8080/BasicAuthen/SecureServlet.

Integrating OAM Security Provider with Oracle Access Manager 11g

This procedure explains how to integrate the OAM Security Provider with Oracle Access Manager 11g.

See the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for detailed instructions on Access Manager tasks.

The procedure was tested on Microsoft Windows and the file names are those of the Windows version.

This procedure focuses on LDAP authentication. See Addtional Considerations for Certificate Authentication for information on X509 authentication.

1. Install and configure Oracle Identity and Access Management 11g.

2. Create OAM Server instance.

   If you have not already done so, create an OAM Server instance.

   Under System Configuration, from the left navigation pane select Server Instances and then click the Create command button in the tool bar. The Create: OAM Server page appears.

   When you create an OAM Server instance, you specify the transport security mode to use between an OAM Agent and this OAM Server instance, from the following choices. See "Securing Communication Between OAM 11g Servers and WebGates" in the Access Manager online help for a description of these modes and how to use them.

   • Open

   • Simple

   • Cert

   For example, consider the OAM Server instance shown in Figure 7-25.

   Figure 7-14 OAM Server Instance

   
   Description of "Figure 7-14 OAM Server Instance"
   
   

3. Create a 10g Webgate.

   Under System Configuration, from the left navigation pane select SSO Agents and then OAM Agents. Click Create 10g Webgate. The Create OAM 10g Webgate screen appears.

   The security mode you choose must match that of the OAM Server instance.

   The Create OAM 10g Webgate screen is shown in Figure 7-15.

   Figure 7-15 10g Webgate

   
   Description of "Figure 7-15 10g Webgate"
   
   

4. Create one or more Host Identifiers.

   You use Host identifiers to simplify the identification of a Web server that hosts resources you want to protect with Access Manager.

   From the Policy Configuration tab, expand the Shared Components node, and then select Host Identifiers. Click the Create command button in the tool bar.

   Figure 7-16 shows an example host identifier GlassfishTestClient to be used for systems that require BASIC and FORM authentication.

   Figure 7-16 GlassfishTestClient Host Identifier

   
   Description of "Figure 7-16 GlassfishTestClient Host Identifier"
   
   

5. Create a User Identity Store

   From the System Configuration tab, select Data Sources. Expand Data Sources and click User Identity Stores. Click the Create command button in the tool bar.

   The User Identity Store specifies the LDAP provider it is associated with, as shown in Figure 7-17. This LDAP provider can be the Oracle WebLogic embedded LDAP provider, or another supported provider from the drop-down menu that you have previously configured.

   Figure 7-17 LDAP Provider of Identity Store

   
   Description of "Figure 7-17 LDAP Provider of Identity Store"
   
   

   For LDAP providers other than the embedded LDAP provider, when you create a User Identify Store based on one of these LDAP providers, you specify identifying properties, such as the User Search Base and the User Name Attribute that you will need later in this procedure to configure the GlassFish Server LDAPRealm. For example, Figure 7-18 shows the User Identity Store screen for the Oracle Internet Directory LDAP Provider.

   Figure 7-18 OID LDAP Provider

   
   Description of "Figure 7-18 OID LDAP Provider"
   
   

   For the embedded LDAP provider, the identifying properties are not available from the Access Manager user interface. You therefore need to use some other LDAP tool to configure these properties when you create a user in the next step.

6. Create a group and user in the LDAP provider.

   Create a group and user in the LDAP provider who will have access to the protected resource.

   Later in this procedure you need to configure the GlassFish Server LDAPRealm, and to do this you will need identifying LDAP properties that are not available for the embedded LDAP provider from the Access Manager user interface.

   If you want to use the embedded LDAP provider, you will therefore need to use some other LDAP tool to configure these properties. For example, you might use LDAP commands to add the user and group, and to search the LDAP database for them:

   ldapadd -x -h cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" 
   -w welcome1 -f gadd.ldif
   ldapadd -x -h cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" -w welcome1 -f uadd.ldif
   ldapsearch -x -h   cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" -w welcome1 -s sub 
   -b "ou=people,ou=myrealm,dc=oam_domain"
   ldapsearch -x -h   cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" -w welcome1 -s sub 
   -b "ou=groups,ou=myrealm,dc=oam_domain"
   

   In this example, the contents of the "user add" file uadd.ldif that adds the user Glassfish might be as follows:

   # GlassFish, people, myrealm, oam_domain
   dn: uid=GlassFish,ou=people,ou=myrealm,dc=oam_domain
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
       objectclass: inetOrgPerson
   objectclass: wlsUser
   cn: GlassFish
   sn: GlassFish
   uid: GlassFish
   description: GlassFish User
   wlsMemberOf: cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain
   userpassword: GlassFish
   

   The contents of the "group add" file gadd.ldif that adds a GlassFish_Group might be as follows:

   dn: cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain
   objectclass: top
   objectclass: groupOfURLs
   objectclass: groupOfUniqueNames
   cn: GlassFish_Group
   description: OAM GlassFish Group
   memberURL: ldap:///ou=people,ou=myrealm,dc=oam_domain??
   sub?(&(objectclass=person)(wlsMemberOf=cn=GlassFish_Group,ou=groups,ou=myrealm,
   dc=oam_domain))
   

   Make a note of sufficient properties to uniquely identity the user, such as wlsMemberOf, as you will need them later in this procedure when you configure the LDAPRealm.

7. Create an Authentication Module.

   From the System Configuration tab, select Authentication Modules. Expand Authentication Modules and select LDAP Authentication Modules. Click the Create command button in the tool bar.

   Specify a name for this Authentication Module, and select the User Identity Store you previously created, as shown in Figure 7-19

   Figure 7-19 LDAP Authentication Module

   
   Description of "Figure 7-19 LDAP Authentication Module"
   
   

8. Create an Authentication Scheme.

   Create an authentication scheme for each challenge method (BASIC, Form, and X.509) that you want to use to protect the resource.

   From the Policy Configuration tab, expand the Shared Components node, and then select Authentication Schemes. Click the Create command button in the tool bar.

   The Authentication Module must already exist.

   Figure 7-20 shows an example BASIC over LDAP authentication scheme.

   Figure 7-20 BASIC Over LDAP Authentication Scheme

   
   Description of "Figure 7-20 BASIC Over LDAP Authentication Scheme"
   
   

9. Create one or more Application Domains.

   From the Policy Configuration tab, select Application Domains. Click the Create command button in the tool bar to create an Application Domain. An example Application Domain is shown in Figure 7-21.

   Figure 7-21 Application Domain

   
   Description of "Figure 7-21 Application Domain"
   
   

   Before an application domain can control access to your resources, you must now identify those resources and specify how you want to protect them:

   1. Add a resource to be protected.

      From the Policy Configuration tab, expand Application Domains and select the domain you just created. Select Resources, and click the Create command button in the tool bar. On the Create resource page:

      Select HTTP as the resource type.

      Select the host identifier (described in Step 4) for the system that hosts the resource to be protected.

      Specify the resource URL for the Web resource. The URL value of a resource must begin with a forward slash (/), for example /BasicAuthen/SecureServlet, and must match a resource value for the chosen host identifier. To protect all of the resource URLs, append "/.../*". For example, /BasicAuthen/SecureServlet/.../*.

      Figure 7-22 shows an example of creating a resource that uses a host identifier named GlassfishTestClient.

      Figure 7-22 Creating a Resource

      
      Description of "Figure 7-22 Creating a Resource"
      
      

   2. Add an Authentication Policy.

      From the Policy Configuration tab, expand Application Domains and select the domain you just created. Select Authentication Policies, and click the Create command button in the tool bar. On the Create Authentication Policies page:

      Name this Authentication Policy.

      Select a named authentication scheme you previously configured.

      Select the resources you want to protect with this Authentication Policy.

      Figure 7-23 shows an example of creating an Authentication Policy that uses the BasicScheme authentication scheme.

      Figure 7-23 Authentication Policy

      
      Description of "Figure 7-23 Authentication Policy"
      
      

   3. Optionally, create one or more Authorization Policies.

      Note:

      The OAM 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access. In contrast, the OAM 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly denied access to limit the number of WebGate queries to the Access Server.

      From the Policy Configuration tab, expand Application Domains and select the domain you just created. Select Authorization Policies, and click the Create command button in the tool bar. On the Create Authorization Policies page:

      Name this Authorization Policy.

      Select the resource to be protected by this Authorization Policy.

      Set the Use Implied Restraints control, or explicitly set constraints on the Constraints tab.

      Figure 7-24 shows an example Authorization Policy with two protected resources.

      Figure 7-24 Authorization Policy

      
      Description of "Figure 7-24 Authorization Policy"
      
      

10. Download and unzip the Oracle Access Server SDK.

    You can download the SDK from Oracle Identity Management 10g (10.1.4.x) Downloads.

    Select Oracle Access Manager Core Components (10.1.4.3.0) (Disk1).

    The Access Server SDK allows Java, C++, and C applications to use the services of the Oracle Access Manager , including user authentication and authorization of user requests to access resources protected by Oracle Access Manager.

    The following components are available from the zip file:

    • oamcfgtool_10_1_4_3_0.zip

    • Oracle_Access_Manager10_1_4_3_0_Win32-dotnet20_AccessServerSDK.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_AccessServerSDK.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_Access_Server.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_Identity_Server.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_OHS11g_Policy_Manager.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_OHS11g_WebPass.exe

    • Oracle_Access_Manager10_1_4_3_0_Win32_Snmp_Agent.exe

11. Run the installation wizard.

    Oracle_Access_Manager10_1_4_3_0_Win32_AccessServerSDK.exe on the system from which you intend to run the GlassFish Server hosted application and follow the installation wizard.

    Note:

    Depending on the platform, additional steps may be required to configure the AccessServerSDK, such as setting LD_LIBRARY_PATH and so forth. Please consult the ASDK_README.htm file under installdirectory\AccessServerSDK for more details.

12. Configure the AccessServer SDK.

    Configure the AccessServer SDK to facilitate the handshake between the WebGate you created and Oracle Access Manager.

    To do this, run the utility configureAccessGate.exe, located in installdirectory\AccessServerSDK\oblix\tools\configureAccessGate, where installdirectory is the root folder for your Access Manager SDK installation.

    configureAccessGate -i <AccessServerSDK-install-dir> 
    -t AccessGate -w GlassfishAG -m open -h access-server-host-name -p 5575 -a oam_server1
    
    Please enter the Password for this AccessGate :
    
    Preparing to connect to Access Server.  Please wait.
    
    AccessGate installed Successfully.
    

    The command line parameters shown are as follows:

    Parameter	Description
    -i	Installation directory for AccessServerSDK.
    -t	AccessGate keyword. Enter as shown.
    -w	Name you specified when you created the WebGate entry in Oracle Access Manager.
    -m	Oracle Access Manager intercomponent mode. This is the security mode you specified between the WebGate/Access client and the OAM Server instance. The valid values are open, simple, or cert. Open mode means no encryption. Simple mode means encryption through SSL and a public key certificate provided by Oracle. Cert mode means encryption through SSL and a public key certificate provided by an external CA.
    -h	Fully-qualified name of the host on which you installed the OAM Server instance.
    -p	Port on which the OAM Server instance is running.
    -a	The OAM Server instance name you created in Oracle Access Manager.

    
    

    You may also need to enter an OAM Server password (-r AccessServerpassphrase) and an AccessGate password (-P AccessGatePwd) if you created them in Oracle Access Manager.

13. Update JVM options

    In the GlassFish Server JVM options, add the following entry:

    <jvm-options>-DOBACCESS_INSTALL_DIR=<AccessServerSDK-install-dir></jvm-options>
    

    You can use the create-jvm-options command to do this. Consider the following example:

    asadmin --port 4848 --host localhost create-jvm-options
     -DOBACCESS_INSTALL_DIR=D\:\\\\"program files"\\NetPoint\\AccessServerSDK
    

14. Copy jobacces.jar.

    Copy jobaccess.jar from from installdirectory\AccessServerSDK\oblix\lib into <Glassfish>\lib.

15. Verify the location of the OAM Security Provider.

    Ensure that oam-integration.jar is in <Glassfish>\lib.

16. Configure the OAM Security Provider.

    1. Define your SAM as a message-security-provider.

       You can use either the Administration Console or the create-message-security-provider command to do this. Consider the following examples:

       For BASIC authentication

       <message-security-config auth-layer="HttpServlet">
                 <provider-config provider-type="server" provider-id="mysam" 
       class-name="com.sun.glassfish.oamsam.OAMAuthenticatorSAM">
                   <property name="oam.resource.hostid.variation" 
       value="your-host-name" />
                 </provider-config>
               </message-security-config>
       

       For Form authentication, you might want to set the form.login.property.

       message-security-config auth-layer="HttpServlet">
                 <provider-config provider-type="server" provider-id="mysam" 
       class-name="com.sun.glassfish.oamsam.OAMAuthenticatorSAM">
                   <property name="oam.resource.hostid.variation" 
       value="your-host-name" />
                   <property name="form.login.page" value="" />
                 </provider-config>
               </message-security-config>
       

    2. Bind the OAM Security Provider for use with your application.

       You do this by defining the httpservlet-security-provider attribute in the glassfish-web.xml file corresponding to your application.

       Set the value of the attribute to the name you assigned to the OAM Security Provider in Step a. For example, MySAM.

       The group name you specify must match the group name you specified in the LDAP provider. For example, GlassFish_Group.

       <?xml version="1.0" encoding="UTF-8"?>
       <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application 
       Server 9.0
       Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/
       sun-web-app_2_5-0.dtd">
       <sun-web-app error-url="" httpservlet-security-provider="MySAM">
       <context-root>/BasicAuthen</context-root>
       <security-role-mapping>
       <role-name>glassfish</role-name>
       <group-name>GlassFish_Group</group-name>
       <group-name>cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain</group-name>
       </security-role-mapping>
       <class-loader delegate="true"/>
       <jsp-config>
       <property name="keepgenerated" value="true">
       <description>Keep a copy of the generated servlet class' java code.</description>
       </property>
       </jsp-config>
       </sun-web-app>
       

17. Deploy the application you want to protect in GlassFish Server.

18. Add SDK_install_dir\oblix\lib to the Path.

19. Configure the LDAPRealm.

    Configure the LDAPRealm in GlassFish Server to point to the Access Manager LDAP provider and group you specified to authenticate the user.

    The properties you enter here must match that of the LDAP provider.

    For example, you can use the Administration Console or the create-auth-realm command to add the following entry:

    <auth-realm classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm" 
    name="ldaprealm">
              <property name="jaas-context" value="ldapRealm"></property>
              <property name="base-dn" value="ou=people,ou=myrealm,dc=oam_domain"></property>
              <property name="directory" value="ldap://cieqalnx01.us.oracle.com:7001"></property>
              <property name="group-search-filter" value="cn=%s"></property>
              <property name="group-target" value="wlsMemberOf"></property>
              <property name="search-bind-dn" value="cn=Admin"></property>
              <property name="search-bind-password" value="welcome1"></property>
            </auth-realm>
    

20. Make the LDAPRealm the default realm in GlassFish Server.

    <security-service default-realm="ldaprealm">
    

21. Restart GlassFish Server.

    Restart GlassFish Server and access the protected resource, such as http://hostname.domainname:8080/BasicAuthen/SecureServlet.

Addtional Considerations for Certificate Authentication

In addition to the procedure described in Integrating OAM Security Provider with Oracle Access Manager 11g, there are additional steps required if you want to use certificate authentication to protect your resource.

• The X.509 root certificate and the CA certificate you plan to use for Authentication to the OAM Server must be in the GlassFish Server trust store for the domain.

• The X.509 root certificate and the CA certificate you plan to use for Authentication to the OAM Server must also be in the OAM Server keystore. See Importing CA-Signed Certificates Into the Keystore for instructions on how to do this.

• The X.509 certificate you use for authentication must map to a valid user. To do this, create a user in the Access Manager LDAP provider whose CN attribute matches that of the subject.CN from the certificate.

  Consider the following example, which adds the user Alice. The subject.CN from the certificate must therefore be Alice.

  #ldapadd -x -h cieqalnx01.us.oracle.com -p 7001 
  -D"cn=Admin" -w welcome1 -f uadd.ldif
  

  In this example, the contents of uadd.ldif are as follows:

  #contents of uaddalice.ldif
  # GlassFish, people, myrealm, oam_domain
  dn: uid=Alice,ou=people,ou=myrealm,dc=oam_domain
  objectclass: top
  objectclass: person
  objectclass: organizationalPerson
  objectclass: inetOrgPerson
  objectclass: wlsUser
  cn: Alice
  sn: Alice
  uid: Alice
  description: GlassFish End User
  wlsMemberOf: cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain
  userpassword: Alice
  

• Create an X509 Authentication Module. Make sure that the Match LDAP Attribute is set to cn, and that the X509 Cert Attribute is Subject.CN. Set CertValidationEnabled to true. Consider the following example.

  
  Description of the illustration x509-auth-module.png
  
  

• Create an Authentication Scheme that uses the X509 Challenge Method, and the X509 Authentication Module you just created.

  Remember that the WebGate challenges the user for credentials based on the type of OAM Server authentication scheme configured for the resource, which is X509 in this case.

  Set the Challenge URL to the SSL port of OAM server. For example, https://<oam_server>:<ssl_port>/oam/CredCollectServlet/X509.

  Note:

  To work around a known problem, the name of the Authentication Scheme must contain either or both of the (case sensitive) words "X509" and "Certificate".

  Consider the following example.

  
  Description of the illustration authentication-scheme-certif.png
  
  

• Configure the OAM Security Provider. To do this, define your SAM as a message-security-provider. You can use either the Administration Console or the create-message-security-provider command to do this. Consider the following example:

  For Ceritificate Auth :
        <message-security-config auth-layer="HttpServlet">
        <provider-config provider-type="server" provider-id="mysam" 
  class-name="com.sun.glassfish.oamsam.OAMAuthenticatorSAM">
              <property description="" name="oam.resource.hostid.variation" 
  value="129.158.239.142"></property>
            </provider-config>
        </message-security-config>
     
  

• Modify the http-listener-2 configuration in domain.xml as follows:

  <ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" 
  ssl3-enabled="false" cert-nickname="s1as" client-auth-enabled="true"></ssl>
  

Integrating OAM Security Provider with Oracle Access Manager 11g and WebGate

This procedure explains how to integrate the OAM Security Provider with Oracle Access Manager 11g and a WebGate.

See the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for detailed instructions on Access Manager tasks.

The procedure was tested on Microsoft Windows and the file names are those of the Windows version.

1. Install and configure Oracle Identity and Access Management 11g.

2. Install Oracle HTTP Server.

   If you have not already done so, install a version of Oracle HTTP Server (OHS) that is compatible with your Oracle Identity and Access Management installation.

   OHS is available from the Oracle Middleware Downloads page. Look for "Web Tier Utilities" under "Required Additional Software." Note that you need to install the complete Web Tier Utilities bundle because OHS is not available separately.

3. Create an OAM Server instance.

   If you have not already done so, create an OAM Server instance.

   Under System Configuration, from the left navigation pane select Server Instances and then click the Create command button in the tool bar. The Create: OAM Server page appears.

   When you create an OAM Server instance, you specify the transport security mode to use between an OAM Agent and this OAM Server instance, from the following choices. See "Securing Communication Between OAM 11g Servers and WebGates" in the Access Manager online help for a description of these modes and how to use them.

   • Open

   • Simple

   • Cert

   For example, consider the OAM Server instance shown in Figure 7-25.

   Figure 7-25 OAM Server Instance

   
   Description of "Figure 7-25 OAM Server Instance"
   
   

4. Create a User Identity Store

   From the System Configuration tab, select Data Sources. Expand Data Sources and click User Identity Stores. Click the Create command button in the tool bar.

   The User Identity Store specifies the LDAP provider it is associated with, as shown in Figure 7-26. This LDAP provider can be the Oracle WebLogic embedded LDAP provider, or another supported provider from the drop-down menu that you have previously configured.

   Figure 7-26 LDAP Provider of Identity Store

   
   Description of "Figure 7-26 LDAP Provider of Identity Store"
   
   

   For LDAP providers other than the embedded LDAP provider, when you create a User Identify Store based on one of these LDAP providers, you specify identifying properties, such as the User Search Base and the User Name Attribute that you will need later in this procedure to configure the GlassFish Server LDAPRealm. For example, Figure 7-27 shows the User Identity Store screen for the Oracle Internet Directory LDAP Provider.

   Figure 7-27 OID LDAP Provider

   
   Description of "Figure 7-27 OID LDAP Provider"
   
   

   For the embedded LDAP provider, the identifying properties are not available from the Access Manager user interface. You therefore need to use some other LDAP tool to configure these properties when you create a user in the next step.

5. Create groups and users in the LDAP provider.

   Create a group and user in the LDAP provider who will have access to the protected resource.

   Later in this procedure you need to configure the GlassFish Server LDAPRealm, and to do this you will need identifying LDAP properties that are not available for the embedded LDAP provider from the Access Manager user interface.

   If you want to use the embedded LDAP provider, you will therefore need to use some other LDAP tool to configure these properties. For example, you might use LDAP commands to add the user and group, and to search the LDAP database for them:

   ldapadd -x -h cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" 
   -w welcome1 -f gadd.ldif
   ldapadd -x -h cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" -w welcome1 -f uadd.ldif
   ldapsearch -x -h   cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" -w welcome1 -s sub 
   -b "ou=people,ou=myrealm,dc=oam_domain"
   ldapsearch -x -h   cieqalnx01.us.oracle.com -p 7001 -D"cn=Admin" -w welcome1 -s sub 
   -b "ou=groups,ou=myrealm,dc=oam_domain"
   

   In this example, the contents of the "user add" file uadd.ldif that adds the user Glassfish might be as follows:

   # GlassFish, people, myrealm, oam_domain
   dn: uid=GlassFish,ou=people,ou=myrealm,dc=oam_domain
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
       objectclass: inetOrgPerson
   objectclass: wlsUser
   cn: GlassFish
   sn: GlassFish
   uid: GlassFish
   description: GlassFish User
   wlsMemberOf: cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain
   userpassword: GlassFish
   

   The contents of the "group add" file gadd.ldif that adds a GlassFish_Group might be as follows:

   dn: cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain
   objectclass: top
   objectclass: groupOfURLs
   objectclass: groupOfUniqueNames
   cn: GlassFish_Group
   description: OAM GlassFish Group
   memberURL: ldap:///ou=people,ou=myrealm,dc=oam_domain??
   sub?(&(objectclass=person)(wlsMemberOf=cn=GlassFish_Group,ou=groups,ou=myrealm,
   dc=oam_domain))
   

   Make a note of sufficient properties to uniquely identity the user, such as wlsMemberOf, as you will need them later in this procedure when you configure the LDAPRealm.

6. Create an Authentication Module.

   From the System Configuration tab, select Authentication Modules. Expand Authentication Modules and select LDAP Authentication Modules. Click the Create command button in the tool bar.

   Specify a name for this Authentication Module, and select the User Identity Store you previously created, as shown in Figure 7-28

   Figure 7-28 LDAP Authentication Module

   
   Description of "Figure 7-28 LDAP Authentication Module"
   
   

7. Create an Authentication Scheme.

   Create an authentication scheme for each challenge method (BASIC, Form, and X.509) that you want to use to protect the resource.

   From the Policy Configuration tab, expand the Shared Components node, and then select Authentication Schemes. Click the Create command button in the tool bar.

   The Authentication Module must already exist.

   Figure 7-29 shows an example BASIC over LDAP authentication scheme.

   Figure 7-29 BASIC Over LDAP Authentication Scheme

   
   Description of "Figure 7-29 BASIC Over LDAP Authentication Scheme"
   
   

8. Create one or more Application Domains.

   From the Policy Configuration tab, select Application Domains. Click the Create command button in the tool bar to create an Application Domain. An example Application Domain is shown in Figure 7-30.

   Figure 7-30 Application Domain

   
   Description of "Figure 7-30 Application Domain"
   
   

   Before an application domain can control access to your resources, you must now identify those resources and specify how you want to protect them:

   1. Add a resource to be protected.

      From the Policy Configuration tab, expand Application Domains and select the domain you just created. Select Resources, and click the Create command button in the tool bar. On the Create resource page:

      Select HTTP as the resource type.

      Select the host identifier (described in Step 5) for the system that hosts the resource to be protected.

      Specify the resource URL for the Web resource. The URL value of a resource must begin with a forward slash (/), for example /BasicAuthen/SecureServlet, and must match a resource value for the chosen host identifier. To protect all of the resource URLs, append "/.../*". For example, /BasicAuthen/SecureServlet/.../*.

      Figure 7-31 shows an example of creating a resource that uses a host identifier named GlassfishTestClient.

      Figure 7-31 Creating a Resource

      
      Description of "Figure 7-31 Creating a Resource"
      
      

   2. Add an Authentication Policy.

      From the Policy Configuration tab, expand Application Domains and select the domain you just created. Select Authentication Policies, and click the Create command button in the tool bar. On the Create Authentication Policies page:

      Name this Authentication Policy.

      Select a named authentication scheme you previously configured.

      Select the resources you want to protect with this Authentication Policy.

      Figure 7-32 shows an example of creating an Authentication Policy that uses the BasicScheme authentication scheme.

      Figure 7-32 Authentication Policy

      
      Description of "Figure 7-32 Authentication Policy"
      
      

   3. Optionally, create one or more Authorization Policies.

9. Configure the Oracle HTTP Server WebGate and Register the WebGate Agent.

   You configure the Oracle HTTP Server WebGate on the system where the Oracle HTTP Server is installed.

   Oracle HTTP Server WebGate is a Web server plug-in that is shipped out-of-the-box with Oracle Access Manager. The Oracle HTTP Server WebGate intercepts HTTP requests from users for Web resources and forwards them to the Access Server for authentication and authorization. Oracle HTTP Server WebGate installation packages are found on media and virtual media that are separate from the core components.

   For complete instructions, see Installing and Configuring Oracle HTTP Server 11g Webgate for OAM.

10. Configure Oracle HTTP Server and Restart

    Edit mod_wl_ohs.conf to configure the redirect host and port (WebLogicHost and WebLogicPort, respectively) to point to the GlassFish Server instance in which the secured application will run. Consider the following example:

    <Location /BasicAuthen/SecureServlet>
    SetHandler weblogic-handler
    WebLogicHost host-name-where-GlassFish-running
    WebLogicPort 8080
    DebugConfigInfo on
    </Location>
    

    After you have edited the file, restart Oracle HTTP server.

11. Verify the location of the OAM Security Provider.

    Ensure that oam-integration.jar is in <Glassfish>\lib.

12. Configure the OAM Security Provider.

    1. Define your SAM as a message-security-provider.

       You can use either the Administration Console or the create-message-security-provider subcommand to do this. Consider the following example:

       <message-security-config auth-layer="HttpServlet">
                 <provider-config provider-type="server" provider-id="mysam" 
                        class-name="com.sun.glassfish.oamsam.OAMAuthenticatorSAM">
                   <property name="oam.base.dn" value="ou=people,ou=myrealm,dc=oam_domain"></property>
                   <property name="oam.ext.header" 
                      value="OAM_REMOTE_USER"></property>
                   <property name="IdentityAsserterMode" 
                      value="true"></property>
                 </provider-config>
               </message-security-config>
       

       The OAM Security Provider acts as an Identity Asserter only when IdentityAsserterMode is set to true. This example also shows the (OAM_REMOTE_USER) header. The value of the base-dn must point to the user's base-dn you configured in Step 5.

    2. Bind the OAM Security Provider for use with your application.

       You do this by defining the httpservlet-security-provider attribute in the glassfish-web.xml file corresponding to your application.

       Set the value of the attribute to the name you assigned to the OAM Security Provider in Step a. For example, MySAM.

       The group name you specify must match the group name you specified in the LDAP provider. For example, GlassfFish_Group.

       <?xml version="1.0" encoding="UTF-8"?>
       <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application 
       Server 9.0
       Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/
       sun-web-app_2_5-0.dtd">
       <sun-web-app error-url="" httpservlet-security-provider="MySAM">
       <context-root>/BasicAuthen</context-root>
       <security-role-mapping>
       <role-name>glassfish</role-name>
       <group-name>GlassFish_Group</group-name>
       <group-name>cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain</group-name>
       </security-role-mapping>
       <class-loader delegate="true"/>
       <jsp-config>
       <property name="keepgenerated" value="true">
       <description>Keep a copy of the generated servlet class' java code.</description>
       </property>
       </jsp-config>
       </sun-web-app>
       

13. Deploy the application you want to protect in GlassFish Server.

14. Configure the LDAPRealm.

    Configure the LDAPRealm in GlassFish Server to point to the Access Manager LDAP provider and group you specified to authenticate the user.

    GlassFish Server directly contacts this LDAP provider for group information.

    The properties you enter here must match that of the LDAP provider.

    For example, you can use the Administration Console or the create-auth-realm command to add the following entry:

    <auth-realm classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm" 
    name="ldaprealm">
              <property name="jaas-context" value="ldapRealm"></property>
              <property name="base-dn" value="ou=people,ou=myrealm,dc=oam_domain"></property>
              <property name="directory" value="ldap://cieqalnx01.us.oracle.com:7001"></property>
              <property name="group-search-filter" value="cn=%s"></property>
              <property name="group-target" value="wlsMemberOf"></property>
              <property name="search-bind-dn" value="cn=Admin"></property>
              <property name="search-bind-password" value="welcome1"></property>
            </auth-realm>
    

15. Make the LDAPRealm the default realm in GlassFish Server.

    <security-service default-realm="ldaprealm">
    

16. Restart GlassFish Server.

    Restart GlassFish Server and access the protected resource, such as http://hostname.domainname:8080/BasicAuthen/SecureServlet.

Additional Considerations for Certificate Authentication With a WebGate

In addition to the procedure described in Integrating OAM Security Provider with Oracle Access Manager 11g and WebGate, there are additional steps required if you want to use certificate authentication to protect your resource.

As described in Use Case: Identity Assertion for Web Resources via WebGate, 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. In response, the client application needs to send its own certificate.

The underlying WebLogic Server implementation is the Web container and must trust the application's certificate. WebLogic Server can trust this certificate either because the certificate is explicitly in the truststore, or because the certificate has a valid cert path to a trusted certificate.

You must therefore perform the following actions or satisfy their requirements by some other method:

1. Select the certificate you want the client to use. If you do not already have a private certificate, you can use a tool such as OpenSSL to generate a self-signed one for development and testing purposes.

2. Import your certificate into your browser. For Firefox, choose the 'Ask me every time' option in the browser (for choosing a Personal Certificate). Also make sure that SSL 3.0 is checked in the browser. Choose analogous options for other browser types.

3. The X.509 certificate you use for authentication must map to a valid user. To do this, create a user in the Access Manager LDAP provider whose CN attribute matches that of the subject.CN from the certificate.

   Consider the following example, which adds the user Alice. The subject.CN from the certificate must therefore be Alice.

   #ldapadd -x -h cieqalnx01.us.oracle.com -p 7001 
   -D"cn=Admin" -w welcome1 -f uadd.ldif
   

   In this example, the contents of uadd.ldif are as follows:

   #contents of uaddalice.ldif
   # GlassFish, people, myrealm, oam_domain
   dn: uid=Alice,ou=people,ou=myrealm,dc=oam_domain
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetOrgPerson
   objectclass: wlsUser
   cn: Alice
   sn: Alice
   uid: Alice
   description: GlassFish End User
   wlsMemberOf: cn=GlassFish_Group,ou=groups,ou=myrealm,dc=oam_domain
   userpassword: Alice
   

4. Create an X509 Authentication Module. Make sure that the Match LDAP Attribute is set to cn, and that the X509 Cert Attribute is Subject.CN. Set CertValidationEnabled to true. Consider the following example.

   
   Description of the illustration x509-auth-module.png
   
   

5. Create an Authentication Scheme that uses the X509 Challenge Method, and the X509 Authentication Module you just created.

   Remember that the WebGate challenges the user for credentials based on the type of OAM Server authentication scheme configured for the resource.

   Set the Challenge URL to the SSL port of OAM server. For example, https://<oam_server>:<ssl_port>/oam/CredCollectServlet/X509.

   Note:

   To work around a known problem, the name of the Authentication Scheme must contain either or both of the (case sensitive) words "X509" and "Certificate".

   Consider the following example.

   
   Description of the illustration authentication-scheme-certif.png
   
   

6. Configure WebLogic Server for Custom Identity and Custom Trust, as described in Configure Identity and Trust.

7. Import the root and intermediate certificates for your generated certificate into a custom keystore and truststore.

   keytool -import -keystore  /scratch/mytruststore -storepass (...) 
   -file root.cer -alias alice_root
   
   keytool -import -keystore  /scratch/mykeystore -storepass (...)
    -file root.cer -alias alice_root
   
   keytool -import -keystore  /scratch/mytruststore -storepass (...)  
   -file ca.cer -alias alice_root_1
   
   keytool -import -keystore  /scratch/aime1/mykeystore -storepass (...)  
   -file ca.cer -alias alice_root_1
   

8. Copy the custom keystore and truststore to the WebLogic Server system.

9. Configure WebLogic Server to use this custom keystore and truststore, as described in Configure Identity and Trust.

10. Restart the Oracle Access Manager and the Oracle HTTP Server.

Session Synchronization

When the same application is used by different user identities, GlassFish Server ensures that the same session is not used by the new user.

Specifically, when a user logs in using the BASIC, FORM or CLIENT-CERT authentication schemes after authentication from Oracle Access Manager, both an Oracle Access Manager session and a GlassFish Server HTTP session are established. When the Oracle Access Manager session is then cleared, the GlassFish Server HTTP session is not automatically cleared.

Therefore, after clearing the Oracle Access Manager session:

• If a user logs in through the OAM Security Provider, and

• The user principal differs from the principal in the previous HTTP session, then

• The previous HTTP session is cleared and a new session is created.