Integrating Microsoft SharePoint Serverdocshare02.docshare.tips/files/28358/283584266.pdf ·...

51

Integrating Microsoft SharePoint Server with Access Manager 51- 1

51 Integrating Microsoft SharePoint Serverwith Access Manager

This chapter explains how to integrate Access Manager with a 10g WebGate and Microsoft SharePoint Server. It covers the following topics:

■ What is Supported in This Release?

■ Introduction to Integrating With the SharePoint Server

■ Integration Requirements

■ Preparing for Integration With SharePoint Server

■ Integrating With Microsoft SharePoint Server

■ Setting Up Microsoft Windows Impersonation

■ Completing the SharePoint Server Integration

■ Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider

■ Configuring Single Sign-On for Office Documents

■ Configuring Single Sign-off for Microsoft SharePoint Server

■ Setting Up Access Manager and Windows Native Authentication

■ Synchronizing User Profiles Between Directories

■ Testing Your Integration

■ Troubleshooting

51.1 What is Supported in This Release?Support for integration between Access Manager and SharePoint enables the following functionality:

Note: Access Manager with a 10g WebGate supports both Microsoft SharePoint Server 2010 and Microsoft SharePoint Server 2013. Other versions of Microsoft SharePoint Server are not supported in this release.

Unless explicitly stated, all details in this chapter apply equally to Access Manager integration with Microsoft SharePoint Server using the OAM impersonation plug-in, and Microsoft SharePoint Server configured with the LDAP Membership Provider.

Introduction to Integrating With the SharePoint Server

51-2 Administrator's Guide for Oracle Access Management

■ 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" on page 51-33.

■ Full feature parity with SharePoint integration with Access Manager 10g is provided to ease upgrades to Access Manager.

51.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:

Note: 11g WebGates are not supported on the IIS Web server. Only the WebGate 10g WebGate for IIS can be used for this integration.



■ About Windows Impersonation

■ About Form Based Authentication With This Integration

■ About Authentication With Windows Impersonation and SharePoint Server Integration

■ About Access Manager and Windows Native Authentication

51.2.1 About Windows ImpersonationUnless 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.

51.2.2 About Form Based Authentication With This IntegrationYou 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 ObSSOCookie 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 1. The user requests access to an SharePoint Server RP site.

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

Note: The WebGate only supports Form Based Authentication using the HTTP validation method (OAMHttp validation mode). The ASDK validation method (OAMAsdk validation mode) is not supported for Form Based Authentication.



2. The WebGate protecting the site intercepts the request, determines if the resource is protected, and challenges the user.

3. 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 (ObSSOCookie), 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.

4. 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 ObSSOCookie value. The login page also automatically submits these credentials to the SharePoint RP site.

5. The SharePoint RP site passes the credentials to SharePoint STS, which invokes the custom membership provider to validate the user credentials.

6. The custom membership provider gets the ObSSOCookie value (passed as a password) and sends it as part of the HTTP request to a resource protected by the WebGate to validate the ObSSOCookie.

7. If the ObSSOCookie is valid, SharePoint STS generates the SAML token and passes it to SharePoint RP.

8. SharePoint RP validates the SAML token and generates the FedAuth cookie. The user is then allowed to access the SharePoint RP site.

51.2.3 About Authentication With Windows Impersonation and SharePoint Server Integration

As described earlier, 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. 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 OAM Server domain. Windows based integration with SharePoint Server 2010 and 2013 is the same as the supported integration with SharePoint 2007.

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

Process overview: Integration Authentication with Windows Impersonation1. 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 ObSSOCookie in the user's browser, which enables single sign-on. The

Note: With the SharePoint 2007 integration, the Access Manager ISAPI extension (IISImpersonationExtension.dll) was used. Because the internal architecture of event handing changed with SharePoint 2010, Access Manager has changed the ISAPI extension to an HTTP module.



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.

51.2.4 About Access Manager and Windows Native AuthenticationAccess Manager provides support for Windows Native Authentication (WNA). Your environment may include:

■ Windows 2008 or 2008 R2 server

■ Internet Information services (IIS) 7 or 7.5

■ 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 authentication1. The user logs in to the desktop computer, and local authentication is completed

using the Windows Domain Administrator authentication scheme.

2. The user opens an Internet Explorer (IE) browser and requests an Access System-protected Web resource.

3. The browser notes the local authentication and sends a Kerberos token to the IIS Web server.

4. The WebGate installed on the IIS Web server sends the Kerberos token to the OAM 11g sever. The OAM 11g Server negotiates the Kerberos token with the KDC (Key distribution center).

5. Access Manager sends authentication success information to the WebGate.

6. The WebGate creates an ObSSOCookie and sends it back to the browser.

7. Access Manager authorization and other processes proceed as usual.

Note: Ensure that Internet Explorer’s security settings for the Internet and (or) intranet security zones are adjusted properly to allow automatic logon.

Integration Requirements


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

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

■ Confirming Requirements

■ Required Access Manager Components

■ Required Microsoft Components

51.3.1 Confirming RequirementsReferences 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

51.3.2 Required Access Manager ComponentsAccess 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 51–1 are required to integrate with Microsoft SharePoint Server (or Microsoft SharePoint Server configured with LDAP Membership Provider.)

Table 51–1 Access Manager Component Requirements

Component Description

10g WebGate The ISAPI version 10g 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 ObSSOCookie 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" on page 51-23.

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.

Integration Requirements


51.3.3 Required Microsoft ComponentsMinimum 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.

Table 51–2 describes the other components required for this integration.

Directory Server Access Managercan 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" on page 51-8.

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

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 51–2 Microsoft Requirements for this Integration


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.

Table 51–1 (Cont.) Access Manager Component Requirements


Preparing for Integration With SharePoint Server


51.4 Preparing for Integration With SharePoint ServerTasks 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 Managerfor your integration. This task applies to both integration scenarios in this chapter. To avoid repetition, information here is not repeated elsewhere.

The ISAPI 10g 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). 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.

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 ObSSOCookie 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 ObSSOCookie 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 ObSSOCookie value passed to it is valid.

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

Table 51–2 (Cont.) Microsoft Requirements for this Integration


Preparing for Integration With SharePoint Server


PrerequisitesInstall and test Microsoft components described in "Required Microsoft Components" on page 51-7.

To prepare for integration with SharePoint Server1. Install Oracle Identity Management and Access Manager as described in the

Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

2. Register a 10g WebGate for IIS Web server with Access Manager:

a. Log in to the Oracle Access Management Console. For example: http://host:port/oamconsole.

b. From the Welcome page, SSO Agent panel, click New OAM 10g Agent to open a fresh page.

c. On the Create: OAM Agent page, enter required details (those with an *):

Name SharePoint user name and password Security mode (Agent host must match OAM Server) Auto Create Policies (Checked)

d. Protected Resource List: In this table, enter individual resource URLs to be protected by this OAM Agent.

e. Public Resource List: In this table, enter individual resource URLs to be public (not protected).

f. Click Apply to submit the registration, check the Confirmation window for the location of generated artifacts, then close the window.

3. 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" on page 51-10.

4. Locate and download the 64-bit ISAPI WebGate installer as follows:

a. Go to Oracle Fusion Middleware 11gR1 Software Downloads at:

https://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

b. Click Accept License Agreement, at the top of the page.

See Also: Chapter 25 for information about the 10g WebGate installation.

Note: Do not specify a Base URL.

Note: Only 64-bit ISAPI WebGates are supported as described in "Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider" on page 51-23.

Integrating With Microsoft SharePoint Server


c. From the Access Manager Webgates (10.1.4.3.0) row, click the download link for the desired platform and follow on-screen instructions.

d. Store the WebGate installer in the same directory as any 10g (10.1.4.3) Access System Language Packs you want to install.

5. Launch the WebGate installer for your platform, installation mode, and Web server. See Chapter 25 for information about 10g WebGate installation.

Follow these steps:

a. Follow on-screen prompts.

b. Provide Administrator credentials for the Web server.

c. Language Pack—Choose a Default Locale and any other Locales to install, then click Next.

d. WebGate installation begins (IISImpersonationModule.dll will be installed in WebGate_install_dir\access\Oblix\apps\Webgate\bin\).

6. Before updating the Web server configuration, copy WebGate artifacts from the Admin Server to the computer hosting the WebGate.

a. 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)

b. On the OAM Agent host, add the artifacts to the WebGate path. For example:

WebGate_install_dir/access/oblix/lib/ObAccessClient.xml WebGate_install_dir/access/oblix/config

c. Restart the WebGate Web server.

d. (Optional.) Restart the OAM Server that is hosting this Agent. This step is recommended but not required.

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

51.5 Integrating With Microsoft SharePoint ServerThe 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 includes1. Performing prerequisite tasks:

■ Installing "Required Microsoft Components" on page 51-7.

■ "Preparing for Integration With SharePoint Server" on page 51-8

2. 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" on page 51-11

■ Creating a New Site Collection for Microsoft SharePoint Server on page 51-13

3. "Setting Up Microsoft Windows Impersonation" on page 51-14 (not used with LDAP Membership Provider).

4. "Completing the SharePoint Server Integration" on page 51-22.

5. "Configuring Single Sign-off for Microsoft SharePoint Server" on page 51-33.

6. "Synchronizing User Profiles Between Directories" on page 51-38.

7. "Testing Your Integration" on page 51-38.

51.5.1 Creating a New Web Application in Microsoft SharePoint ServerYou perform this task when integrating with Microsoft SharePoint Server, with or without LDAP Membership Provider.

PrerequisitesInstalling Microsoft components. See "Required Microsoft Components" on page 51-7.

To create a new Web application in Microsoft SharePoint Server1. 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.

Table 51–3 (Cont.) Create Web Application Options for Microsoft SharePoint Server




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

51.5.2 Creating a New Site Collection for Microsoft SharePoint ServerYou perform this task when integrating with Microsoft SharePoint Server, with or without LDAP Membership Provider.

To create a new site collection for Microsoft SharePoint Server1. 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:

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.

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


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.

Table 51–3 (Cont.) Create Web Application Options for Microsoft SharePoint Server


Setting Up Microsoft Windows Impersonation


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

■ "Setting Up Microsoft Windows Impersonation" on page 51-14

■ "Completing the SharePoint Server Integration" on page 51-22

■ "Configuring Single Sign-off for Microsoft SharePoint Server" on page 51-33

■ "Synchronizing User Profiles Between Directories" on page 51-38

■ "Testing Your Integration" on page 51-38

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

Task overview: Setting up impersonation1. Create a trusted user account for only impersonation in the Active Directory

connected to SharePoint Server, as described in "Creating Trusted User Accounts" on page 51-15.

2. Give the trusted user the special right to act as part of the operating system, as described in "Assigning Rights to the Trusted User" on page 51-15.

3. 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" on page 51-16.

4. 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" on page 51-17.

5. Configure IIS by adding the IISImpersonationModule.dll to your IIS configuration, as described in "Adding an Impersonation DLL to IIS" on page 51-18.

6. Test impersonation, as described in "Testing Impersonation" on page 51-20.

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.

See Also: "Task overview: Integrating with Microsoft SharePoint Server Configured with LDAP Membership Provider" on page 51-24

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.

Table 51–4 (Cont.) Create a Web Application to Host a Site Collection for SharePoint




51.6.1 Creating Trusted User AccountsThis 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 account1. Perform the following steps on the computer hosting your SharePoint Server

installation:

■ Windows 2008: 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.

Figure 51–1 Setting up a Trusted User Account for Windows Impersonation

51.6.2 Assigning Rights to the Trusted UserYou need to give the trusted user the right to act as part of the operating system.

To give appropriate rights to the trusted user1. Perform steps for your environment:

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.



■ Windows 2008: 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

51.6.3 Binding the Trusted User to Your WebGateYou need to bind the trusted user to the 10g WebGate that communicates with Access Managerby supplying the authentication credentials for the trusted user, as follows.

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

2. From the Welcome page, SSO Agent panel, click New OAM 10g Agent to open a fresh page:

3. On the Create: OAM Agent page, enter required details (those with an *) to register this WebGate.

See Also: Chapter 25 for details on managing 10g WebGates



4. Protected Resource List: In this table, enter individual resource URLs to be protected by this OAM Agent, as shown in Table 14–9.

5. Public Resource List: In this table, enter individual resource URLs to be public (not protected), as shown in Table 14–9.

6. 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)).

7. Click Apply to submit the registration.

8. Check the Confirmation window for the location of generated artifacts, then close the window.

9. In the navigation tree, open the Agent page.

10. SharePoint Requirements: Add trusted user credentials in the fields shown here:, and click Apply.

11. Copy the artifacts as follows (or install the WebGate and then copy these artifacts):

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

b. On the computer hosting the agent, copy the artifacts. For example

10g WebGate/AccessClient: $WebGate_install_dir/oblix/lib/ ObAccessClient.xml

c. Proceed to "Adding an Impersonation Response to an Authorization Policy".

51.6.4 Adding an Impersonation Response to an Authorization PolicyAn Application Domain and basic policies to protect your SharePoint resources was created when you registered the WebGate with Access Manager. Now 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.

See Also: Chapter 20 for details about Application Domains and policies.



To add an impersonation response to your Authorization Policy1. From the Oracle Access Management Console Policy Configuration tab, open

Application Domains, find and open the DesiredDomain, then open the DesiredPolicy.

See "Searching for an Existing Application Domain" on page 20-12.

Here DesiredDomain refers to the Application Domain created specifically for impersonation (Impersonation for example). DesiredPolicy is your default policy created during agent registration. By default, no policy Responses exist until you create them.

2. Responses: On the open 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.

■ See also: "Adding and Managing Policy Responses for SSO" on page 20-47.

3. Click Add to save the Response, which is used for the second WebGate request (for authorization). Following is a sample.

51.6.5 Adding an Impersonation DLL to IISYou are ready to configure IIS Web server for this 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:

■ To configure and register ImpersonationModule to IIS

■ To configure site level Native Modules for Web sites

To configure and register ImpersonationModule to IIS1. Select Start, Administrative Tools, Internet Information Services (IIS) Manager.

2. In the left pane of IIS 7, click the hostname.

3. In the middle pane, under the IIS header, double click Modules.

4. In the right pane, click Configure Native Modules and click Register.

5. In the window, provide a module Name (for example, Oracle Impersonation Module).



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

7. Click OK to register the module.

8. Check the name of the newly created module and click OK to apply the module across the Web sites.

Figure 51–3 Registering the Impersonation Module

To configure site level Native Modules for Web sites1. Click the plus icon (+) icon to left of Sites.

2. Click the site where you want to enable Impersonation.

3. In the Middle pane, under IIS, double click Modules.

4. In the right pane, click Configure Native Modules and select the Impersonation Module registered earlier.

5. Click OK.

Note: If any spaces exist in the path (for example, C:\Program Files\Oracle\...) surround the entire string with double quotes (" ").



6. Proceed with:

■ Testing Impersonation

■ Completing the SharePoint Server Integration

51.6.6 Testing ImpersonationYou can test to ensure that impersonation is working properly in the following ways before you complete the integration:

■ Outside the SharePoint Server context or test single sign-on, as described in "Creating an IIS Virtual Site Not Protected by SharePoint Server" on page 51-20

■ Using the Event Viewer, as described in "Testing Impersonation Using the Event Viewer" on page 51-21

■ Using a Web page, as described in "Testing Impersonation using a Web Page" on page 51-22

■ Using negative testing as described in "Negative Testing for Impersonation" on page 51-22

51.6.6.1 Creating an IIS Virtual Site Not Protected by SharePoint ServerTo 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 Server1. Select Start, Administrative Tools, Internet Information Services (IIS) Manager.

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



2. Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.

3. Right-click Web Sites on the tree in the left pane, then navigate to New, Web Site on the menu.

4. Respond to the prompts by the Web site creation wizard.

5. After you create the virtual site, you must protect it with policies in an Application Domain. See Chapter 20 for details about Application Domains and policies.

51.6.6.2 Testing Impersonation Using the Event ViewerWhen 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 Viewer1. Select Start Menu, Event Viewer.

2. In the left pane, right-click Security, then click Properties.

3. Click the Filter tab on the Security property sheet.

4. 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 51–4 Verifying Event Viewer Settings

5. Create a new IIS virtual server (virtual site).

6. Place a target Web page anywhere in the tree on the virtual site.

7. Point your browser at the Web page.

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

Completing the SharePoint Server Integration


51.6.6.3 Testing Impersonation using a Web PageYou 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 variables1. 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:

Example 51–1 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>

2. Create an IIS virtual site, or use the one you created for the previous task.

3. Place an .asp page or Perl script (such as the sample in the preceding listing) anywhere in the tree of the new virtual site.

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

51.6.6.4 Negative Testing for ImpersonationTo conduct negative testing for impersonation, you need to unbind the trusted user from the WebGate, as explained in the following procedure.

To unbind the trusted user from your WebGate1. In the Oracle Access Management Console, locate the WebGate.

See "Searching for an OAM Agent Registration" on page 16-20.

2. Open the desired WebGate registration page and remove the credentials for the trusted user.

3. Click Apply to save the change.

4. Restart the IIS server and in a browser window, go to a protected code page (previously accessible to the trusted user).

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

6. Restore the trusted user to the WebGate registration page.

51.7 Completing the SharePoint Server IntegrationYou need to complete several procedures to set up a Access Manager with SharePoint Server integration.

Integrating With Microsoft SharePoint Server Configured With LDAP Membership Provider


Task overview: Completing the SharePoint Server integration1. Set up IIS security, as described in "Configuring IIS Security" on page 51-23.

2. Test the integration, as described in "Testing the SharePoint Server Integration" on page 51-38.

51.7.1 Configuring IIS SecurityBe sure to configure IIS Security before you continue.

To configure IIS Security for the SharePoint Server integration1. 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 the Authentication under IIS.

5. Ensure that Anonymous access is enabled and Windows Authentication is disabled.

Figure 51–5 Impersonation Authentication

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

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.

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

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



Task overview: Integrating with Microsoft SharePoint Server Configured with LDAP Membership Provider1. Preparing for this integration:

a. Install "Required Microsoft Components", as described on page 51-7.

b. Create a SharePoint Web site, as described in "Creating a New Web Application in Microsoft SharePoint Server" on page 51-11.

c. Configure the SharePoint site collection, as described in "Creating a New Site Collection for Microsoft SharePoint Server" on page 51-13.

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

e. Ensure that users who are present in the LDAP directory can log in to the SharePoint Web site and get proper roles.

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

2. Perform all tasks described in "Installing Access Manager for Microsoft SharePoint Server Configured With LDAP Membership Provider" on page 51-25.

This task includes installing a 10g WebGate for IIS and configuring a WebGate.dll for the individual SharePoint Web site.

3. Add an authentication scheme for this integration, as described in "Configuring an Authentication Scheme for Use With LDAP Membership Provider" on page 51-26.

4. Update the Application Domain that protects the SharePoint Web Site, as described in "Updating the Application Domain Protecting the SharePoint Web Site" on page 51-27.

5. In the new Application Domain, create an authorization rule for this integration, as described in "Creating an Authorization Response for Header Variable SP_SSO_UID" on page 51-29.

6. Perform all steps in "Creating an Authorization Response for the OAMAuthCookie" on page 51-29.

7. Perform all steps in "Configuring and Deploying OAMCustomMembershipProvider" on page 51-30.

8. Synchronize directory servers, if needed, as described in "Ensuring Directory Servers are Synchronized" on page 51-33.

9. Configure single-sign-on for office documents as described in "Configuring Single Sign-On for Office Documents" on page 51-33.

10. Configure single sign-off, as described in "Configuring Single Sign-off for Microsoft SharePoint Server" on page 51-33.

11. Finish by testing your integration to ensure it operates without problem, as described in "Testing the Integration" on page 51-33.

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

The previous scenario, "Integrating With Microsoft SharePoint Server" on page 51-10, 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 ObSSOCookie and sends it to the user's browser to facilitate single sign-on (SSO). The WebGate also sets SP_SSO_UID 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 SP_SSO_UID.

Requirements: This integration requires that Microsoft SharePoint Server:

■ Must be integrated with the LDAP Membership Provider

■ Must not use Windows authentication

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

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

This procedure describes how to prepare your installation for integration with Microsoft SharePoint Server Configured with LDAP Membership Provider.

PrerequisitesPerform Step 1 of the previous "Task overview: Integrating with Microsoft SharePoint Server Configured with LDAP Membership Provider" on page 51-24.

To prepare your deployment for integration that includes LDAP Membership Provider1. Install Oracle Identity Management and Access Manager as described in the Oracle

Fusion Middleware Installation Guide for Oracle Identity and Access Management.

2. Provision and install an ISAPI WebGate using steps in Chapter 25 and Chapter 28

3. Configure Webgate.dll at the SharePoint Web site that you want to protect. For example:

a. Start the Internet Information Services (IIS) Manager: Click Start, Programs, Administrative Tools, Internet Information Services (IIS) Manager

b. Under Web Sites, double click the name of the SharePoint Web site to protect.

c. In the Middle pane, double click ISAPI Filters and click Add in the right pane.

d. Enter the filter name as Oracle WebGate.

e. Enter the following path to the Webgate.dll file.

See Also: "Introduction to Integrating With the SharePoint Server" on page 51-2 for a look at processing differences between this integration and the other integrations described in this chapter.

See Also: "Integration Requirements" on page 51-6



WebGate_install_dir/access/oblix/apps/Webgate/bin/Webgate.dll

f. Save and apply these changes.

g. Double click Authentication in the middle pane.

h. Verify that the following Internet Information Services settings are correct: Anonymous Authentication and Forms Authentication is enabled, and Windows Authentication is disabled.

i. Save and Apply these changes.

4. Go to the Web sites level to protect and create an /access virtual directory that points to the newly installed WebGate_install_dir. For instance:

a. Under Web Sites, right-click the name of the Web site to be protected.

b. Select Add Virtual Directory named with the alias "access" that points to the appropriate WebGate_install_dir\access.

c. Under Access Permissions, check Read, Run Scripts, and Execute.

d. Save and apply these changes.

5. Proceed to "Configuring an Authentication Scheme for Use With LDAP Membership Provider".

51.8.3 Configuring an Authentication Scheme for Use With LDAP Membership ProviderWhen your integration includes the LDAP Membership Provider, only three Access Manager authentication methods are supported, as described in this procedure.

To configure an authentication scheme for SharePoint with LDAP Membership Provider1. From the Oracle Access Management Console, Policy Configuration tab, expand

the Shared Components node.

2. Click the Authentication Schemes node, then click the Create button in the tool bar.

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 (/)

Note: For Claim-based Authentication to work with the Access Manager, Windows Authentication for the SharePoint Site must be disabled.

See Also: Chapter 19 for details about managing authentication schemes



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.

13. Proceed with "Updating the Application Domain Protecting the SharePoint Web Site".

51.8.4 Updating the Application Domain Protecting the SharePoint Web SiteThis Application Domain was created when you provisioned the IIS WebGate to protect the Microsoft SharePoint Server Web site for the integration scenario with LDAP Membership Provider.

Within an Application Domain, resource definitions exist as a flat collection of objects. Each resource is defined as a specific type, and the URL prefix that identifies a document or entity stored on a server and available for access by a large audience. The location is specified using an existing shared Host Identifier.

You need to use the authentication scheme that you created earlier. To validate the ObSSOCookie, you must create another policy for a resource protected by a WebGate; for example: /ValidateCookie. This resource should be deployed on a Web server protected by a WebGate and you should be able to access it after providing correct Access Manager credentials: http(s)://host:port/ValidateCookie

This example uses SharePoint w/LDAP-MP as the Application Domain name. Your environment will be different.

Note: If the SharePoint resource is protected with an Access Manager client-cert authentication scheme, you might need to add to the PATH environment variable C:\Program Files\Microsoft Office Servers\14.0\Bin;C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN.

Note: For this integration, leave empty the URL Prefix. Do not enter a region to be appended to the URL prefix.

Note: Step 4 includes an alternative Authentication Scheme to protect the SharePoint Web site with a Form authentication scheme.

See Also: Chapter 20 for details about managing policies to protect resources



To update the Application Domain protecting the root SharePoint Web site1. From the Oracle Access Management Console, open the SharePoint w/LDAP-MP

Application Domain.

See "Searching for an Existing Application Domain" on page 20-12.

2. Open the Resources tab, then click the New Resource button.

3. On the Resource Definition page, select or enter your details for a single resource and click Apply:

Type: http Description (optional): Protecting SharePoint Website Host Identifier: Select the host identifier that you added earlier. Resource URL: Enter /ValidateCookie. Protection Level: Protected Authentication Policy (if level is Protected) Authorization Policy (if level is Protected and Authentication Policy is chosen) 4. In the Protected Resource Policy for Authentication, add a defined resource:

See "Viewing or Editing an Authentication Policy" on page 20-36.

■ Click the Resources tab on the Authentication Policy page.

■ Click the Add button on the Resources tab.

■ Locate and select the desired resource definition, then click Add Selected.

■ Click Apply to add the resources.

■ Repeat to add more resources.

5. Click the Responses tab, then click its Add button and:

■ In the Name field, enter a unique name for this response (SP_SSO_UID).


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

■ Click Apply.


6. Add a Policy: Add a policy for a resource used with the HTTP validation method, If selected.

7. Before you enable this Application Domain, proceed to "Creating an Authorization Response for Header Variable SP_SSO_UID"



51.8.5 Creating an Authorization Response for Header Variable SP_SSO_UID This topic describes how to add an Authorization Response for the integration configured with LDAP Membership Provider. For this integration, you add the following Header Variable to the Application Domain as Responses for Authorization success:

Type = HeaderName = SP_SSO_UIDReturn Attribute = $user.userid

In this case:

■ The Return Attribute is the login attribute used in Login

■ This authorization rule protects the root SharePoint Web site "/ "

To create an authorization response for SharePoint with LDAP Membership Provider1. From the Oracle Access Management Console, open the SharePoint w/LDAP-MP

Authorization Policy: ProtectedResourcePolicy.

See "Searching for an Authorization Policy" on page 20-39.

2. Click to activate the Authorization Policy Responses tab, then click its Add button:

■ In the Name field, enter a unique name for this response (SharePoint w/LDAP-MP).



■ Click Apply.

■ Repeat as needed.


3. Proceed to "Creating an Authorization Response for the OAMAuthCookie".

51.8.6 Creating an Authorization Response for the OAMAuthCookieHere, you add the following Header Variable named OAMAuthCookie to the Application Domain as Responses under Authorization success:

Type = CookieName = OAMAuthCookieReturn Attribute = $user.userid

To create a Application Domain to protect the validation URL1. From the Oracle Access Management Console, open the SharePoint w/LDAP-MP

Authorization Policy: Protected Resource Policy:

See "Searching for an Authorization Policy" on page 20-39.

2. Click the Responses tab, then click its Add button and:

Redirection URL: Not required for this integration

See Also: Chapter 20 for details about authorization rules

See Also: Chapter 20 for details about policy responses



Return

Type = CookieName = OAMAuthCookieReturn Attribute = $user.userid

■ In the Name field, enter a unique name for this response (OAMAuthCookie).

■ From the Type list, choose Cookie.


■ Click Apply to submit the response, then close the confirmation window.

■ Repeat as needed.

3. Proceed to "Configuring and Deploying OAMCustomMembershipProvider."

51.8.7 Configuring and Deploying OAMCustomMembershipProviderYou perform the following configuration steps in SharePoint to use the Access Manager Authentication Module to authenticate and authorize the user.

To configure SharePoint to use OAM authentication Module 1. Go to the physical location of the SharePoint Web site directory. For example:

C:\Inetpub\wwwroot\wss\VirtualDirectories\SharePoint website Name

2. From the folder_forms, copy the file Default.aspx as Default.ORIG.aspx.

3. Open Default.aspx, search for </asp:login>, add the following after the line, and then save the file:

<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_SP_SSO_UID"); HttpCookie ObSSOCookie = Request.Cookies["ObSSOCookie"]; bool isOAMCredsPresent = username != null && username.Length > 0 && ObSSOCookie != null && ObSSOCookie.Value != null; bool signInAsDifferentUser = loginasanotheruser != null && loginasanotheruser.Contains("true");

if (isOAMCredsPresent) {

Note: You can specify a default login page bundled in this file:

WebGate_install_dir\access\oblix\apps\Webgate\ OAMCustomMembershipProvider\samples\Sample.Default.aspx



//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,"ObSSOCookie:"+ObSSOCookie.Value); 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 = }

} else {

// DO NOTHING } } void OnLoginError(object sender, EventArgs e) { loginTracker.Value = ""; } </script>

4. Go to IIS Manager and click the Plus icon (+) before Sites.

5. Click on the plus icon (+) before SharePoint Web Services.

6. Right -click SecurityTokenServiceApplication, then click Explore.

7. Create a backup copy of Web.config as Web.config.ORIG, then open Web.config.

8. In the membership provider entries for enabling the LDAP membership provider go to <membership>, <providers>, type, and then modify the type value as follows:

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

9. Add the following attribute at the end of the entry in Step 8 ValidationMode="OAMHttp" to indicate the ObSSOCookie validation method.

<add name="membership"



type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1" server="HOST1.COM" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="cn=users,dc=bored,dc=com" userObjectClass="person" userFilter="(&(ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" ValidationURL="http(s)://host:port/ValidateCookie.html" OAMAuthUser="OAMAuthCookie ValidationMode="OAMHttp" />

10. Save the file.

11. Using command prompt go to the following directory:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe

12. Type:

gacutil -l OAMCustomMembershipProvider

13. Confirm that no results are returned.

14. Type the following.

gacutil -i <Webgate_install_dir>\access\oblix\apps\Webgate\OAMCustomMembershipProvider\OAMCustomMembershipProvider.dll

15. Type:

gacutil -l OAMCustomMembershipProvider

16. Confirm that one result is returned.

17. Restart the SharePoint Web site.

18. Proceed as follows:

■ Enabling Logging for CustomMemberShipProvider

■ Ensuring Directory Servers are Synchronized

■ Configuring Single Sign-off for Microsoft SharePoint Server

51.8.8 Enabling Logging for CustomMemberShipProviderIf you want to enable logs for the Oracle Custom Membership Provider, you must configure the DebugFile parameter in the configuration file for the Oracle Custom

Note: The resource configured for ValidationURL must be present on the Web server. Also, the value of the OAMAuthUser parameter should be configured as the authorization return action as described in Step 6.

Configuring Single Sign-off for Microsoft SharePoint Server


Membership Provider. For example: a sample entry for the DebugFile=Location_of_logs_file":

type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1" DebugFile="c:\Debug.txt"

51.8.9 Ensuring Directory Servers are SynchronizedUsers 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.

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

51.9 Configuring Single Sign-On for Office DocumentsSingle sign-on for Office documents can be achieved by setting a persistent cookie in the authentication scheme. To do this, you need to set ssoCookie:max-age in the authentication scheme. This creates a persistent cookie which lasts for more than one session.

To define a persistent cookie for single sign-on for Office Documents1. Log in to the Oracle Access Management Console.

2. Find the Authentication Scheme being used and open the page.

3. In the Challenge Parameter, add:

ssoCookie:max-age=1000000 (Table 19–30)

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

4. Save the change.

5. Configure centralized logout for the 10g WebGate, as described in Chapter 25.

51.10 Configuring Single Sign-off for Microsoft SharePoint ServerManual Logout occurs when the user clicks the Logout button from SharePoint Server. You can also configure the SharePoint Server logout URL in Access Manager so that

See Also: "Synchronizing User Profiles Between Directories" on page 51-38

See Also: "Testing the SharePoint Server Integration" on page 51-38

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

Configuring Single Sign-off for Microsoft SharePoint Server


when a user clicks the Logout button from SharePoint Server site, Access Manager logout is also triggered.

Cookie time-out occurs when the overall user session is controlled by ObSSOCookie. Consider the following use-case:

■ FedAuth cookie time-out and ObSSOCookie is still valid: The user won't be challenged again because the ObSSOCookie is present. A new FedAuth cookie is generated (using the same flow described earlier).

■ ObSSOCookie 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.

■ Configuring a Custom Logout URL in SharePoint Server

■ Configuring Logout in SharePoint Server With Impersonation

51.10.1 Configuring a Custom Logout URL in SharePoint Server

To configure a Custom Logout URL in SharePoint Server1. 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.

Note: Closing the browser window after sign-off is always recommended, for security.

See Also: Chapter 22 for details about configuring centralized logout for 10g WebGate with OAM 11g Servers

Setting Up Access Manager and Windows Native Authentication


51.10.2 Configuring Logout in SharePoint Server With ImpersonationYou can skip this procedure if you do not have Impersonation configured.

To configure Logout in SharePoint Server with Impersonation1. 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".

51.11 Setting Up Access Manager and Windows Native AuthenticationThis section provides the following topics:

■ Setting Up Access Manager WNA

■ Setting Up WNA With SharePoint Server

■ Installing Access Manager for WNA and SharePoint Server

■ Testing Your WNA Implementation

51.11.1 Setting Up Access Manager WNAConfigure Access Manager to use Windows Native Authentication, as described in Chapter 49.

51.11.2 Setting Up WNA With SharePoint ServerThe 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 Server1. Complete the following prerequisite tasks:

■ Perform tasks in "Required Microsoft Components" on page 51-7.

■ Create a SharePoint Web site, as described in "Creating a New Web Application in Microsoft SharePoint Server" on page 51-11.

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

2. Install Access Manager as described in "Installing Access Manager for WNA and SharePoint Server" on page 51-36.

This step includes installing the WebGate for IIS and configuring Webgate.dll for the individual SharePoint Web site.

3. Configure the Active Directory authentication provider, as follows:

a. Login to the WebLogic Console.

b. Go to Security Realm and click the realm being used.

c. Go to the Provider tab provider, click New.

d. Enter the provider name, select the Type ActiveDirectoryAuthenticator, click OK.

e. Select the newly created Provider, change Control Flag to Sufficient, and Save.

f. Go to Provider Specific tab, enter details for your Active Directory, and save these.

4. Perform "Testing Your WNA Implementation" on page 51-37.

51.11.3 Installing Access Manager for WNA and SharePoint ServerYou perform this task after you perform all prerequisites described in step 1 of the "Task overview: 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 Server1. Install Oracle Access Management Access Manager as described in the Oracle

Fusion Middleware Installation Guide for Oracle Identity and Access Management.

2. Install the ISAPI WebGate using steps in Chapter 25 for:

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

3. Configure Webgate.dll at the SharePoint Web site that you want to protect. For example:

a. Start the Internet Information Services (IIS) Manager: Click Start, Programs, Administrative Tools, Internet Information Services (IIS) Manager.

b. Select the hostname from the Connections pane.



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

d. In the Connection pane, under Sites, click the name of the Web Site for which you want to configure a WebGate filter.

e. In the Home pane, double-click ISAPI Filters.

f. In the Actions pane, click Add…

g. In the Filter name text box of the Add ISAPI Filter dialog box, type WebGate as the name of the ISAPI filter.

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

4. Creating a Virtual Directory

a. Expand the Sites pane and select the Web Site for which you just configured the ISAPI filter (Webgate.dll).

b. On the Action pane, click View Virtual Directories and then select Add Virtual Directory.

c. 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\

5. Set permissions on the Virtual Directory:

a. Select the "access" virtual directory created in Step 3.

b. From the access Home pane, double click Handler Mappings; from the Action pane, select Edit Feature Permissions….

c. Select Read, Script, and Execute, then click OK

6. Configure Access Manager to use Windows Native Authentication, as described in Chapter 49.

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

8. Go to IIS newly created SharePoint site and:

a. Open Authentication, Windows Authentication, Advance Settings.

b. Select Enable Kernel mode authentication.

c. Select providers, delete NTLM provider.

d. Add Negotiate:Kerberos and move it to the top level.

e. Restart IIS.

9. Proceed to "Testing Your WNA Implementation".

51.11.4 Testing Your WNA ImplementationUse the following steps to confirm your WNA implementation is working properly.

Synchronizing User Profiles Between Directories


To test your WNA implementation1. Log in to the machine as someone who is a user of both Access Manager and the

Windows operating system.

2. Enter the URL of the protected resource.

51.12 Synchronizing User Profiles Between DirectoriesUnless explicitly stated, this task should be performed for all integration scenarios in this chapter.

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

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

51.13 Testing Your IntegrationAfter you complete the tasks to enable integration, you should test to verify that integration is working.

This section contains the following topics:

■ Testing the SharePoint Server Integration

■ Testing Single Sign-On for the SharePoint Server Integration

51.13.1 Testing the SharePoint Server IntegrationYou can verify that a user can access SharePoint Server resources through Access Manager authentication and SharePoint Server authorization.

To test your SharePoint Server integration1. 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.

51.13.2 Testing Single Sign-On for the SharePoint Server IntegrationYou 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 ObSSOCookie 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.

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

Troubleshooting


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

51.14 Troubleshooting■ Internet Explorer File Downloads Over SSL Might Not Work

51.14.1 Internet Explorer File Downloads Over SSL Might Not WorkThis 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.

Troubleshooting


Integrating Microsoft SharePoint Serverdocshare02.docshare.tips/files/28358/283584266.pdf ·...

Documents

Transcript of Integrating Microsoft SharePoint Serverdocshare02.docshare.tips/files/28358/283584266.pdf ·...