This trusted impersonator maintains the identity context of the user while accessing the resource on behalf of the user.

Impersonation is transparent to the user. Access appears to take place as if the SharePoint resource were a resource within the Access System domain.

The next overview identifies the authentication processing flow with SharePoint Server and Windows impersonation enabled.

Process overview: Integration Authentication with Windows Impersonation

1. The user requests access to a SharePoint Portal Server resource.

2. The WebGate ISAPI filter protecting SharePoint Portal Server intercepts the request, determines whether the target resource is protected, and if it is, challenges the user for authentication credentials.

3. If the user supplies credentials and the OAM Server validates them, the WebGate sets an OAMAuthnCookie in the user's browser, which enables single sign-on. The WebGate also sets an HTTP header variable named "impersonate," whose value is set to one of the following:

   • the authenticated user's LDAP uid

   • samaccountname, if the user account exists in Active Directory

4. The Access Manager HTTP module IISImpersonationModule.dll checks for the Authorization Success Action header variable named impersonate.

5. When the header variable exists, the Oracle ISAPI module obtains a Kerberos ticket for the user.

   This Service for User to Self (S4U2Self) impersonation token enables the designated trusted user to assume the identity of the requesting user and obtain access to the target resource through IIS and the SharePoint Portal Server.

Access Manager provides support for Windows Native Authentication (WNA).

Access Manager provides access and security functions, including Web-based single sign-on, policy management, reporting, and auditing.

Minimum requirements dictate a 64-bit, four cores processor.

https://technet.microsoft.com/en-us/library/cc262485.aspx 

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

http://technet.microsoft.com/en-us/library/cc262485.aspx

You can create a New Web Application in Microsoft SharePoint Server with or without LDAP Membership Provider.

1. On the host where SharePoint Server is installed, open the Central Administration home page: Start, All Programs, SharePoint Products, SharePoint, Central Administration.
2. From the Central Administration home page, click Application Management.
3. From the Application Management page, Web Applications section, click Manage Web Applications.
4. In the top-left corner, click the New button to create a new web application.
5. Configure the items in Table 51-3 on the Create New Web Application page:

   Table 51-3 Create Web Application Options for Microsoft SharePoint Server

   Section	What You Configure in This Section
   Authentication	In this section you select either Claim Based Authentication or Classic Mode Authentication, as appropriate.
   IIS Web Site	In this section you configure the following settings for your new Web application, as follows: To choose an existing Web site, click Use an Existing Web Site... To create a new site, click Create. In the Port field, enter the port number you want to use to access the Web application. For a new Web site, this field contains a default port number. For an exiting site, this field contains the currently configured port number. In the optional Host Header field, enter the URL for accessing the Web application. In the Path field, enter the path to the directory that contains the site on the server. For a new Web site, this field contains a default path. For an exiting site, this field contains the current path.
   Security Configuration	In this section you configure authentication and encryption for your Web application, as follows: In the Authentication Provider section, select Negotiate(Kerberos) or NTLM, as appropriate. In the Allow Anonymous section, choose Yes or No. A value of Yes allows anonymous access to the Web site by using a computer-specific anonymous access account. The account name is IUSR_computername. In the Secure Sockets Layer (SSL) section, choose Yes or No. If you choose to enable SSL for the Web site, you must configure SSL by requesting and installing a certificate.
   Public URL	Enter the URL for the domain name for all sites that users will access in this Web application. This URL domain will be used in all links shown on pages in the Web application. By default, the box is populated with the current server name and port. The Zone field is automatically set to Default for a new Web application and cannot be changed from this page.
   Application Pool	In the Application Pool section, choose whether to use an existing application pool or create a new application pool for this Web application, as follows: To use an existing application pool, select Use Existing Application Pool, then select the application pool you wish to use from the drop-down menu. To create a new application pool, select Create a New Application Pool, and in the Application Pool Name field, type the name of the new application pool, or keep the default name. In the section Select a Security Account for This Application Pool, select Predefined to use an existing application pool security account, then select the security account from the drop-down menu. To use a security account that is not currently being used for an existing application pool, select Configurable, enter the user name of the account you want to use in the User Name field, and enter the password for the account in the Password field.
   Database Name and Authentication	In this section, choose the database server, database name, and authentication method for your new Web application. In the Database Name field, enter the name of the database or use the default entry. In the Database Authentication field, choose whether to use Windows authentication (recommended) or SQL authentication, as follows: If you want to use Windows authentication, leave this option selected. If you want to use SQL authentication, select SQL authentication. In the Account field, type the name of the account that you want the Web application to use to authenticate to the SQL Server database, then type the password in the Password field.
   Failover Server	You can optionally choose to specify a fail-over database server to configure a Fail-over Server.
   Service Application Connections	You can use the default value or choose custom value and optionally select the services you want your web application to connect to.

6. Click OK to create the new Web application, or click Cancel to cancel the process and return to the Application Management page.
7. Proceed with "Creating a New Site Collection for Microsoft SharePoint Server".

You can create a new site collection for Microsoft SharePoint Server with or without LDAP Membership Provider.

1. From the Application Management page, Site Collection section, click Create Site Collections.
2. On the Create Site Collection page, in the Web Application section, either select a Web application to host the site collection (from the Web Application drop-down list), or create a new Web application to host the site collection, as follows:

   Table 51-4 Create a Web Application to Host a Site Collection for SharePoint Server

   Section	What You Configure in This Section
   Quota Template	You can decide to use predefined quota template to limit resources used for this site collection or use "No quota" as appropriate.
   Title and Description	Enter a title and description for the site collection
   Web Site Address	Select a URL type, and specify a URL for the site collection.
   Template	Select a template from the tabbed template control.
   Primary Site Collection Administrator	Enter the user account name for the user you want to be the primary Administrator for the site collection. You can also browse for the user account by clicking the book icon to the right of the text box. You can verify the user account by clicking the check names icon to the right of the text box.
   Secondary Site Collection Administrator (optional)	Enter the user account for the user that you want to be the secondary Administrator for the site collection. You can also browse for the user account by clicking the book icon to the right of the text box. You can verify the user account by clicking the Check Names icon to the right of the text box.

3. Refer to the following topics as you finish this integration:

   • "Setting Up Microsoft Windows Impersonation"

   • "Completing the SharePoint Server Integration"

   • "Configuring Single Sign-off for Microsoft SharePoint Server"

   • "Synchronizing User Profiles Between Directories"

   • "Testing Your Integration"

   See Also:

   "Task overview: Integrating with Microsoft SharePoint Server Configured with LDAP Membership Provider"

You can create trusted user accounts. The special user should not be used for anything other than impersonation.

1. Perform the following steps on the computer hosting your SharePoint Server installation:

   • Windows: Select Start, Programs, Administrative tools, Active Directory Users and Computers.

2. In the Active Directory Users and Computers window, right-click Users on the tree in the left pane, then select New, User.
3. In the First name field of the pane entitled New Object - User, enter an easy-to-remember name such as Impersonator.
4. Copy this same string to the User logon name field, then click Next.
5. In succeeding panels, you will be asked to choose a password and then retype it to confirm.

Note:

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 51-1 Setting up a Trusted User Account for Windows Impersonation

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

1. Perform steps for your environment:

   • Windows: Select Start, Programs, Administrative tools, Local Security Policy.

2. On the tree in the left pane, click the plus icon (+) next to Local Policies.
3. Click User Rights Assignment on the tree in the left pane.
4. Double-click Act as part of the operating system in the right pane.
5. Click Add User or Group.
6. In the Add User or Group panel, type the User logon name of the trusted user (SPPSImpersonator in our example) in the User and group names text entry box, then click OK to register the change.

Figure 51-2 Configuring Rights for the Trusted User in Windows Impersonation

Description of "Figure 51-2 Configuring Rights for the Trusted User in Windows Impersonation"

You need to bind the trusted user to the 12c WebGate that communicates with Access Manager by supplying the authentication credentials for the trusted user.

1. Click Application Security at the top of the Console window.
2. In the Launch Pad tab, click Application Domains in the Access Manager section.
3. Search for the desired domain and open it for editing.
4. Click the Authorization Policies tab and open the desired policy for editing.

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

5. On the Policy page, click the Responses tab, click the Add (+) button, and:

   • From the Type list, choose Header.

   • In the Name field, enter a unique name for this response: IMPERSONATE

   • In the Value field, enter a value for this Response. For example: $user.userid.

6. Click Add to save the Response, which is used for the second WebGate request (for authorization).

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:

• Configuring and Registering ImpersonationModule to IIS.

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"

1. Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
2. Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.
3. Click Web Sites on the tree in the left pane.
4. In the center pane, double-click on Authentication under IIS.
5. Ensure that Anonymous Authentication is enabled and Windows Authentication is disabled.

Figure 51-4 Impersonation Authentication

Description of "Figure 51-4 Impersonation Authentication"

The previous scenario, "Integrating With Microsoft SharePoint Server", describes how to use Windows authentication. In that scenario, authentication and authorization are performed for users residing in Active Directory. Access Manager used Windows impersonation for integration.

For the integration described in this section, support for the LDAP Membership Provider is achieved by using a HeaderVar-based integration. The ISAPI WebGate filter intercepts HTTP requests for Web resources and works with the OAM Server to authenticate the user who made the request. When authentication is successful, WebGate creates an OAMAuthnCookie and sends it to the user's browser to facilitate single sign-on (SSO). The WebGate also sets OAM_REMOTE_USER as a HeaderVar action for this user session. The Oracle Custom Membership provider in SharePoint validates the ObSSOCookie using the HTTP validation method, whereby the Access Manager Custom Membership Provider makes an HTTP/HTTPS request to a protected resource. Access Manager then validates and compares the user login returned on Authorization success with OAM_REMOTE_USER.

Requirements: This integration requires that Microsoft SharePoint Server:

• Must be integrated with the LDAP Membership ProviderMust not use Windows authentication

• Must not have IISImpersonationModule.dll configured at the Web site using Claim Based Authentication

You can prepare your installation for integration with Microsoft SharePoint Server Configured with LDAP Membership Provider.

When your integration includes the LDAP Membership Provider, only three Access Manager authentication methods are supported.

1. In the Oracle Access Management Console, click Application Security at the top of the window.
2. In the Launch Pad tab, select Create Authentication Scheme from the Create (+) drop-down menu the Access Manager section.
3. On the Authentication Scheme page, fill in the:

   Name: Enter a unique name for this scheme. For example: SharePoint w/LDAP-MP

   Description: Optional

4. Authentication Level: Choose a level of security for the scheme.
5. Choose a Challenge Method:

   Basic Authentication for SharePoint Web site root (/)

   Form Authentication with Challenge Redirect for SharePoint Web site root (/)

   Client Certificate Authentication for SharePoint Web site root (/)

6. Challenge Redirect: Enter your challenge redirect value, if required.
7. Choose an Authentication Module from those listed.
8. Challenge Parameters: Enter your challenge parameter values, if required.
9. Challenge URL: The URL the credential collector will redirect to for credential collection.
10. Click Apply to submit the new scheme, review details in the Confirmation window.
11. Optional: Click the Set as Default button to automatically use this with new Application Domains, then close the Confirmation window.
12. In the navigation tree, confirm the new scheme is listed, and then close the page.

Users in the directory server configured for Access Manager should be synchronized with the directory server used by SharePoint if these are different.

You can configure a custom logout URL in SharePoint Server.

1. From the generated artifacts for WebGate, add logout.html to the SharePoint Server Site
2. Locate C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES.
3. In \CONTROLTEMPLATES, change the welcome.ascx by adding the following tag. For example:

   <SharePoint:MenuItemTemplate runat="server" id="ID_OverrideLogout" Text="Custom Logout"       
      	  ClientOnClickNavigateUrl="/logout.html?end_url=_layouts/SignOut.aspx"
        Description="My Custom Logout"
      MenuGroupId="200"
      Sequence="100"
      UseShortId="true" />
   

4. Click Save.
5. Protect the two URLs /_layouts/SignOut.aspx and /_layouts/closeConnection.aspx in an Application Domain using Anonymous authentication.
6. Proceed to Configuring Logout in SharePoint Server With Impersonation.

You can configure logout in SharePoint server with Impersonation. If you do not have Impersonation configured, this procedure can be skipped.

1. Copy signout.aspx from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS) to MySignout.aspx in the same path.
2. In MySignout.aspx, below (<asp:content contentplaceholderid="PlaceHolderAdditionalPageHead" runat="server">) add the following script details:

   <script runat="server">       
   private void Page_Load(object sender, System.EventArgs e){
    Response.Status = "302 Moved Temporarily";
    Response.AddHeader("Location", "/logout.html?end_url=/_layouts/SignOut.aspx");}
   </script>
   

3. Save.
4. Use this URL _layouts/Mysignout.aspx as custom logout URL for SharePoint Server in the case of Impersonation.
5. Proceed with "Testing Your Integration".

1. Log in to the machine as the Windows domain user (or AD user or AD user account).

   The login account must also be a user of Access Manager.

2. Enter the URL of the protected resource.

You can verify that a user can access SharePoint Server resources through Access Manager authentication and SharePoint Server authorization.

1. Navigate to any SharePoint Server Web page using your browser.

   You are challenged for your credentials.

2. Log in by supplying the necessary credentials.
3. Verify that the page you requested is visible.
4. Optional: Check the Event Viewer to confirm that the access request was successful.

You can also test single sign-on by demonstrating that a user who has just supplied credentials and accessed an SharePoint Server resource can (before the OAMAuthnCookie expires) access a non-SharePoint Server resource without having to supply credentials a second time.

1. Create and protect a new virtual site with a Application Domain (or use one you have already created.
2. Place a Web page anywhere in the tree of this virtual site.
3. Using a browser, navigate to the page in the new virtual site.

   If you have already passed authentication, you should be granted access to the page without having to supply credentials a second time.

The issue may occur if the server sends a Cache-control:no-store header or sends a Cache-control:no-cache header. The WebGate provides configuration parameters to control setting these headers.