Integrating Microsoft SharePoint Server with Access Manager

41.1 What is Supported in This Release?

Support for integration between Access Manager and SharePoint enables the following functionality:

When a user accesses SharePoint before SSO login with Access Manager, the user is prompted for Access Manager SSO login credentials.
When a user with a valid Access Manager login session wants to access SharePoint documents, he must be established with SharePoint (logged in and authenticated with SharePoint). Once the Access Manager session is established, it is also respected by SharePoint for integration with Access Manager and SharePoint using LDAP Membership Provider, OAM WNA, and impersonation. Based on authentication status, SharePoint either allows or denies access to documents stored in SharePoint.
When a user opens an Office document from SharePoint using a browser, the SSO session should persist into the MS Office program so that access to the document through the MS Office program is maintained. See "Configuring Single Sign-On for Office Documents".

41.2 Introduction to Integrating With the SharePoint Server

SharePoint Server is a Microsoft-proprietary secure and scalable enterprise portal server that builds on Windows Server Microsoft Internet Information Services (IIS) and Windows SharePoint Services (WSS).

SharePoint Server is typically associated with Web content and document management systems. SharePoint Server works with Microsoft IIS web server to produce sites intended for collaboration, file sharing, web databases, social networking and web publishing. In addition to WSS functionality, SharePoint Server incorporates additional features such as News and Topics as well as personal and public views for My Site, and so on.

Microsoft SharePoint Server enhances control over content, business processes, and information sharing. Microsoft SharePoint Server provides centralized access and control over documents, files, Web content, and e-mail, and enables users to submit files to portals for collaborative work.

SharePoint server farms can host web sites, portals, intranets, extranets, Internet sites, web content management systems, search engine, wikis, blogs, social networking, business intelligence, workflow as well as providing a framework for web application development.

When integrated with Microsoft SharePoint Server, Access Manager handles user authentication through an ISAPI filter and an ISAPI Module. This enables single sign-on between Access Manager and SharePoint Server.

SharePoint Server supports the following authentication methods:

Form Based Authentication
Impersonation Based Authentication
Windows Authentication: Used only for the configuration where the information about the users is stored in Active Directory server

The integrations in this chapter provide single sign-on to Microsoft SharePoint Server resources and all other Access Manager protected resources. For more information, see:

41.2.1 About Windows Impersonation

Unless explicitly stated, the integrations described in this chapter rely on Windows impersonation. Windows impersonation enables a trusted user in the Windows server domain to assume the identity of any user requesting a target resource in Microsoft SharePoint Server.

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.

Note:

Windows impersonation is not used when integrating Microsoft SharePoint Server configured with the LDAP Membership Provider.

41.2.2 Form Based Authentication With This Integration

You can integrate Access Manager with SharePoint Server using any of the three authentication methods. Given common use of LDAP servers (Sun Directory Server and Active Directory for instance), your integration can include any LDAP server. Form-based authentication in SharePoint Server is claims-aware. When a user enters credentials on the Forms login page of SharePoint Relying Party (RP), these are passed to the SharePoint Security Token Service (STS). SharePoint STS authenticates the users against its membership provider and generates the SAML token, which is passed to SharePoint RP. SharePoint RP validates the SAML token and generates the FedAuth cookie. The user is then allowed to access the SharePoint RP site.

With form-based authentication, the WebGate is configured as an ISAPI filter. The form login page of SharePoint RP is customized such that the user is not challenged to enter the credentials by the SharePoint RP. Also, the membership provider is customized such that it just validates the OAMAuthnCookie set by the WebGate to authenticate the user.

The following overview outlines the authentication flow for this integration using form-based authentication.

Process overview: Request processing with form-based authentication

The user requests access to an SharePoint Server RP site.
The WebGate protecting the site intercepts the request, determines if the resource is protected, and challenges the user.
The user enters their OAM credentials. Next the OAM WebGate server verifies the credentials from LDAP and authenticates the user.

The WebGate generates the OAM native SSO cookie (OAMAuthnCookie), which enables single sign-on and sets the User ID header variable (to the user name) in the HTTP request and redirects the user to the SharePoint RP site.
The SharePoint RP custom login page is invoked, which sets the user name to the user ID passed in the header variable, and sets the password to the OAMAuthnCookie value. The login page also automatically submits these credentials to the SharePoint RP site.
The SharePoint RP site passes the credentials to SharePoint STS, which invokes the custom membership provider to validate the user credentials.
The custom membership provider gets the OAMAuthnCookie value (passed as a password) and sends it as part of the HTTP request to a resource protected by the WebGate to validate the OAMAuthnCookie.
If the OAMAuthnCookie is valid, SharePoint STS generates the SAML token and passes it to SharePoint RP.
SharePoint RP validates the SAML token and generates the FedAuth cookie. The user is then allowed to access the SharePoint RP site.

41.2.3 Authentication With Windows Impersonation and SharePoint Server Integration

Windows impersonation enables a trusted user in the Windows server domain to assume the identity of any user requesting a target resource in SharePoint Portal Server. The 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 OAM Server domain.

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

Process overview: Integration Authentication with Windows Impersonation

The user requests access to a SharePoint Portal Server resource.
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.
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
The Access Manager HTTP module IISImpersonationModule.dll checks for the Authorization Success Action header variable named impersonate.
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.

41.2.4 Access Manager Support for Windows Native Authentication

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

Your environment may include:

Windows 2008/R2 or 2012/R2 server
Internet Information services (IIS) 7.x or 8.x
Active Directory

If the user's directory server has, for example, an NT Logon ID, or if the user name is the same everywhere, then a user is able to authenticate into any directory server. The most common authentication mechanism on Windows Server 2008 is Kerberos.

The use of WNA by Access Manager is seamless. The user does not notice any difference between a typical authentication and WNA when they log on to their desktop, open an Internet Explorer (IE) browser, request a protected web resource, and complete single sign-on.

Process overview: Using WNA for authentication

The user logs in to the desktop computer, and local authentication is completed using the Windows Domain Administrator authentication scheme.
The user opens an Internet Explorer (IE) browser and requests an Access System-protected Web resource.
The browser notes the local authentication and sends a Kerberos token to the IIS Web server.

Note:

Ensure that Internet Explorer's security settings for the Internet and (or) intranet security zones are adjusted properly to allow automatic logon.
The WebGate installed on the IIS Web server sends the Kerberos token to the OAM sever. The OAM Server negotiates the Kerberos token with the KDC (Key distribution center).
Access Manager sends authentication success information to the WebGate.
The WebGate creates an OAMAuthnCookie and sends it back to the browser.
Access Manager authorization and other processes proceed as usual.

The maximum session time-out period configured for the WebGate is applicable to the generated OAMAuthnCookie.

41.3 Integration Requirements

Unless explicitly stated, this section introduces components required for integrations described in this chapter. It includes the following topics:

41.3.1 Requirements Confirmation

References to specific versions and platforms are for demonstration purposes. For the latest Access Manager certification information, see the certification matrix on Oracle Technology Network at:

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

41.3.2 Required Access Manager Components

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

When integrated with Microsoft SharePoint Server, Access Manager handles user authentication through an ISAPI filter and an ISAPI Module, which enables single sign-on between the two products. The components in Table 41-1 are required to integrate with Microsoft SharePoint Server (or Microsoft SharePoint Server configured with LDAP Membership Provider.)

Table 41-1 Component Requirements

Component	Description
11g WebGate	The ISAPI version 11g WebGate must reside on the same computer as the SharePoint Server. Within the context of this integration, this WebGate is an ISAPI filter that intercepts HTTP requests for Web resources and forwards them to the OAM Server to authenticate the user who made the request. If authentication is successful, the WebGate creates an OAMAuthnCookie and sends it to the user's browser, thus facilitating single sign-on. The WebGate also sets impersonate as a HeaderVar action for this user session. For LDAP Membership Provider Scenario: See "Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider".
`IISImpersonationModule.dll`	This IIS-native module is installed with the WebGate. The `IISImpersonationModule.dll` module determines whether the Authorization Success Action HeaderVar has been set to impersonate and, if it has, the DLL file creates a Kerberos S4U2Self ticket that enables the special trusted user in the SharePoint Server Active Directory to impersonate the user who originally made the request. After a WebGate installation, you must configure `IISImpersonationModule.dll` manually to enable impersonation and this integration. For LDAP Membership Provider Scenario: Do not configure `IISImpersonationModule.dll`.
Directory Server	Access Manager can be connected to any supported directory server including, but not limited to, LDAP and Active Directory. Access Manager can even connect to the same instance of Active Directory used by SharePoint Server. In any case, the directory is not required on the same machine as SharePoint Server and the protecting WebGate.
OAM Server	The integration also requires installation of the OAM Server with which the WebGate protecting your SharePoint Server installation is configured to inter-operate. Except for the WebGate protecting SharePoint Server, your components do not need to reside on the machine hosting SharePoint Server. See Also: "Preparing for Integration With SharePoint Server".

41.3.3 Required Microsoft Components

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

However, references to specific versions and platforms are for demonstration purposes. For the latest Access Manager certification information, see the following Microsoft library location for Microsoft SharePoint Server:

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

The SharePoint multi-purpose platform allows for managing and provisioning of intranet portals, extranets, and Web sites; document management and file management; collaboration spaces; social networking tools; enterprise search and intelligence tooling; process and information integration; and third-party developed solutions.

Note:

Minimum requirements dictate a 64-bit, four cores processor. However, references to specific versions and platforms are for demonstration purposes. For the latest Access Manager certification information, see Oracle Technology Network at:

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

Table 41-2 describes the other components required for this integration.

See Also:

The following library location for Microsoft SharePoint Server and access to applicable software:

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

Table 41-2 Microsoft Requirements for this Integration

Component	Description
Custom Login Page for SharePoint site	When the user tries to access a SharePoint site configured to use Form Based Authentication, the user is redirected to a login page where the user enters his or her credentials (user name and password). The custom login page passes the credentials to the SharePoint site.
SharePoint site	You create the SharePoint site using the SharePoint Central Administration application. The site is configured to use Form Based Authentication as the authentication method by following the steps mentioned in `http://technet.microsoft.com/en-us/library/ee806890.aspx`. The SharePoint site passes the user credentials to the SharePoint STS that generates SAML token upon successful OAMAuthnCookie validation by the custom membership provider. The SharePoint site also generates FedAuth cookie upon receiving the SAML token from SharePoint STS. The SharePoint site passes the FedAuth cookie to the user so that he/she can access the SharePoint site.
SharePoint Security Token Service (STS)	The SharePoint site passes the user credentials (user name and password) to SharePoint STS, which invokes the custom membership provider and passes the credentials to it. Once the custom membership provider validates the OAMAuthnCookie passed to it, the SharePoint STS generates the SAML token for the user that is passed to the SharePoint Relying Party (RP).
Custom Membership Provider for SharePoint STS	The SharePoint STS invokes the membership provider (configured with Form Based Authentication). STS passes the user credentials and the URL for the IIS resource (configured in `web.config` on the SharePoint site) to the custom membership provider for cookie validation. The membership provider is customized such that it returns success if the OAMAuthnCookie value passed to it is valid. The custom membership provider library (`OAMCustomMembershipProvider.dll`) is packaged and installed with the 11g WebGate for IIS Web server. You must deploy the library in the global assembly cache of the SharePoint Server host. The `CustomMembershipProvider` class is derived from `LdapMembershipProvider` class present in the `Microsoft.Office.Server.Security` namespace.
IIS resource for Cookie validation	Configure the URL for the IIS resource in the SharePoint site's `web.config` file. For the HTTP validation method, the WebGate intercepts the request sent by the custom membership provider, extracts the OAMAuthnCookie from the request, and validates it. If the cookie is valid, then the request is redirected to the IIS resource, which returns the response with a 200 (OK) status code to the custom membership provider. Otherwise, a 403 (Forbidden) error code is returned to the custom membership provider.

41.4 Preparing for Integration With SharePoint Server

The IIS 11g WebGate must be installed on the same computer as the SharePoint Server. Other components in this integration can reside on the same host as the WebGate or any other computer in your deployment (Solaris, Linux, or Windows platforms).

Tasks in the following procedure are required for all integration scenarios described in this chapter.

After installing and testing Microsoft components, perform steps here to install Access Manager for your integration. This task applies to both integration scenarios in this chapter. To avoid repetition, information here is not repeated elsewhere.

A different host can be set up for Active Directory or some other directory service. If both Access Manager and SharePoint Server are set up for different instances of Active Directory, both instances must belong to the same Active Directory domain.

Prerequisites

Install and test Microsoft components described in "Required Microsoft Components".

To prepare for integration with SharePoint Server

Install Oracle Identity Management and Access Manager as described in the Installing and Configuring Oracle Internet Directory.
Register a 11g WebGate for IIS Web server with Access Manager:
1. Log in to the Oracle Access Management Console. For example: http://host:port/oamconsole.
2. Click Application Security at the top of the window.
3. In the Launch Pad tab, click SSO Agent Registration in the Quick Start Wizards section.
4. Select WebGate as the agent type and click Next.
5. Set the agent version to 11g and enter required details (those with an *):
  - Name
  - SharePoint user name and password
  - Security mode (Agent host must match OAM Server)
  - Auto Create Policies (Checked)
  Note:
  
  Do not specify a Base URL.
6. Protected Resource List: In this table, enter individual resource URLs to be protected by this OAM Agent.
7. Public Resource List: In this table, enter individual resource URLs to be public (not protected).
8. Click Apply to submit the registration, check the Confirmation window for the location of generated artifacts, then close the window.
Proceed as follows:
- Install a fresh WebGate: Continue with steps 6, 7, and 8.
- Existing WebGate on SharePoint Host: Skip to "Integrating With Microsoft SharePoint Server".
  
  Note:
  
  Only 64-bit ISAPI WebGates are supported as described in "Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider".
Locate and download the 64-bit IIS WebGate installer as follows:
1. Go to Oracle Fusion Middleware 11gR1 Software Downloads at:
```
https://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html
```
2. Click Accept License Agreement, at the top of the page.
3. From the Access Manager Webgates (10.1.4.3.0) row, click the download link for the desired platform and follow on-screen instructions.
4. Store the WebGate installer in the same directory as any 11g (10.1.4.3) Access System Language Packs you want to install.
Launch the WebGate installer for your platform, installation mode, and Web server.

Follow these steps:
1. Follow on-screen prompts.
2. Provide Administrator credentials for the Web server.
3. Language Pack—Choose a Default Locale and any other Locales to install, then click Next.
4. WebGate installation begins (IISImpersonationModule.dll will be installed in WebGate_install_dir\webgate\iis\lib).
Before updating the Web server configuration, copy WebGate artifacts from the Admin Server to the computer hosting the WebGate.
1. On the computer hosting the Oracle Access Management Console (AdminServer), locate and copy ObAccessClient.xml (and any certificate artifacts):
  
  $DOMAIN_HOME/output/$Agent_Name/
  - ObAccessClient.xml
  - password.xml (if needed)
  - aaa_key.pem (your private key generated by openSSL)
  - aaa_cert.pem (signed certificates in PEM format)
2. On the OAM Agent host, add the artifacts to the WebGate path. For example:
  - WebGate_instance_dir/webgate/config/ObAccessClient.xml
  - WebGate_instance_dir/webgate/config/
3. Restart the WebGate Web server.
4. (Optional.) Restart the OAM Server that is hosting this Agent. This step is recommended but not required.
Proceed as needed to complete this integration within your environment:
- Integrating With Microsoft SharePoint Server
- Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider

41.5 Integrating With Microsoft SharePoint Server

You can integrate with Microsoft SharePoint Server by creating a new Web application or site application.

The following overview outlines the tasks that you must perform for this integration and the topics where you will find the steps and details.

The custom membership provider library (OAMCustomMembershipProvider.dll) is packaged and installed with the 10g WebGate for IIS Web Server. You must deploy the library in the global assembly cache of the computer hosting SharePoint Server as outlined next.

Task overview: Integrating with Microsoft SharePoint Server includes

Performing prerequisite tasks:
- Installing "Required Microsoft Components".
- "Preparing for Integration With SharePoint Server"
Creating a new Web application (or site application) in SharePoint Server is described in following topics:
- "Creating a New Web Application in Microsoft SharePoint Server"
- Creating a New Site Collection for Microsoft SharePoint Server
"Setting Up Microsoft Windows Impersonation" (not used with LDAP Membership Provider).
"Completing the SharePoint Server Integration".
"Configuring Single Sign-off for Microsoft SharePoint Server".
"Synchronizing User Profiles Between Directories".
"Testing Your Integration".

41.5.1 Creating a New Web Application in Microsoft SharePoint Server

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

You perform this task when integrating with Microsoft SharePoint Server, with or without LDAP Membership Provider.

Prerequisites

Installing Microsoft components. See "Required Microsoft Components".

To create a new Web application in Microsoft SharePoint Server

On the host where SharePoint Server is installed, open the Central Administration home page: Start, All Programs, SharePoint Products, SharePoint, Central Administration.
From the Central Administration home page, click Application Management.
From the Application Management page, Web Applications section, click Manage Web Applications.
In the top-left corner, click the New button to create a new web application.

Configure the items in Table 41-3 on the Create New Web Application page:

Table 41-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.

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

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

To create a new site collection for Microsoft SharePoint Server

From the Application Management page, Site Collection section, click Create Site Collections.

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

Refer to the following topics as you finish this integration:
See Also:

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

41.6 Setting Up Microsoft Windows Impersonation

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.

Note:

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

Create a trusted user account for only impersonation in the Active Directory connected to SharePoint Server, as described in "Creating Trusted User Accounts".
Give the trusted user the special right to act as part of the operating system, as described in "Assigning Rights to the Trusted User".
Bind the trusted user to the WebGate by supplying the authentication credentials for the trusted user, as described in "Binding the Trusted User to Your WebGate".
Add a header variable named IMPERSONATE to the Authorization Success Action in the Application Domain for impersonation, as described in "Adding an Impersonation Response to an Authorization Policy".
Configure IIS by adding the IISImpersonationModule.dll to your IIS configuration, as described in "Adding an Impersonation DLL to IIS".
Test impersonation, as described in "Testing Impersonation".

41.6.1 Creating Trusted User Accounts

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:

Perform the following steps on the computer hosting your SharePoint Server installation:
- Windows: Select Start, Programs, Administrative tools, Active Directory Users and Computers.
In the Active Directory Users and Computers window, right-click Users on the tree in the left pane, then select New, User.
In the First name field of the pane entitled New Object - User, enter an easy-to-remember name such as Impersonator.
Copy this same string to the User logon name field, then click Next.
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 41-1 Setting up a Trusted User Account for Windows Impersonation

Description of "Figure 41-1 Setting up a Trusted User Account for Windows Impersonation"

41.6.2 Assigning Rights to the Trusted User

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:

Perform steps for your environment:
- Windows: Select Start, Programs, Administrative tools, Local Security Policy.
On the tree in the left pane, click the plus icon (+) next to Local Policies.
Click User Rights Assignment on the tree in the left pane.
Double-click Act as part of the operating system in the right pane.
Click Add User or Group.
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 41-2 Configuring Rights for the Trusted User in Windows Impersonation

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

41.6.3 Binding the Trusted User to Your WebGate

You need to bind the trusted user to the 11g 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 11g 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.

For example:
```
http://hostname:port/oamconsole
```
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 11g 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):
1. On the Oracle Access Management Console host, locate the updated OAM Agent ObAccessClient.xml configuration file (and any certificate artifacts). For example:
  
  $DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml
2. On the computer hosting the agent, copy the artifacts. For example
  - 11g WebGate/AccessClient: $WebGate_instance_dir/webgate/config/ObAccessClient.xml
  - ObAccessClient.xml
3. Proceed to "Adding an Impersonation Response to an Authorization Policy".

41.6.4 Adding an Impersonation Response to an Authorization Policy

An Application Domain and basic policies to protect your SharePoint resources was created when you registered the WebGate with Access Manager. You must add an Authorization Success Action (Response) with a return type of Header, set the name to 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:

Click Application Security at the top of the Console window.
In the Launch Pad tab, click Application Domains in the Access Manager section.
Search for the desired domain and open it for editing.
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.
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.
Click Add to save the Response, which is used for the second WebGate request (for authorization).

41.6.5 Adding an Impersonation DLL to IIS

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.

41.6.5.1 Configuring and Registering ImpersonationModule to IIS.

You can configure and register ImpersonationModule to IIS

To configure and register ImpersonationModule to IIS

Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
In the left pane of IIS, click the hostname.
In the middle pane, under the IIS header, double click Modules.
In the right pane, click Configure Native Modules and click Register.
In the window, provide a module Name (for example, Oracle Impersonation Module).
In the Path field, type the full path to IISImpersonationModule.dll.
By default, the path is:
```
WebGate_install_dir\access\oblix\apps\Webgate\bin\IISImpersonation
```
Where WebGate_install_dir is the directory of your WebGate installation.

Note:

If any spaces exist in the path (for example, C:\Program Files\Oracle\...) surround the entire string with double quotes (" ").
Click OK to register the module.
Check the name of the newly created module and click OK to apply the module across the Web sites.
Add IISImpersonationModule.dll as Native Module on the IIS.
Configure the IISImpersonationModule.dll as Native Module at site level only (not at global level).
IISImpersonationModule.dll must be above SPWindowsClaimAthenticationHttpModule in Http module at site level for the integration. In order to move IISImpersonationModule.dll above SPWindowsClaimAthenticationHttpModule, all the native module must be unlocked from the Http module at IIS Global level.

41.6.6 Testing Impersonation

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"

See Also:

"Completing the SharePoint Server Integration" after confirming impersonation configuration is working properly

41.6.6.1 Creating an IIS Virtual Site Not Protected by SharePoint Server

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

Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.
Right-click Web Sites on the tree in the left pane, then navigate to New, Web Site on the menu.
Respond to the prompts by the Web site creation wizard.
After you create the virtual site, you must protect it with policies in an Application Domain.

41.6.6.2 Testing Impersonation Using the Event Viewer

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:

Select Start Menu, Event Viewer.
In the left pane, right-click Security, then click Properties.
Click the Filter tab on the Security property sheet.
Verify that all Event Types are checked, and the Event Source and Category lists are set to All, then click OK to dismiss the property sheet.

Your Event Viewer is now configured to display information about the HeaderVar associated with a resource request.

Figure 41-3 Verifying Event Viewer Settings

Description of "Figure 41-3 Verifying Event Viewer Settings"
Create a new IIS virtual server (virtual site).
Place a target Web page anywhere in the tree on the virtual site.
Point your browser at the Web page.

If impersonation is working correctly, the Event Viewer will report the success of the access attempt.

41.6.6.3 Testing Impersonation using a Web Page

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

Create an .asp page or Perl script that will display the parameters AUTH_USER and IMPERSONATE, which can resemble the sample page presented in the following listing:

Sample .ASP Page Code:

<TABLE border=1>
       <TR>
             <TD>Variable</TD>
             <TD>&nbsp&nbsp</TD>
             <TD>Value</TD></TR>
       <%for each servervar in request.servervariables%>
       <TR>
             <TD><%=servervar%></TD>   
             <TD>&nbsp&nbsp</TD>
             <TD><%=request.servervariables(servervar)%>&nbsp</TD>
       </TR>

Create an IIS virtual site, or use the one you created for the previous task.
Place an .asp page or Perl script (such as the sample in the preceding listing) anywhere in the tree of the new virtual site.
Point your browser at the page, which should appear, with both AUTH_USER and IMPERSONATE set to the name of the user making the request.

41.6.6.4 Negative Testing for Impersonation

To conduct negative testing for impersonation, you need to unbind the trusted user from the WebGate.

To unbind the trusted user from your WebGate:

In the Oracle Access Management Console, locate the WebGate.
Open the desired WebGate registration page and remove the credentials for the trusted user.
Click Apply to save the change.
Restart the IIS server and in a browser window, go to a protected code page (previously accessible to the trusted user).
Confirm that you receive an message page should appear. Values for AUTH_USER and IMPERSONATE are necessary for impersonation credentials to be bound to a WebGate.
Restore the trusted user to the WebGate registration page.

41.7 Completing the SharePoint Server Integration

You need to complete several procedures to set up an Access Manager with SharePoint Server integration.

Skip this section if you are integrating with SharePoint Server configured with LDAP Membership Provider.

Task overview: Completing the SharePoint Server integration

Set up IIS security, as described in "Configuring IIS Security".
Test the integration, as described in "Testing the SharePoint Server Integration".

41.7.1 Configuring IIS Security

Be sure to configure IIS Security before you continue.

To configure IIS Security for the SharePoint Server integration

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

Figure 41-4 Impersonation Authentication

Description of "Figure 41-4 Impersonation Authentication"

41.8 Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider

In this scenario, Access Manager gets integrated with SharePoint Server using SharePoint Security Token Service (STS). This includes the ISAPI WebGate installation on IIS, as well as Access Manager configuration and steps needed to achieve the HeaderVar integration.

Note:

Only 64-bit ISAPI WebGates are supported for this integration.

The following overview introduces the tasks that you must perform for this integration, including prerequisites, and where to find the information you need for each task.

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

Preparing for this integration:
1. Install "Required Microsoft Components", as described.
2. Create a SharePoint Web site, as described in "Creating a New Web Application in Microsoft SharePoint Server".
3. Configure the SharePoint site collection, as described in "Creating a New Site Collection for Microsoft SharePoint Server".
4. Configure the created Web site with LDAP directory using Claim-Based Authentication type (which uses the LDAP Membership Provider), as described in your SharePoint documentation.
5. Ensure that users who are present in the LDAP directory can log in to the SharePoint Web site and get proper roles.
6. Test the configuration to ensure that users who are present in the LDAP directory can log in to the SharePoint Web site and get proper roles, as described in your SharePoint documentation.
Perform all tasks described in "Installing Access Manager for Microsoft SharePoint Server Configured With LDAP Membership Provider".

This task includes installing a 11g WebGate for IIS and configuring a WebGate.dll for the individual SharePoint Web site.
Add an authentication scheme for this integration, as described in "Configuring an Authentication Scheme for Use With LDAP Membership Provider".
Synchronize directory servers, if needed, as described in "Ensuring Directory Servers are Synchronized".
Configure single-sign-on for office documents as described in "Configuring Single Sign-On for Office Documents".
Configure single sign-off, as described in "Configuring Single Sign-off for Microsoft SharePoint Server".
Finish by testing your integration to ensure it operates without problem, as described in "Testing the Integration".

41.8.1 About Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider

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.

See Also:

"Introduction to Integrating With the SharePoint Server" for a look at processing differences between this integration and the other integrations described in this chapter.

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

See Also:

"Integration Requirements"

41.8.2 Installing Access Manager for Microsoft SharePoint Server Configured With LDAP Membership Provider

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

Prerequisites

Perform Step 1 of the previous "About Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider".

To prepare your deployment for integration that includes LDAP Membership Provider

Install Oracle Identity Management and Access Manager.
Provision and install an IIS WebGate.
Configure Webgate.dll at the SharePoint Web site that you want to protect. For example:
1. Start the Internet Information Services (IIS) Manager: Click Start, Programs, Administrative Tools, Internet Information Services (IIS) Manager
2. Under Web Sites, double click the name of the SharePoint Web site to protect.
3. In the Middle pane, double click IIS Filters and click Add in the right pane.
4. Enter the filter name as Oracle WebGate.
5. Enter the following path to the Webgate.dll file.
```
WebGate_install_dir\webgate\iis\lib
```
6. Save and apply these changes.
7. Double click Authentication in the middle pane.
8. Verify that the following Internet Information Services settings are correct: Anonymous Authentication and Forms Authentication is enabled, and Windows Authentication is disabled.
  
  Note:
  
  For Claim-based Authentication to work with Access Manager, Windows Authentication for the SharePoint Site must be disabled.
9. Save and Apply these changes.
Execute ConfigureIISWebGate.bat tool on the IIS website.

Example: configureIISwebgate -oh C:\Oracle_WebGateHome -w C:\Oracle_WebGateInstance -site "Default WebSite"
Proceed to "Configuring an Authentication Scheme for Use With LDAP Membership Provider".

41.8.3 Configuring an Authentication Scheme for Use With LDAP Membership Provider

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

To configure an authentication scheme for SharePoint with LDAP Membership Provider:

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

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

Description: Optional
Authentication Level: Choose a level of security for the scheme.
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 (/)
Challenge Redirect: Enter your challenge redirect value, if required.
Choose an Authentication Module from those listed.
Challenge Parameters: Enter your challenge parameter values, if required.
Challenge URL: The URL the credential collector will redirect to for credential collection.
Click Apply to submit the new scheme, review details in the Confirmation window.
Optional: Click the Set as Default button to automatically use this with new Application Domains, then close the Confirmation window.
In the navigation tree, confirm the new scheme is listed, and then close the page.

41.8.4 Integrating SharePoint Server with OAM 11g using FBA

Access Manager is integrated with SharePoint 2013 OAM 11g using FBA (OAMCustomMembershipProvider). The following steps must be performed for this integration:

Update the WebGate profile (used for the integration). Enter user defined parameter IISIntegrationMode=true.
For Office Integration and “Open with explorer" feature support, update Authentication scheme "Challenge Parameter" with ssoCookie=max-age=<time in seconds>, to make OAMAuthnCookie as persistent cookie and to propagate it to WebDAV browser.
Add OAMCustomMembershipProvider.dll to GAC (Global Assembly Cache) using the following command:
gacutil -I OAMCustomMembershipProvider.dll

Update the web.config of the SharePoint Web Services>SecureTokenServiceApplication, substitute the following line in SecureTokenServiceApplication Membership provider.

Note: Sample web.config can be found at <WebGate Install Dir>\webgate\iis\tools\ConfigureIISConf\OAMCustomMembershipProvider\sample

type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

type="Oracle.OAMCustomMembershipProvider, OAMCustomMembershipProvider, Version=12.2.1.3, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1"

Update the SharePoint site default.apsx and add the following content after </asp:login> tag.

Note: Sample default.aspx can be found at <WebGate Install Dir>\webgate\iis\tools\ConfigureIISConf\OAMCustomMembershipProvider\sample

<asp:HiddenField EnableViewState="false" ID="loginTracker" runat="server" Value="autoLogin" /> 
<% 
bool autoLogin = loginTracker.Value == "autoLogin"; 
%> 
<script runat="server"> 
void Page_Load() 
{
	signInControl.LoginError += new EventHandler(OnLoginError); 
	NameValueCollection headers = Request.ServerVariables; 
	NameValueCollection queryString = Request.QueryString; 
	string loginasanotheruser = queryString.Get("loginasanotheruser"); 
	string username = Request.ServerVariables.Get("HTTP_OAM_REMOTE_USER"); 
	bool isOAMCredsPresent = username != null && username.Length > 0; 
	bool signInAsDifferentUser = loginasanotheruser != null && loginasanotheruser.Contains("true"); 
		if (isOAMCredsPresent) 
	{
		//Handling For UTF-8 Encoding in HeaderName 
		if (username.StartsWith("=?UTF-8?B?") && username.EndsWith("?=")) 
		{
			username = username.Substring("=?UTF-8?B?".Length, username.Length - 12); 
			byte[] decodedBytes = Convert.FromBase64String(username); 
			username = Encoding.UTF8.GetString(decodedBytes); 
		}
	}
		if (isOAMCredsPresent && loginTracker.Value == "autoLogin" && !signInAsDifferentUser) 
	{
		bool status=Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(SPContext.Current.Site.Url),username,"dummy"); 		if(status)
		{
			if (Context.Request.QueryString.Keys.Count > 1) 
			{
				Response.Redirect(Context.Request.QueryString["Source"].ToString()); 
			}
			else 
			Response.Redirect(Context.Request.QueryString["ReturnUrl"].ToString()); 
		}
		else
		{
			loginTracker.Value = ""; 
		}
	}
}
void OnLoginError(object sender, EventArgs e) 
{
	loginTracker.Value = ""; 
}
</script> 
</asp:Content>

Note:

After performing the above steps, if the following error is observed during login then revert the configuration changes done in steps 4 & 5 and try to access SharePoint site. The site should be accessible after OAM login and SharePoint login. If the SharePoint Site is still not accessible , then add alternate access mapping for SharePoint site and try to access SharePoint site, now the site should be accessible after OAM login and SharePoint login. Reconfigure steps 4 &5.

Line 73: { 
Line 74: 
Line 75: bool 
status=Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(SPContext.Current.Site.Url),username,"dummy"); 
Line 76: if(status){ 
Line 77: if (Context.Request.QueryString.Keys.Count > 1) 
Source File: 
c:\inetpub\wwwroot\wss\VirtualDirectories\3261\_forms\Default.aspx Line:75
Stack Trace: 
[NullReferenceException: Object reference not set to an instance of an object.] 
ASP._forms_default_aspx.Page_Load() in c:\inetpub\wwwroot\wss\VirtualDirectories\3261\_forms\Default.aspx:75 
Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase.OnLoad(EventArgs e) +299 
Microsoft.SharePoint.IdentityModel.Pages.FormsSignInPage.OnLoad(EventArgs e) +18 
System.Web.UI.Control.LoadRecursive() +94 
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2935

41.8.5 Ensuring Directory Servers are Synchronized

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

This is the same task that you perform for other integration scenarios in this chapter. When your SharePoint integration includes an LDAP Membership Provider, however, you can use a directory server that supports LDAP commands.

41.8.6 Testing the Integration

This is similar to the task you perform for other integration scenarios in this chapter. There are no differences when configured with LDAP Membership Provider.

41.9 Configuring Single Sign-On for Office Documents

Single sign-on for Office documents can be achieved by setting a persistent cookie in the authentication scheme.

To do this using OAM 11g, you need to set ssoCookie=max-age in the authentication scheme. This creates a persistent cookie which lasts for more than one session.

Note:

For integration based on Windows Native Authentication, you do not need to set the persistent cookie parameter.

Log in to the Oracle Access Management Console.
Find the Authentication Scheme being used and open the page.
In the Challenge Parameter, add:
```
  ssoCookie=max-age=1000000
```
Where, time-in-seconds represents the time interval when the cookie expires. For example, ssoCookie=max-age=3600 sets the cookie to expire in 1 hour (3600 seconds).
Save the change.
Configure centralized logout for the 11g or OAM Webgate.

41.10 Configuring Single Sign-off for Microsoft SharePoint Server

Manual Logout occurs when the user clicks the Logout button from SharePoint Server. You can configure the SharePoint Server logout URL in Access Manager so that when a user clicks the Logout button from SharePoint Server site, Access Manager logout is also triggered.

Closing the browser window after sign-off is always recommended, for security. Cookie time-out occurs when the overall user session is controlled by OAMAuthnCookie. Consider the following use-case:

FedAuth cookie time-out and OAMAuthnCookie is still valid: The user won't be challenged again because the OAMAuthnCookie is present. A new FedAuth cookie is generated (using the same flow described earlier).
OAMAuthnCookie time-out and FedAuth Cookie is still valid: Since each request is intercepted by the WebGate, the user is challenged for credentials again.

Access Manager provides single logout (also known as global or centralized log out) for user sessions. With Access Manager, single logout refers to the process of terminating an active user session.

This topic describes how to configure single sign-off for integration with SharePoint. Single sign-off kills the user session.

41.10.1 Configuring a Custom Logout URL in SharePoint Server

You can configure a custom logout URL in SharePoint Server.

To configure:

From the generated artifacts for WebGate, add logout.html to the SharePoint Server Site
Locate C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES.

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

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

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

To configure:

Copy signout.aspx from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS) to MySignout.aspx in the same path.

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>

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

41.11 Setting Up Access Manager and Windows Native Authentication

This section provides the following topics:

41.11.1 Setting Up Access Manager WNA

Configure Access Manager to use Windows Native Authentication.

41.11.2 Setting Up WNA With SharePoint Server

The following overview outlines the tasks that must be performed to set up WNA with Access Manager and the SharePoint Server.

Task overview: Setting up WNA with SharePoint Server

Complete the following prerequisite tasks:
- Perform tasks in "Required Microsoft Components".
- Create a SharePoint Web site, as described in "Creating a New Web Application in Microsoft SharePoint Server".
- Configure the SharePoint site collection, as described in "Creating a New Site Collection for Microsoft SharePoint Server".
- Test the configuration to ensure that users who are present in the directory server can log in to the SharePoint Web site and get proper roles, as described in your SharePoint documentation.
Install Access Manager as described in "Installing Access Manager for WNA and SharePoint Server".

This step includes installing the WebGate for IIS and configuring Webgate.dll for the individual SharePoint Web site.
Configure the Active Directory authentication provider, as follows:
1. Login to the WebLogic Console.
2. Go to Security Realm and click the realm being used.
3. Go to the Provider tab provider, click New.
4. Enter the provider name, select the Type ActiveDirectoryAuthenticator, click OK.
5. Select the newly created Provider, change Control Flag to Sufficient, and Save.
6. Go to Provider Specific tab, enter details for your Active Directory, and save these.
Perform "Testing Your WNA Implementation".

41.11.3 Installing Access Manager for WNA and SharePoint Server

You perform this task after you perform all prerequisites described in step 1 of the "Setting Up WNA With SharePoint Server". Installing most Access Manager components for this integration scenario is the same as for any other situation.

Installing the IIS WebGate is similar to installing any other WebGate. The WebGate should be installed with the IIS v7 Web server; later it can be configured at the specific SharePoint Web site level to be protected. For IIS, the WebGate must be configured at the "web sites" level. For Microsoft SharePoint Server, you must configure the WebGate for the specific SharePoint Web site level to be protected.

To install Access Manager for WNA and SharePoint Server

Install Access Manager as described in the Installing and Configuring Oracle Identity and Access Management.
Install the ISAPI WebGate as follows:
- Installing WebGates
- Installing Web components for the IIS Web server
  
  Next, you configure Webgate.dll at the SharePoint Web site that yo want to protect. Configuring Webgate.dll at the "Website level" protects all Web sites on the IIS Web server. However, configuring Webgate.dll at the "SharePoint Website" protects only the expected Web site.
Configure Webgate.dll at the SharePoint Web site that you want to protect. For example:
1. Start the Internet Information Services (IIS) Manager: Click Start, Programs, Administrative Tools, Internet Information Services (IIS) Manager.
2. Select the hostname from the Connections pane.
3. From the host name Home pane, double-click ISAPI Filters, look for any Webgate.dll; if it is present, select it and click Remove from the Action pane.
4. In the Connection pane, under Sites, click the name of the Web Site for which you want to configure a WebGate filter.
5. In the Home pane, double-click ISAPI Filters.
6. In the Actions pane, click Add…
7. In the Filter name text box of the Add ISAPI Filter dialog box, type WebGate as the name of the ISAPI filter.
8. In the Executable box, type the file system path of the WebGate ISAPI filter file or click the ellipsis button (...) to go to the folder that contains the Webgate.dll ISAPI filter file, and then click OK.
```
WebGate_install_dir\access\oblix\apps\Webgate\bin\Webgate.dll
```
Creating a Virtual Directory
1. Expand the Sites pane and select the Web Site for which you just configured the ISAPI filter (Webgate.dll).
2. On the Action pane, click View Virtual Directories and then select Add Virtual Directory.
3. In the Alias field, specify access and the physical path to the WebGate \access folder (or click the ellipsis button (...), go to the \access folder, then click OK).
```
WebGate_install_dir\access\
```
Set permissions on the Virtual Directory:
1. Select the "access" virtual directory created in Step 3.
2. From the access Home pane, double click Handler Mappings; from the Action pane, select Edit Feature Permissions….
3. Select Read, Script, and Execute, then click OK
Configure Access Manager to use Windows Native Authentication.
Configure Microsoft SharePoint Server Authentication to Classic Mode Authentication while creating a new Web Application in Microsoft SharePoint. In the Authentication Provider section, select Negotiate(Kerberos).
Go to IIS newly created SharePoint site and:
1. Open Authentication, Windows Authentication, Advance Settings.
2. Select Enable Kernel mode authentication.
3. Select providers, delete NTLM provider.
4. Add Negotiate:Kerberos and move it to the top level.
5. Restart IIS.
Proceed to "Testing Your WNA Implementation".

41.11.4 Testing Your WNA Implementation

Use the following steps to confirm your WNA implementation is working properly.

To test your WNA implementation

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.
Enter the URL of the protected resource.

41.12 Synchronizing User Profiles Between Directories

You need to synchronize user profiles between the SharePoint Server directory and the Access Manager directory.

Unless explicitly stated, this task should be performed for all integration scenarios in this chapter.

Note:

When your integration includes LDAP Membership Provider, you can use any directory server that supports LDAP commands.

To synchronize:

Uploading user data—If your Access Manager installation is configured for any directory server other than SharePoint Active Directory, you must load the user profiles that reside on the other directory server to SharePoint Active Directory.

Proceed to "Testing Your Integration"

41.13 Testing Your Integration

After you complete the tasks to enable integration, you should test to verify that integration is working.

This section contains the following topics:

41.13.1 Testing the SharePoint Server Integration

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

To test your SharePoint Server integration:

Navigate to any SharePoint Server Web page using your browser.

You are challenged for your credentials.
Log in by supplying the necessary credentials.
Verify that the page you requested is visible.
Optional: Check the Event Viewer to confirm that the access request was successful.

41.13.2 Testing Single Sign-On for the SharePoint Server Integration

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.

For example, use a resource defined in the Policy Manager. When single sign-on is working, you should be granted access to the page without having to supply credentials a second time.

To test single sign-on for your SharePoint Server integration:

Create and protect a new virtual site with a Application Domain (or use one you have already created.
Place a Web page anywhere in the tree of this virtual site.
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.

41.14 Troubleshooting

Internet Explorer File Downloads Over SSL Might Not Work

41.14.1 Internet Explorer File Downloads Over SSL Might Not Work

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.

Following are the parameters and their default value:

CachePragmaHeader no-cache

CacheControlHeader no-cache

You can modify the WebGate configuration not to set these headers at all (the values for these parameters would be kept blank). By this, it would mean that Access Manager will not control the caching behavior.