| Oracle® Access Manager Integration Guide 10g (10.1.4.2) Part Number E10356-01 |
|
|
View PDF |
| Oracle® Access Manager Integration Guide 10g (10.1.4.2) Part Number E10356-01 |
|
|
View PDF |
SharePoint Portal Server is a secure, scalable, enterprise portal server. This chapter explains how to integrate with the Microsoft SharePoint Portal Server 2003 and SharePoint Office Server 2007. It covers the following topics:
Oracle Access Manager provides identity management and security functions, including Web-based single sign-on, user self-service and self-registration, user provisioning, reporting and auditing, policy management, dynamic groups, and delegated administration. Oracle Access Manager integrates with all leading directory servers, application servers, Web servers, and enterprise applications.
SharePoint Portal Server is a secure, scalable, enterprise portal server that builds on Windows Server 2003 Microsoft Internet Information Services (IIS) and Windows SharePoint Services (WSS). SharePoint Portal Server can aggregate SharePoint sites, information, and applications into a single, easy-to-use portal. In addition to WSS functionality, SharePoint Portal Server incorporates additional features such as News and Topics as well as personal and public views for My Site, and so on.
SharePoint Office Server 2007 enhances control over content, business processes, and information sharing. Office SharePoint Office Server 2007 provides centralized access and control over documents, files, Web content, and e-mail, and enables users to submit files to portals for collaborative work.
When Oracle Access Manager is integrated with SharePoint Portal Server 2003 or SharePoint Office Server 2007, the Access System handles user authentication through an ISAPI filter for IIS and an ISAPI wildcard extension, which enables single sign-on between Oracle Access Manager and SharePoint Portal Server. WSS handles resource request authorization for all SharePoint Portal Server resources.
This integration provides single sign-on to SharePoint Portal Server 2003 and SharePoint Office Server 2007 resources and all other Oracle Access Manager-protected resources.
This integration relies on Windows impersonation, which enables a trusted user in the Windows server domain to assume the identity of any user requesting a target resource in SharePoint Portal Server 2003 or SharePoint Office Server 2007. 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.
Successful integration with SharePoint Portal Server 2003 or SharePoint Office Server 2007 requires both Oracle Access Manager and Microsoft components, which must be installed and configured to support impersonation as well as integration.
This section contains the following topics:
Any references to specific versions and platforms in this chapter are for demonstration purposes.
You can find support and certification information at the following URL:
http://www.oracle.com/technology/documentation/
You must register with OTN to view this information.
Also, you can see the supported versions and platforms for this integration on Metalink, as follows.
To view information on Metalink
In your browser, enter the following URL:
Log in to MetaLink.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Identity Management and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, Oracle Access Manager Certification to display the certification matrix.
Table 17-1 lists the Microsoft components required to integrate with SharePoint Portal Server 2003 and SharePoint Office Server 2007.
Note:
Be sure to install SP1 or later to have all critical updates.Table 17-1 Microsoft Requirements
| Component | Description |
|---|---|
|
Operating System |
Windows Server for the SharePoint Server host. Note: Any of the five editions is acceptable. The Active Directory Domain Controller must reside on a Windows Server 2003 computer. This computer does not have to be the SharePoint Portal Server host. |
|
Extended Services |
|
|
Directory Service |
Active Directory. You install this after installing Windows Server 2003. You can connect a SharePoint Server directly to the Active Directory Domain Controller or to a different instance of Active Directory, as follows:
Note: For all scenarios mentioned here, SharePoint Server can use either Desktop SQL or an instance of SQL Server installed on a machine within the Active Directory domain. |
|
SharePoint Server |
SharePoint Server. After installing Active Directory, you install SharePoint Portal Server 2003 or SharePoint Office Server 2007 on a computer where Windows Server 2003 and IIS are already installed. |
|
Security Service |
Kerberos Key Distribution Center (KDC) installs automatically as part of Windows Server 2003. |
The components in Table 17-2 are required to integrate with SharePoint Server and SharePoint Portal Server.
Table 17-2 Component Requirements
| Item | Requirement/Description |
|---|---|
|
WebGate |
The ISAPI version WebGate that ships with Oracle Access Manager must reside on the same machine as SPPS. Within the context of the SPPS integration, this WebGate is an ISAPI filter that intercepts HTTP requests for Web resources and works with the Access 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. |
|
IISImpersonationExtension. dll |
This dll is an IIS wildcard extension that checks whether the Authorization Success Action HeaderVar has been set to impersonate, and if it has been, the dll creates a Kerberos U4S2Self ticket so that the special trusted user in the SPPS Active Directory can impersonate the user who originally made the request. When you run the ISAPI WebGate installation wizard, IISImpersonationExtension.dll installs automatically within the WebGate directory structure, but you still need to configure the dll manually to enable impersonation and SPPS integration. |
|
Oracle Access ManagerDirectory |
Oracle Access Manager can be connected to any supported directory service including, but not limited to, LDAP and Active Directory. It can even connect to the same instance of Active Directory used by SPPS. In any case, the directory does not have to reside on the same machine as SPPS and the WebGate protecting it. |
|
Other Components |
The SPPS integration also requires installation of the other standard Oracle Access Manager system components such as the Access Server with which the WebGate protecting your SPPS installation is configured to interoperate. For details see the Oracle Access Manager Installation Guide. Except for the WebGate protecting SPPS, your components do not need to reside on the machine hosting SPPS. Note that if you install either Policy Manager or WebPass (or both) on the same IIS virtual server as SPPS, you must exclude the URL paths to those components through SharePoint Managed Paths. (See "To define managed paths in SharePoint" for details). You may find it easier to install Policy Manager and WebPass on a machine other than the one on which SPPS resides or, at the very least, on an IIS virtual server other than the one on which SPPS has been installed. |
Oracle Access Manager uses the Windows impersonation feature to facilitate user access to SharePoint Portal Server resources.
Process overview: Request processing with the SharePoint Portal Server integration
The user requests access to an SharePoint Portal Server resource.
The WebGate ISAPI filter protecting SharePoint Portal Server intercepts the request, determines whether the target resource is protected, and if it is, challenges the user for authentication credentials.
If the user supplies credentials and the Access Server validates them, the WebGate sets an ObSSOCookie in the user's browser, thus enabling single sign-on.
The WebGate also sets an HTTP header variable called "impersonate", whose value is set to the authenticated user's LDAP uid (or samaccountname, if the user account exists in Active Directory, or userPrincipalName, if the user account exists in a multi-domain Active Directory forest).
Note:
At this point, IIS considers the user to be anonymous, since the impersonation has not yet been set.The Oracle Access Manager ISAPI wildcard extension IISImpersonationExtension.dll checks for the Authorization Success Action header variable named impersonate.
When such a header variable exists, the wildcard extension 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.
Any references to specific versions and platforms in this chapter are made for demonstration purposes. For complete support information, see the Certify tab at https://metalink.oracle.com.
There are several phases to integrate with the SharePoint Portal Server.
Task overview: Integrating with SharePoint Portal Server
Install the Microsoft components, as described in "Installing Microsoft Components".
Install Oracle Access Manager, as described in "Installing Oracle Access Manager Components".
Set up impersonation, as described in "Setting Up Impersonation".
Complete the integration, as described in "Completing the SharePoint Server Integration".
Except where noted, all Microsoft SharePoint Portal Server-related components must be installed on the same host machine, including the following software:
Windows Server 2003
Microsoft IIS v6 Web Server
SharePoint Portal Server (and underlying WSS)
The following Microsoft components can be installed on machines other than the one hosting the main SharePoint Portal Server installation:
Active Directory (see Table 17-1 for installation location details).
SQL Server must be installed on a machine in the Active Directory domain only if the Active Directory Domain Controller is installed on the same machine as SharePoint Portal Server. See Table 17-1 for installation location details.
Additional SharePoint Portal Server front end servers.
One or more back end servers containing SharePoint Portal Server resources such as Web pages, documents, or applications.
Note:
All of the machines hosting the preceding SharePoint Portal Server-related components must be in the same Active Server domain as the SharePoint Portal Server server you are installing.The following task overview includes references to documentation that provides procedures and steps you need to complete when installing the Microsoft components for this integration.
Task overview: Installing Microsoft Components
Install Windows Server 2003 on the machine that will host your SharePoint Portal Server installation, as described in the appropriate Microsoft documentation.
Install IIS on the machine that will host your SharePoint Portal Server installation, as described in the appropriate Microsoft documentation.
Install Active Directory, as described in the appropriate Microsoft documentation and the Oracle Access Manager Installation Guide; also, see Table 17-1 for installation location considerations.
If SharePoint Portal Server and Active Directory Domain Controller reside on the same machine, you must also install Microsoft SQL Server on that machine as well, as described in Table 17-1.
Install SharePoint Services and SharePoint Portal Server on the root virtual server (which uses port 80, by default) of your IIS installation or on some other IIS virtual server.
Create and set up your portal.
After you install SharePoint Portal Server, stop and test the installation to ensure it operates correctly before you integrate with Oracle Access Manager.
Task Overview: Creating and setting up a Sharepoint portal
Create a portal.
See "To create a portal" for details.
Upload a test document.
See "To upload a document to the portal" for details.
Create audiences.
See "To create audiences" for details.
Edit audiences (if necessary).
See "To edit audiences" for details.
Compile audiences.
See "To compile audiences" for details.
In the Portal Site and Virtual Server Configuration section of the SharePoint Portal Server Central Administration page for server on which you wish to create a portal, click Create a portal site.
In the Portal Creation Options section, click Create a portal.
In the Site Name section, in the Name box, type a name for the portal site. This name will appear at the top of most pages for the portal site.
In the Virtual server list within the Site URL section, click the existing virtual server on the server that will host the portal site.
In the URL box, type the URL through which users connect to the portal site. By default, this URL is http://server_name/. If you choose a virtual server that has a port number other than 80, the port number appears as part of the URL, that is, http://server_name:port_number/.
Note:
Make sure to specify the load-balanced URL, not the local server URL.In the Account name box of the Owner section, type the account name of the portal site owner in the format Domain\user_name. The portal site owner manages content and user access.
In the E-mail address box, type the e-mail address for the portal site owner, then click OK.
On the Create Portal Confirmation for server_name page, click OK to begin creating the portal site.
The Operation Status page displays as the portal is created. Following successful portal site creation, the Operation Successful page appears. At this point, you can begin detailed configuration of the portal site.
To upload a document to the portal
Using your Web browser, navigate to the home page for the portal.
Select Upload Document from the Actions list.
On the Upload Document page, click Browse, navigate to the document you wish to add, then click Open.
To add multiple documents simultaneously, click Upload Multiple Files.
To replace a file of the same name within the library, select the checkbox titled "Overwrite existing file(s)?"
Click Save, then click Close.
Audiences, which are based on jobs or tasks within an organization, match specified users to target content while preventing all other users from viewing that content. On the Managing Audiences page for the site you wish to configure, click Create audience.
On the Create Audience page, type a name and description for the audience.
Click either "Satisfy all rules" or "Satisfy any of the rules," then click OK.
After the Add Audience Rule page appears, add whatever rules you wish to govern access to the site content. (You can also add rules through the View Audience Properties page.) For details, consult the Microsoft SharePoint Portal Server documentation on Adding and Editing Audience Rules.
Compile the audience so that the content is targeted to that audience. See "To compile audiences".
On the View Audience Properties page for the site you are configuring, click View Audience Properties, then click Edit audience.
On the Edit Audience page, change the name or description of the audience, as necessary.
Click either "Satisfy all rules" or "Satisfy any of the rules," then click OK.
When the View Audience Properties page reappears, Add, Delete, or Edit the audience rules, as necessary.
Review the statistics for the audience, checking the number of current members and the most recent time of compilation. When you are satisfied with all the settings for the audience and the rules associated with that audience, compile the audience so that your changes take effect. See "To compile audiences".
Any changes you make to an audience or the rules associated with them do not take effect until you compile the audience. Navigate to the Manage Audiences page and check the compilation status and most recent compilation time for the audience you wish to compile. (You can also view the number of incomplete audiences on this page).
Either start a compilation or set a compilation schedule.
The ISAPI Webgate for SharePoint Portal Server must be installed on the same machine as SharePoint Portal Server. The rest of your installation can reside on the same machine or any other machine.
If you choose to install on a different machine (which can be a Solaris, Linux, or Windows machine), it can be set up for Active Directory (if the host machine runs Windows Server 2003) or some other directory service, such as NetScape Directory Server (if the machine runs Solaris or Linux, for example).
If both Oracle Access Manager and SharePoint Portal Server are set up for different instances of Active Directory, both instances must belong to the same Active Directory domain.
To install Oracle Access Manager components for SharePoint Portal Server integration
On either the same machine that hosts SharePoint Portal Server (or on a different machine), install an Identity Server and a WebPass, then set up the Identity System as described in the Oracle Access Manager Installation Guide and see Table 17-2 for WebPass installation considerations.
On either the same machine that hosts SharePoint Portal Server (or a different machine), install Policy Manager and one or more instances of the Access Server, as described in the Oracle Access Manager Installation Guide and Table 17-2.
On the machine hosting the SharePoint Portal Server instance you are trying to integrate, install an ISAPI WebGate.
The IISImpersonationExtension.dll will be installed as part of the package in the following directory:
WebGate_install_dir\access\Oblix\apps\webgate\bin\
Where WebGate_install_dir is the directory where you installed the WebGate.
If you installed Policy Manager or WebPass on the same IIS virtual server as SharePoint Portal Server, complete activities in "Defining Managed Paths in SharePoint".
You complete the following procedure only if the Policy Manager or WebPass resides on the same IIS virtual server as SharePoint Portal Server and listens to the same port as that IIS virtual server. For instance, the default virtual IIS server uses port 80, as do many Policy Manager and WebPass installations; therefore, you need to change the port used by one application or exclude the path used by the Oracle Access Manager component through the Define Managed Paths feature in SharePoint.
To define managed paths in SharePoint
Select Start, Administrative Tools, SharePoint Central Administration.
In the Virtual Server Configuration section, click Configure virtual server settings.
In the Virtual Server list, click Default Web Site or the name of the virtual server on which both SharePoint Portal Server and the Oracle Access Manager components are installed.
In the Virtual Server Management section, select Define Managed Paths.
In the Add a Path section, type the path to Policy Manager or WebPass, then click the button marked Excluded path.
Click OK to add the path to the list of excluded paths.
Integrating with SharePoint Office Server 2007 is very similar to integrating with SharePoint Portal Server 2003. Many of the steps for performing the two integrations are identical.
The following paragraphs describe how to create and set up a Web site using SharePoint Office Server 2007.
Note:
The SharePoint Portal Server 2003 portal creation object model is deprecated in SharePoint Office Server 2007. In SharePoint Office Server 2007, portal sites use the same provisioning process as Windows SharePoint Services sites. You must update any scripts that create portals sites to use the Microsoft Windows SharePoint Services 3.0 site creation APIs. If you require a new vServer (Web application), use the Windows SharePoint Services CreateWebApplication API before creating the site. See the following URL for details:Task overview: Integrating with SharePoint Portal Server
Install the Microsoft components, as described in "Installing Microsoft Components".
Create a new Web application or site application in SharePoint Office Server 2007.
See "To create a new Web application in SharePoint Office Server 2007" and "To create a new site collection for SharePoint Office Server 2007" for details.
Install Oracle Access Manager, as described in "Installing Oracle Access Manager Components".
Set up impersonation, as described in "Setting Up Impersonation".
Complete the integration, as described in "Completing the SharePoint Server Integration".
To create a new Web application in SharePoint Office Server 2007
From the Windows desktop, click Start, then All Programs, then Microsoft Office Server, then click SharePoint 3.0 Central Administration.
From the Central Administration home page, click Application Managment.
From the Application Managemetn page, in the SharePoint Web Application Management section, click Create or Extend Web Application.
From the Create or Extend Web Application page, in the Adding a SharePoint Web Application section, click Create a New Web Application.
Configure the following on the Create New Web Application page:
Table 17-3 Create Web Application Options for SharePoint Office Server 2007
| Section | What You Configure in This Section |
|---|---|
|
IIS Web Site |
In this section you configure the following settings for your new Web application, as follows:
|
|
Security Configuration |
In this section you configure authentication and encryption for your Web application, as follows:
|
|
Load Balanced 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:
|
|
Reset Internet Information Services |
In this section, choose whether to allow SharePoint Office Server 2007 to restart IIS on other farm servers. The local server must be restarted manually for the process to finish. If you do not select this option and you have more than one server in the farm, you must wait until the IIS Web site is created on all servers and then run This choice is unavailable if your farm only contains a single server. |
|
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:
|
Click OK to create the new Web application, or click Cancel to cancel the process and return to the Application Management page.
To create a new site collection for SharePoint Office Server 2007
On the SharePoint Central Administration home page, click the Application Management tab on the top link bar.
On the Application Management page, in the SharePoint Site Management section, click Create Site Collection.
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 17-4 Create a Web Application to Host a Site Collection for SharePoint Office Server 2007
| Section | What You Configure in This Section |
|---|---|
|
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. |
Setting up impersonation, whether for SharePoint Server integration or for use by some other application, is described in the following sections:
Task overview: Setting up impersonation
Create a trusted user account for only impersonation in the Active Directory connected to SharePoint Server, as described in "Creating a Trusted User Accounts".
Give the trusted user the special right to act as part of the operating system., as described in "Assigning Rights to the Trusted User".
Bind the trusted user to the WebGate by supplying the authentication credentials for the trusted user, as described in "Binding the Trusted User to Your WebGate".
Add a header variable named impersonate to Authorization Success Action in the policy domain for impersonation, as described in "Adding an Impersonation Action to a Policy Domain".
Configure IIS by adding the IISImpersonationExtension.dll to your IIS configuration, as described in "Adding an Impersonation dll to IIS".
Test impersonation, as described in "Testing Impersonation".
This special user should not be used for anything other than impersonation.
To create a trusted user account
On the Windows 2003 machine hosting your SharePoint Portal Server installation, select Start, Programs, Manage Your Server, Domain Controller (Active Directory), Manage Users and Computers in Active Directory.
In the Active Directory Users and Computers window, right-click Users on the tree in the left pane, then select New, User.
In the First name field of the pane entitled New Object - User, enter an easy-to-remember name such as SPPSImpersonator.
Copy this same string to the User logon name field, then click Next.
In succeeding panels, you will be asked to choose a password and then retype it to confirm.
Note:
Oracle recommends that you chose a very complex password, because your trusted user is being given very powerful permissions. Also, be sure to check the box marked Password Never Expires. Since the impersonation extension 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.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
Select Control Panel, Administrative Tools, Domain Controller Security Policy.
On the tree in the left pane, click the plus icon (+) next to Local Policies.
Click User Rights Assignment on the tree in the left pane.
Double-click "Act as part of the operating system" in the right pane.
Click Add User or Group.
In the Add User or Group panel, type the User logon name of the trusted user (SPPSImpersonator in our example) in the User and group names text entry box, then click OK to register the change.
You need to bind the trusted user to the WebGate by supplying the authentication credentials for the trusted user, as follows.
To bind your trusted user to your WebGate
Point your browser to your Access System Console. For example:
http://hostname.domain.com:port/access/oblix
where hostname is the DNS name of the machine hosting your Policy Manager, domain is the name of the server domain to which the machine belongs, and port is the number of the port to which Policy Manager listens.
Navigate to Access System Console, Access System Configuration, AccessGate Configuration.
Select the name of the Webgate you want to modify.
The Details for AccessGate page appears with a summary of the configuration information for this WebGate. At the bottom of this Web page are fields for Impersonation Username and Impersonation Password.
Click the Modify button at the bottom of the Details for AccessGate page.
After the Modify AccessGate page appears, scroll to the bottom and enter the username and password for the trusted user account you created through the task .
For example:
Click the Save button to commit the changes and return to the Details page.
A bind has been created for the WebGate and the trusted user. The WebGate is now ready to provide impersonation on demand. The demand is created by an Authorization Success Action in a policy domain created for impersonation.
You must create or configure a policy domain to protect your SharePoint resources. You do this by adding an Authorization Success Action with a return type of "headerVar," the "name" parameter set to "Impersonate", and the "return attribute" parameter set to "samaccountname" for a single-domain Active Directory installation or "userPrincipalName" for a multi-domain Active Directory forest.
You must also choose an easy-to-remember name for the domain, such as Impersonation Policy Domain.
For details on creating a policy domain, see the Oracle Access Manager Access System Administration Guide.
To add an impersonation action to your policy domain
Navigate to the Access System Console and log in, for example:
http://hostname.domain.com:port/access/oblix
Where hostname is the DNS name of the machine hosting your WebPass and Policy Manager, domain is the name of the server domain to which the machine belongs, and port is the number of the port to which Policy Manager listens.
Navigate to the Authorization Definitions page of the policy domain you want to change:
Policy Manager, My Policy Domains, PolicyName, Authorization Rules
Where PolicyName refers to the policy domain you created specifically for impersonation (ImpersonationPolicyDomain in our example).
Currently defined authorization rules are listed. If none are listed, click the Add button and complete the form to create one.
Click the link to the rule to which you want to add the impersonation action to expand the description.
Click the Actions tab, directly under the Authorization Rules tab.
The Authorization Success page appears, with a separate section for Authorization Success and Authorization Failure. If no actions are identified, you must add them. If actions are provided, you can modify them.
You need to add a header variable named "impersonate" to the Authorization Success Action in the policy domain for impersonation.
On the Authorization Success page, click the Add or Modify button.
In the Authorization Success area, fill in the Return details.
For example:
Type: HeaderVarName: IMPERSONATEReturn attribute: uid or samaccountname (Active Directory username, the Windows domain user for the desired folder)
Where "HeaderVar" is the return Type, "IMPERSONATE" is Name of the header variable for impersonation, and the Return value of uid or samaccountname is based on the directory being used.
Save the rule, which is used for the second WebGate request (for authorization).
The following is a sample screen shot.
You are ready to configure IIS by adding the IISImpersonationExtension.dll to your IIS configuration. See "To add the impersonation dll to your IIS configuration" for details.
If you have multiple Web sites, where some are integrated with SharePoint Portal Server while others are not, you may want to enable impersonation for the Web sites that are not integrated with the SharePoint Portal Server. To do this, you must install Impersonation.dll at any level of the Web site tree and add a wildcard extension for Web sites. See "To add a wildcard extension for Web sites" for details.
To add the impersonation dll to your IIS configuration
Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.
Click Web Service Extensions on the tree in the left pane.
Double-click Oblix WebGate in the right panel to open the Properties panel.
Click the Required Files tab.
Click Add.
In the Path to file text box, type the full path to IISImpersonationExtension.dll.
By default, the path is:
WebGate_install_dir\access\oblix\apps\webgate\bin\ IISImpersonationExtension.dll
Where WebGate_install_dir is the directory of your WebGate installation.
Note:
If any spaces exist in the path (for example, C:\Program Files\Oracle\...) surround the entire string with double quotes (" ").Click OK.
Click the General tab on the Web Services Extension Properties panel, then verify that the box "Do not check the file location" is not checked.
Verify that the Allow button to the left of the Oblix WebGate icon is greyed out, which indicates that the dll is allowed to run as a Web service extension.
Note:
If Allow is not greyed out, click it so that it becomes greyed out. When Allow is greyed out, this indicates that the highlighted file is permitted to run on the IIS virtual server.To add a wildcard extension for Web sites
If Oracle Access Manager is not integrated with SharePoint Server, configure a wildcard extension for Web sites by navigating as follows:
Click Start, then click Administrative Tools, then click Internet Information Services (IIS) Manager.
Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.
Click Web Sites in the tree in the left pane.
Right-click the icon representing your Web site, then click Properties in the menu.
Click the Home Directory tab.
Click the Configuration button.
In the list box for Wildcard application maps, click the entry for IISImpersonationExtension.dll to highlight it, then click Edit.
Ensure that the box is unchecked.
You can test Impersonation in the following ways:
Outside the SharePoint Server context or test single sign-on, as described in "Creating an IIS Virtual Site Not Protected by SharePoint Server"
Using the Event Viewer, as described in "Testing Impersonation Using the Event Viewer"
Using a Web page, as described in "Testing Impersonation using a Web Page"
Using negative testing as described in "Negative Testing for Impersonation"
To test the impersonation feature outside the SharePoint Server context or to test single sign-on, you will need a target Web page on an IIS virtual Web site that is not protected by SharePoint Server. You create such a virtual Web site by completing the following task.
To create an IIS virtual site not protected by SharePoint Server
Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.
Right-click Web Sites on the tree in the left pane, then navigate to New, Web Site on the menu.
Respond to the prompts by the Web site creation wizard.
After you create the virtual site, you must protect it with a policy domain, as described in the Oracle Access Manager Access System Administration Guide.
When you complete impersonation testing using the Windows 2003 Event Viewer, you must configure the event viewer before conducting the actual test.
To test impersonation through the Event Viewer
Select Start Menu, Event Viewer.
In the left pane, right-click Security, then click Properties.
Click the Filter tab on the Security property sheet.
Verify that all Event Types are checked, and the Event Source and Category lists are set to All, then click OK to dismiss the property sheet.
Your Event Viewer is now configured to display information about the HeaderVar associated with a resource request.
Create a new IIS virtual server (virtual site).
Place a target Web page anywhere in the tree on the virtual site.
Point your browser at the Web page.
If impersonation is working correctly, the Event Viewer will report the success of the access attempt.
You can also test impersonation using a dynamic test page, such as an .asp page or a perl script, that can return and display information about the request.
To test impersonation through a Web page that displays server variables
Create an .asp page or perl script that will display the parameters AUTH_USER and IMPERSONATE, which can resemble the sample page presented in the following listing:
Create an IIS virtual site, or use the one you created for the previous task.
Place an .asp page or perl script (such as the sample in the preceding listing) anywhere in the tree of the new virtual site.
Point your browser at the page, which should appear, with both AUTH_USER and IMPERSONATE set to the name of the user making the request.
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
Log in to the Access System Console at a URL similar to the following:
http://hostname.domain.com:port/access/oblix
Where hostname is the DNS name of the computer hosting your Access Manager, domain is the name of the server domain to which the machine belongs, and port is the number of the port to which Access Manager listens.
Select Access System Console, then click Access System Configuration, then click AccessGate Configuration.
Select the name of the Webgate that you want to modify.
The Details for AccessGate page appears with a summary of the configuration information for this WebGate. At the bottom of this Web page are fields for Impersonation Username and Impersonation Password.
Click the Modify button at the bottom of the Details for AccessGate page.
The Modify AccessGate page appears.
Remove the credentials for the trusted user.
Click Save.
You return to the Details page.
Restart the IIS server.
Point your browser at the sample .ASP code page that you created in "To test impersonation through a Web page that displays server variables".
An error message page should appear. Values for AUTH_USER and IMPERSONATE are necessary for impersonation credentials to be bound to a WebGate.
You need to complete several procedures to set up a Oracle Access Manager/SharePoint Server integration.
Task overview: Setting up the SharePoint Server integration
Set up IIS security, as described in "Configuring IIS Security".
Configure the wildcard extension for each SharePoint Server virtual server for which you wish to enable integration, as described in "Configuring the Wildcard Extension".
Edit the web.config file, as described in "Editing web.config".
Test the integration, as described in "Testing Your Integration".
Be sure to configure IIS Security before you continue.
To configure IIS Security for the SharePoint Server integration
Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.
Click Web Sites on the tree in the left pane.
Right-click the icon on the tree in the left pane that represents the SharePoint Server server you are protecting with your WebGate, then select Properties from the menu.
In the property sheet for the SharePoint Server server, click the Directory Security tab.
In the Authentication and access control section of the Directory Security tab, click Edit.
In the Authentication Methods panel, click the box labelled Enable anonymous access so that a check appears, then click OK to complete the task.
Note:
Enable anonymous access does not enable anonymous users to access the SharePoint Server. Rather, this setting configures IIS to relinquish access control to the Access System.You are ready to configure the wildcard extension for each SharePoint Portal Server virtual server for which you wish to enable integration.
To configure the wildcard extension for SharePoint Portal Server virtual servers
Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
Click the plus icon (+) to the left of the local computer icon on the tree in the left pane.
Click Web Sites on the tree in the left pane.
Right-click the icon representing your SharePoint Portal Server server, then click Properties on the menu.
Click the Home Directory tab.
Click the Configuration button.
In the list box for Wildcard application maps, click the entry for IISImpersonationExtension.dll to highlight it, then click Edit.
Ensure that the box is unchecked.
Verify that the file exists, then click OK three times to close the Add/Edit panel, the Application Configuration panel and the property sheet for your portal server.
Add the following line to the web.config file.
<add key = "SPS-EnforceIISAnonymousSetting" value="false" />
To edit web.config for the SharePoint Portal Server integration
Open Windows Explorer and navigate to the document root of your IIS Web site.
Use any text editor to open the XML file web.config.
Locate the appSettings markers at the end of the file, or create them if they do not exist:
<Configuration> // [Various configuration settings] <appSettings> // [Insert "<add key . . .>" here.] </appSettings > </Configuration>
Important:
The appSettings markers are case sensitive and must appear as appSettings.Add the following line where indicated in the previous listing:
<add key = "SPS-EnforceIISAnonymousSetting" value="false" />
Save web.config.
Restart IIS so that the new setting will take effect by completing the following steps:
Select Start Menu, Internet Information Services (IIS) Manager.
In the tree in the left pane, locate the name of the local computer hosting your SharePoint Portal Server installation and write it down; you will need the name of this computer to restart IIS.
Right-click the local computer icon and select Disconnect from the menu.
After the warning asks if you really want to disconnect, click Yes to confirm the action.
The local computer icon disappears from the tree in the left pane, indicating that IIS has been shut down on that machine.
In the tree in the left pane, right-click the Internet Information Services icon and click Connect on the menu.
In the Connect to computer panel, type the name of the computer hosting your SharePoint Portal Server installation, then click OK to restart IIS.
You need to synchronize user profiles between the SharePoint Portal Server directory and the Oracle Access Manager directory:
Uploading user data—If your Oracle 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.
Importing user profiles in SharePoint Portal Server—After uploading the user profiles, you need to import the profiles from Active Directory to SharePoint Portal Server.
To configure importing user profiles in SharePoint Portal Server
Go to Site Settings.
Under User Profile, Audiences, and Personal Sites, click Manage Profile Database.
To configure user profile imports from Active Directory, click Configure Profile Import.
After you complete the tasks to enable integration, you should test to verify that integration is working.
This section contains the following topics:
You want to verify that a user can access SharePoint Portal Server resources through Oracle Access Manager authentication and SharePoint Portal Server authorization.
To test your SharePoint Portal Server integration
Navigate to any SharePoint Portal Server Web page using your browser.
The Access System challenges you for credentials.
Log in by supplying the necessary credentials, then verify that the page you requested is visible.
Optional: Check the Event Viewer to confirm that the access request was successful.
You should also test single sign-on by demonstrating that a user who has just supplied credentials and accessed an SharePoint Portal Server resource can (before the ObSSOCookie expires) access a non-SharePoint Portal 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 Portal Server integration
Create and protect a new virtual site with a policy domain (or use one you have already created.
Place a Web page anywhere in the tree of this virtual site.
Using a browser, navigate to the page in the new virtual site.
If you have already passed authentication, you should be granted access to the page without having to supply credentials a second time.
