45 Integrating Microsoft SharePoint Server 2010 with Access Manager

This chapter explains how to integrate Access Managerwith a 10g Webgate and the Microsoft SharePoint Server 2010. It covers the following topics:

Note:

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

45.1 What is New in this Release?

This chapter includes the following new information:

  • Integrating with Microsoft SharePoint Server 2010

  • Integrating with Microsoft SharePoint Server 2010 Configured With LDAP Membership Provider

  • Integrating with Microsoft SharePoint Server 2010 using Access Manager WNA

Support for integration between Access Managerand SharePoint 2010 enables the following functionality:

  • When a user accesses SharePoint 2010 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".

  • Full feature parity with Share point 2010 integration with Access Manager 10g is provided to ease upgrades to Access Manager.

Note:

11g Webgates are not supported on the IIS Web server. Only 10g Webgate for IIS can be used for this integration.

45.2 Introduction to Integrating with the SharePoint Server 2010

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 2010 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 2010 enhances control over content, business processes, and information sharing. Microsoft SharePoint Server 2010 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 2010, 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 2010 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 2010 resources and all other Access Manager-protected resources. For more information, see:

45.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 2010. 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 2010 configured with the LDAP Membership Provider.

45.2.2 About Form-based Authentication With This Integration

You can integrate Access Manager with SharePoint 2010 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 2010 is claims-aware. When a user enters credentials on the Forms login page of SharePoint Relying Party (RP), these are passed to 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, 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 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.

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

  3. The user enters their OAM credentials; Webgate contacts the OAM Server, which verifies the credentials from LDAP and authenticates the user. Webgate generates the OAM native SSO cookie (ObSSOCookie), which enables single sign-on and sets the User ID (to username) header variable in the HTTP request and redirects the user to SharePoint RP site.

  4. The custom login page of SharePoint RP is invoked, which sets the username to the user ID set in header variable and password to ObSSOCookie value. The login page also automatically submits these credentials to SharePoint RP site.

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

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

  7. If the ObSSOCookie is valid, SharePoint STS generates 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.

45.2.3 About Authentication with Windows Impersonation and SharePoint 2010 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 2010. 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 2010 is the same as the supported integration with SharePoint 2007.

Note:

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

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

Process overview: Integration Authentication with Windows Impersonation

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

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

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

    • 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 SharePoint Portal Server.

45.2.4 About Access Manager and Windows Native Authentication

Access 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 authentication

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

    Note:

    Ensure that Internet Explorer security settings over internet and (or) intranet are adjusted properly to allow "auto-login".

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

  5. Access Manager sends authentication success information to WebGate.

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

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

    The maximum session timeout period configured for the Webgate is applicable to the generated ObSSOCookie.

45.3 Integration Requirements

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

45.3.1 Confirming Requirements

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

45.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 2010, 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 45-1 are required to integrate with Microsoft SharePoint Server 2010 (or Microsoft SharePoint Server 2010 configured with LDAP Membership Provider.)

Table 45-1 Access Manager Component Requirements

Component Description

10g Webgate

The ISAPI version 10g Webgate must reside on the same computer as SharePoint Server 2010.

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 2010 Configured With LDAP Membership Provider".

IISImpersonationModule.dll

This IIS-native Module is installed with Webgate. IISImpersonationModule.dll determine whether the Authorization Success Action HeaderVar has been set to impersonate and, if it has, the dll 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 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 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 2010.

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

Access Manager ASDK

Custom Membership provider uses Win 64-bit ASDK for ObSSOCookie validation.

45.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 2010:

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 45-2 describes the other components required for this integration.

See Also:

The following library location for Microsoft SharePoint Server 2010 and access to applicable software: 
http://technet.microsoft.com/en-us/library/cc262485.aspx

Table 45-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 he/she can enter his/her credentials (Username, 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 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 (username 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 provider validates ObSSOCookie by sending HTTP request to an IIS resource (HTML page) protected by Webgate or by making ASDK calls (based on your configuration).

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

The CustomMembershipProvider class is derived from LdapMembershipProvider class present in Microsoft.Office.Server.Security namespace.

IIS resource for Cookie validation

The custom membership provider validates the ObSSOCookie by sending HTTP request to IIS resource (HTML page) protected by Webgate or by making ASDK calls (based on configuration). The URL for the IIS resource is configured in web.config file of SharePoint site.

For the HTTP validation method, 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 status code set to 200 (OK) to the custom membership provider. Otherwise, 403 (Forbidden) error code is returned to the custom membership provider.

45.4 Preparing for Integration with SharePoint 2010

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

See Also:

Chapter 22 for 10g Webgate installation

Prerequisites

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

To prepare for integration with SharePoint 2010

  1. Install Oracle Identity Management and Access Manager as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

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

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

    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 *):


      Name
      Security mode (Agent host must match OAM Server)
      Auto Create Policies (Checked)

      Note:

      Do not specify a Base URL.

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

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

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

  3. ASDK: Download and install Access Manager Win 64-bit ASDK as described in Oracle Fusion Middleware Developer's Guide for Oracle Access Management

  4. Proceed as follows:

  5. Locate and download the 64-bit ISAPI 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 10g (10.1.4.3) Access System Language Packs you want to install.

  6. Launch the Webgate installer for your platform, installation mode, and Web server, then:

    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\access\Oblix\apps\Webgate\bin\).

  7. Before updating the Web server configuration, copy Webgate artifacts from the AdminServer to the computer hosting 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_install_dir/access/oblix/lib/ObAccessClient.xml
      Webgate_install_dir/access/oblix/config

    3. Restart the Webgate Web server.

    4. Restart the OAM Server that is hosting this Agent.

  8. Proceed as needed to complete this integration within your environment:

45.5 Integrating with Microsoft SharePoint Server 2010

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 2010 as outlined next.

Task overview: Integrating with Microsoft SharePoint Server 2010 includes

  1. Performing prerequisite tasks:

  2. Creating a new Web application (or site application) in SharePoint Server 2010 is described in following topics:

  3. "Setting Up Microsoft Windows Impersonation" (not used with LDAP Membership Provider).

  4. "Completing the SharePoint Server Integration".

  5. "Configuring Single Sign-off for Microsoft SharePoint Server 2010".

  6. "Synchronizing User Profiles Between Directories".

  7. "Testing Your Integration".

45.5.1 Creating a New Web Application in Microsoft SharePoint Server 2010

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

Prerequisites

Installing Microsoft components. See "Required Microsoft Components".

To create a new Web application in Microsoft SharePoint Server 2010

  1. On the host where SharePoint 2010 is installed, open the Central Administration home page: Start, All Programs, SharePoint 2010 Products, SharePoint 2010, 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 45-3 on the Create New Web Application page:

    Table 45-3 Create Web Application Options for Microsoft SharePoint Server 2010

    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 failover database server to configure a Failover Server.

    Service Application Connections

    You can use the default value or choose custom value and optionally select the services you want your web application to connect to.

  6. Click OK to create the new Web application, or click Cancel to cancel the process and return to the Application Management page.

  7. Proceed with "Creating a New Site Collection for Microsoft SharePoint Server 2010".

45.5.2 Creating a New Site Collection for Microsoft SharePoint Server 2010

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

To create a new site collection for Microsoft SharePoint Server 2010

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

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

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

    Section What You Configure in This Section

    Quota Template

    You can decide to use predefined quota template to limit resources used for this site collection or use "No quota" as appropriate.

    Title and Description

    Enter a title and description for the site collection

    Web Site Address

    Select a URL type, and specify a URL for the site collection.

    Template

    Select a template from the tabbed template control.

    Primary Site Collection Administrator

    Enter the user account name for the user you want to be the primary Administrator for the site collection.

    You can also browse for the user account by clicking the book icon to the right of the text box. You can verify the user account by clicking the check names icon to the right of the text box.

    Secondary Site Collection Administrator (optional)

    Enter the user account for the user that you want to be the secondary Administrator for the site collection.

    You can also browse for the user account by clicking the book icon to the right of the text box. You can verify the user account by clicking the Check Names icon to the right of the text box.

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

    See Also:

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

45.6 Setting Up Microsoft Windows Impersonation

Setting up impersonation, whether for SharePoint Server integration or for use by some other application, is described in the following sections.

Note:

Skip this section if you are integrating Microsoft SharePoint Server 2010 configured with LDAP Membership Provider. With LDAP Membership Provider, Windows impersonation is not used.

Task overview: Setting up impersonation

  1. Create a trusted user account for only impersonation in the Active Directory connected to SharePoint Server, as described in "Creating Trusted User Accounts".

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

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

  4. Add a header variable named IMPERSONATE to Authorization Success Action in the Application Domain for impersonation, as described in "Adding an Impersonation Response to an Authorization Policy".

  5. Configure IIS by adding the IISImpersonationModule.dll to your IIS configuration, as described in "Adding an Impersonation dll to IIS".

  6. Test impersonation, as described in "Testing Impersonation".

45.6.1 Creating Trusted User Accounts

This 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

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

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

Setting up a Trusted User Account

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

  1. Perform steps for your environment:

    • 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 45-2 Configuring Rights for the Trusted User in Windows Impersonation

Configuring Rights for the Trusted User.

45.6.3 Binding the Trusted User to Your Webgate

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

See Also:

Chapter 22 for details on managing 10g Webgates

To bind your trusted user to your Webgate

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

  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.

    SharePoint User Credentials in Webgate Registration

  11. Copy the artifacts as follows (or install 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 artifacts. For example


      10g Webgate/AccessClient: $Webgate_install_dir/oblix/lib/
      ObAccessClient.xml

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

45.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. 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 17 for details about Application Domains and policies.

To add an impersonation response to your Authorization Policy

  1. 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 Authorization Policy".

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

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

    Sample authorization success rule.

45.6.5 Adding an Impersonation dll to IIS

You 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

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

    Note:

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

  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 45-3 Registering the Impersonation Module

Graphic of IIS Security Settings

To configure site level Native Modules for Web sites

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

    Surrounding text describes site_level_imprsn.png.

  6. Proceed with:

45.6.6 Testing Impersonation

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

See Also:

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

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

  1. Select Start, Administrative Tools, Internet Information Services (IIS) Manager.

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

  3. 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 17for details about Application Domains and policies.

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

  1. 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 45-4 Verifying Event Viewer Settings

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

45.6.6.3 Testing Impersonation using a Web Page

You can also test impersonation using a dynamic test page, such as a .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

  1. Create a .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 45-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 a .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.

45.6.6.4 Negative Testing for Impersonation

To 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 Webgate

  1. In the Oracle Access Management Console, locate the Webgate.

    See "Searching for an OAM Agent Registration".

  2. In the text field, enter the exact name of the desired instance. For example: ImpersonationAgent and click Search.

  3. Open the desired Webgate registration page and Remove the credentials for the trusted user.

  4. Click Apply to save the change.

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

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

  7. Restore the trusted user to the Webgate registration page.

45.7 Completing the SharePoint Server Integration

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

Note:

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

Task overview: Completing the SharePoint Server integration

  1. Set up IIS security, as described in "Configuring IIS Security".

  2. Test the integration, as described in "Testing the SharePoint Server Integration".

45.7.1 Configuring IIS Security

Be sure to configure IIS Security before you continue.

To configure IIS Security for the SharePoint Server integration

  1. Select Start, Administrative Tools, Internet Information Services (IIS) Manager.

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

  3. Click Web Sites on the tree in the left pane.

  4. In the center pane, double-click on the Authentication under IIS.

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

Figure 45-5 Impersonation Authentication

Graphic of IIS Security Configuration.

45.8 Integrating with Microsoft SharePoint Server 2010 Configured With LDAP Membership Provider

In this scenario, Access Manager gets integrated with SharePoint 2010 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 2010 Configured with LDAP Membership Provider

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

    3. Configure the SharePoint site collection, as described in "Creating a New Site Collection for Microsoft SharePoint Server 2010".

    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.

  2. Perform all tasks described in "Installing Access Manager for Microsoft SharePoint Server 2010 Configured With LDAP Membership Provider".

    This task includes installing a 10g Webgate for IIS and configuring 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".

  4. Update the Application Domain that protects the SharePoint Web Site, as described in "Updating the Application Domain Protecting the SharePoint Web Site".

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

  6. Perform all steps in "Creating an Authorization Response for the OAMAuthCookie".

  7. Perform all steps in "Configuring and Deploying OAMCustomMemebershipProvider".

  8. Synchronize directory servers, if needed, as described in "Ensuring Directory Servers are Synchronized".

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

  10. Configure single sign-off, as described in "Configuring Single Sign-off for Microsoft SharePoint Server 2010".

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

45.8.1 About Integrating with Microsoft SharePoint Server 2010 Configured with LDAP Membership Provider

The previous scenario, "Integrating with Microsoft SharePoint Server 2010", 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). Webgate also sets SP_SSO_UID as a HeaderVar action for this user session. The Oracle Custom Membership provider in SharePoint validates the ObSSOCookie by one of the following methods, which can be configured:

  • HTTP Validation Method: Access Manager Custom Membership Provider makes HTTP/HTTPS request to a protected resource, Access Manager validates and compares the user login returned on Authorization success with SP_SSO_UID.

  • ASDK Validation method: In this, OAM Custom Membership provider makes OAM ASDK calls to validate ObSSOCookie.

See Also:

"Introduction to Integrating with the SharePoint Server 2010" 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 2010:

  • Is integrated with the LDAP Membership ProviderDoes not use Windows authentication

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

See Also:

"Integration Requirements"

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

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

Prerequisites

Perform Step 1 of the previous "Task overview: Integrating with Microsoft SharePoint Server 2010 Configured with LDAP Membership Provider".

To prepare your deployment for integration that includes LDAP Membership Provider

  1. Install Oracle Identity Management and Access Manager as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  2. Provision and install an ISAPI Webgate using steps in Chapter 22 and Chapter 25

  3. 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 ISAPI 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/access/oblix/apps/Webgate/bin/Webgate.dll

    6. Save and apply these changes.

    7. Double click Authentication in the middle pane.

    8. Confirm that Anonymous Authentication and Forms Authentication are enabled, and that Windows Authentication is disabled.

      Note:

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

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

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

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

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

    4. Save and apply these changes.

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

45.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, as described in this procedure.

See Also:

Chapter 16 for details about managing authentication schemes

To configure an authentication scheme for SharePoint with LDAP Membership Provider

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

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

    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.

45.8.4 Updating the Application Domain Protecting the SharePoint Web Site

This Application Domain was created when you provisioned the IIS Webgate to protect the Microsoft SharePoint Server 2010 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.

Note:

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

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 Webgate and you should be able to access it after providing correct Access Manager credentials: http(s)://host:port/ValidateCookie after providing correct Access Manager credentials.

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

Note:

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

See Also:

Chapter 17 for details about managing policies to protect resources

To update the Application Domain protecting the root SharePoint Web site

  1. From the Oracle Access Management Console, open the SharePoint w/LDAP-MP Application Domain.

    See "Searching for an Existing Application Domain".

  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 "Searching for an Existing Application Domain"; "Defining Authentication Policies for Specific Resources".

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

    • From the Type list, choose Header.

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

    • Click Apply.

    • See also: "Adding and Managing Policy Responses for SSO".

    Authorization Response for User Impersonation

  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"

45.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 = Header
        Name = SP_SSO_UID
        Return 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 "/ "

See Also:

Chapter 17 for details about authorization rules

To create an authorization response for SharePoint with LDAP Membership Provider

  1. From the Oracle Access Management Console, open the SharePoint w/LDAP-MP Authorization Policy: ProtectedResourcePolicy.

    See "Searching for an Authorization Policy".

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

    • From the Type list, choose Header.

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

    • Click Apply.

    • Repeat as needed.

    • See also: "Adding and Managing Policy Responses for SSO".

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

45.8.6 Creating an Authorization Response for the OAMAuthCookie

Here, you add the following Header Variable named OAMAuthCookie to the Application Domain as Responses under Authorization success:

        Type = Cookie
        Name = OAMAuthCookie
        Return Attribute = $user.userid

See Also:

Chapter 17 for details about policy responses

To create a Application Domain to protect the validation URL

  1. From the Oracle Access Management Console, open the SharePoint w/LDAP-MP Authorization Policy: Protected Resource Policy:

    See "Searching for an Authorization Policy".

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

    Redirection URL: Not required for this integration

    Return

            Type = Cookie
        Name = OAMAuthCookie
        Return Attribute = $user.userid

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

    • From the Type list, choose Cookie.

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

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

    • Repeat as needed.

  3. Proceed to "Configuring and Deploying OAMCustomMemebershipProvider".

45.8.7 Configuring and Deploying OAMCustomMemebershipProvider

You perform the following configuration steps in SharePoint to use the Access Manager Authentication Module to authenticate and authorize the user.

Note:

You can specify a default login page bundled in Webgate_install_dir\access\oblix\apps\Webgate\OAMCustomMembershipProvider\samples\Sample.Default.aspx.

To configure SharePoint to use OAM authentication Module

  1. Go to 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)
        {

            //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 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 two attributes at the end of the entry in Step 8 ValidationMode="OAMAsdk" or ValidationMode="OAMHttp", depending on the ObSSOCookie validation method requirement.

    Note:

    For ValidationMode="OAMAsdk", you must install the Win 64-bit ASDK with the installation path specified in the parameter AsdkPath="<ASDK INSTALL PATH>".
    <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="(&amp;(ObjectClass=person))" 
             scope="Subtree" 
             otherRequiredUserAttributes="sn,givenname,cn" 
                         ValidationURL="/ValidateCookie.html"
             OAMAuthUser="OAMAuthCookie
             ValidationMode="OAMAsdk"
                         AsdkPath="C:\AccessServerSDK"
                         />

    Note:

    For ValidationMode="OAMHttp", the Validation URL should be specified as shown next.
    ValidationURL="http(s)://host:port/ValidateCookie.html"
OAMAuthUser="OAMAuthCookie"

    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.

  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:

45.8.8 Enabling Logging for CustomMemeberShipProvider

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

45.8.9 Ensuring Directory Servers are Synchronized

Users in 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 LDAP Membership Provider, however, you can use a directory server that supports LDAP commands.

See Also:

"Synchronizing User Profiles Between Directories"

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

See Also:

"Testing the SharePoint Server Integration"

45.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, 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 need not set the persistent cookie parameter.

To define a persistent cookie for single sign-on for Office Documents

  1. 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 16-23)

    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 10g Webgate, as described in Chapter 19.

45.10 Configuring Single Sign-off for Microsoft SharePoint Server 2010

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

Note:

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

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

  • FedAuth cookie timeout 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 timeout and FedAuth Cookie is still valid: Since each request is intercepted by 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.

See Also:

Chapter 15 for details about configuring centralized logout for 10g Webgate with OAM 11g Servers

45.10.1 Configuring a Custom Logout URL in SharePoint Server 2010

To configure a Custom Logout URL in SharePoint Server 2010

  1. From the generated artifacts for Webgate, add logout.html to the SharePoint Server 2010 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 2010 with Impersonation.

45.10.2 Configuring Logout in SharePoint Server 2010 with Impersonation

You can skip this procedure if you do not have Impersonation configured.

To configure Logout in SharePoint Server 2010 with Impersonation

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

  2. In MySignout.aspx, below (<asp:content contentplaceholderid="PlaceHolderAdditionalPageHead" runat="server">) add the following script details:

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

  3. Save.

  4. Use this URL _layouts/Mysignout.aspx as custom logout URL for SharePoint Server 2010 in the case of Impersonation.

  5. Proceed with "Testing Your Integration".

45.11 Setting Up Access Manager and Windows Native Authentication

This section provides the following topics:

45.11.1 Setting Up Access Manager WNA

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

45.11.2 Setting Up WNA with SharePoint Server 2010

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

Task overview: Setting up WNA with SharePoint Server 2010

  1. Complete the following prerequisite tasks:

  2. Install Access Manager as described in "Installing Access Manager for WNA and SharePoint Server 2010".

    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:

    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.

  4. Perform "Testing Your WNA Implementation".

45.11.3 Installing Access Manager for WNA and SharePoint Server 2010

You perform this task after you perform all prerequisites described in step 1 of the "Task overview: Setting up WNA with SharePoint Server 2010". 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, Webgate must be configured at the "web sites" level. For Microsoft SharePoint Server 2010, you must configure Webgate for the specific SharePoint Web site level to be protected.

To install Access Manager for WNA and SharePoint Server 2010

  1. Install Access Manager as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  2. Install the ISAPI Webgate using steps in the following chapters of the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management:

    • 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:

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

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

  5. Set permissions to 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. Check boxes beside Read, Script, and Execute, then click OK

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

  7. Configure Microsoft SharePoint 2010 Authentication to Classic Mode Authentication while creating a new Web Application in Microsoft 2010 SharePoint. In the Authentication Provider section, select Negotiate(Kerberos).

  8. Go to IIS newly created SharePoint site and:

    1. Open Authentication, Windows Authentication, Advance Settings.

    2. Check Enable Kernel mode authentication.

    3. Select providers, delete NTLM provider.

    4. Add Negotiate:Kerberos and move it to top level.

    5. Restart IIS.

  9. Proceed to "Testing Your WNA Implementation".

45.11.4 Testing Your WNA Implementation

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

To test your WNA implementation

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

45.12 Synchronizing User Profiles Between Directories

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.

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"

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

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

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

    You are challenged for your credentials.

  2. Log in by supplying the necessary credentials.

  3. Verify that the page you requested is visible.

  4. Optional: Check the Event Viewer to confirm that the access request was successful.

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

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

  1. Create and protect a new virtual site with a Application Domain (or use one you have already created.

  2. Place a Web page anywhere in the tree of this virtual site.

  3. Using a browser, navigate to the page in the new virtual site.

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

45.14 Troubleshooting

45.14.1 Internet Explorer File Downloads Over SSL Might Not Work

This issue may occur if the server sends a Cache-control:no-store header or sends a Cache-control:no-cache header. 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.