If you want to use a directory server other than Active Directory, use LDAP Membership provider. The OAMCustomMembership provider leverages the functionality of LDAP Membership provider.
This section describes how to set up impersonation, whether for SharePoint Server integration or for use by some other application.
Skip this section if you are integrating Microsoft SharePoint Server configured with LDAP Membership Provider. Windows impersonation is not used with the LDAP Membership Provider.
Task overview: Setting up impersonation
IISImpersonationModule.dllto your IIS configuration, as described in "Adding an Impersonation DLL to IIS".
You can create trusted user accounts. The special user should not be used for anything other than impersonation.
The example in the following procedure uses Impersonator as the New Object - User. Your environment will be different.
To create a trusted user account:
Windows 2008: Select Start, Programs, Administrative tools, Active Directory Users and Computers.
Oracle recommends that you chose a very complex password, because your trusted user is being given very powerful permissions. Also, be sure to check the box marked Password Never Expires. Since the impersonation module should be the only entity that ever sees the trusted user account, it would be very difficult for an outside agency to discover that the password has expired.
Figure 59-1 Setting up a Trusted User Account for Windows Impersonation
You need to give the trusted user the right to act as part of the operating system.
To give appropriate rights to the trusted user:
Windows 2008: Select Start, Programs, Administrative tools, Local Security Policy.
Figure 59-2 Configuring Rights for the Trusted User in Windows Impersonation
You need to bind the trusted user to the 10g WebGate that communicates with Access Manager by supplying the authentication credentials for the trusted user.
The following procedure presumes that you have not yet registered a 10g WebGate with Access Manager. Values in the following procedure are provided as an example only. Your environment will be different.
To bind your trusted user to your WebGate
Go to the Oracle Access Management Console.
where hostname is the fully-qualified DNS name of the computer hosting the Oracle Access Management Console; port is the listening port configured for the OAM Server; oamconsole leads to the Oracle Access Management Console.
Click Application Security at the top of the window.
In the Launch Pad tab, click SSO Agent Registration in the Quick Start Wizards section.
Select WebGate as the agent type and click Next..
Set the version to 10g and enter required details (those with an *) to register this WebGate.
Protected Resource List: In this table, enter individual resource URLs to be protected by this OAM Agent, as shown in Table 14–9.
Public Resource List: In this table, enter individual resource URLs to be public (not protected), as shown in Table 14–9.
Auto Create Policies: Check to create fresh policies (or clear and use the same host identifier as another WebGate to share policies (Table 14–9)).
Click Apply to submit the registration.
Check the Confirmation window for the location of generated artifacts, then close the window.
In the navigation tree, open the Agent page.
SharePoint Requirements: Enter trusted user credentials in the Sharepoint Impersonator fields and click Apply.
Copy the artifacts as follows (or install the WebGate and then copy these artifacts):
On the Oracle Access Management Console host, locate the updated OAM Agent ObAccessClient.xml configuration file (and any certificate artifacts). For example:
On the computer hosting the agent, copy the artifacts. For example
IMPERSONATE, with the Response value of $user.userid: "samaccountname" for a single-domain Active Directory installation or "userPrincipalName" for a multi-domain Active Directory forest.
To add an impersonation response to your Authorization Policy:
"Desired domain" refers to the Application Domain created specifically for impersonation (Impersonation for example). "Desired policy" is your default policy created during agent registration. By default, no policy Responses exist until you create them.
From the Type list, choose Header.
In the Name field, enter a unique name for this response:
In the Value field, enter a value for this Response. For example: $user.userid.
You can add an impersonation DLL to IIS.
You can configure IIS Web server for the integration by registering and configuring the IISImpersonationModule.dll across all sites including central administration and web services.
Alternatively, if you have multiple Web sites, where some are integrated with Access Manager while others are not, you might want to enable impersonation only for those Web sites that are integrated with Access Manager. To do this, you must configure the Native Module only at those sites that require integration. See:
You can configure and register ImpersonationModule to IIS
To configure and register ImpersonationModule to IIS
By default, the path is:
Where WebGate_install_dir is the directory of your WebGate installation.
If any spaces exist in the path (for example,
C:\Program Files\Oracle\...) surround the entire string with double quotes (" ").
Figure 59-3 Registering the Impersonation Module
You can configure site level Native Modules for Web sites.
You can test to ensure that impersonation is working properly before you complete the integration.
Following are the ways to test impersonation:
Outside the SharePoint Server context or test single sign-on, as described in "Creating an IIS Virtual Site Not Protected by SharePoint Server"
Using the Event Viewer, as described in "Testing Impersonation Using the Event Viewer"
Using a Web page, as described in "Testing Impersonation using a Web Page"
Using negative testing as described in "Negative Testing for Impersonation"
"Completing the SharePoint Server Integration" after confirming impersonation configuration is working properly
To test the impersonation feature outside the SharePoint Server context or to test single sign-on, you will need a target Web page on an IIS virtual Web site that is not protected by SharePoint Server.
You create such a virtual Web site by completing the following task.
To create an IIS virtual site not protected by SharePoint Server
When you complete impersonation testing using the Windows 2003 Event Viewer, you must configure the event viewer before conducting the actual test.
To test impersonation through the Event Viewer:
Your Event Viewer is now configured to display information about the HeaderVar associated with a resource request.
Figure 59-4 Verifying Event Viewer Settings
If impersonation is working correctly, the Event Viewer will report the success of the access attempt.
You can also test impersonation using a dynamic test page, such as an .asp page or a Perl script, that can return and display information about the request.
To test impersonation through a Web page that displays server variables
Sample .ASP Page Code:
<TABLE border=1> <TR> <TD>Variable</TD> <TD>  </TD> <TD>Value</TD></TR> <%for each servervar in request.servervariables%> <TR> <TD><%=servervar%></TD> <TD>  </TD> <TD><%=request.servervariables(servervar)%> </TD> </TR>
To conduct negative testing for impersonation, you need to unbind the trusted user from the WebGate.
To unbind the trusted user from your WebGate: