| Oracle® Access Manager Integration Guide 10g (10.1.4.0.1) Part Number B25347-01 |
|
|
View PDF |
| Oracle® Access Manager Integration Guide 10g (10.1.4.0.1) Part Number B25347-01 |
|
|
View PDF |
This chapter explains how to integrate with the Microsoft SharePoint Portal Server (SPPS) 2003. It covers the following topics:
Oracle Access Manager provides a full range of identity management and security functions, including: Web-based single sign-on (SSO), 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 (SPPS) is a secure, scalable, enterprise portal server that builds on Windows Server 2003 Microsoft Internet Information Services (IIS) and Windows SharePoint Services (WSS). SPPS can aggregate SharePoint sites, information, and applications into a single, easy-to-use portal. In addition to WSS functionality, SPPS incorporates additional features such as News and Topics as well as personal and public views for My Site, and so on.
Once Oracle Access Manager has been integrated with SPPS, the Access System handles user authentication through an ISAPI filter for IIS and an ISAPI wild card extension, which enables single sign-on between Oracle Access Manager and SPPS. WSS handles resource request authorization for all SPPS resources.
Such integration enables authenticated users to enjoy SSO access not just to SPPS resources, but also Oracle Access Manager-protected resources, which can reside on the full range of Oracle Access Manager-supported platforms (such as Windows, Solaris, or Linux,) or application servers (such as WebLogic or WebSphere).
Oracle Access Manager/SPPS integration utilizes the Windows impersonation feature, which enables a trusted user in the Windows server domain to assume the identity of any user requesting an SPPS target resource. 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 directly, as if the SPPS resource were a resource within the Access System domain.
Successful integration with SPPS 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.
To see the supported versions and platforms for this integration, refer to Metalink, as follows.
To view information on Metalink
Go to the following URL:
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Application Server and click Submit.
Any references to specific versions and platforms in this chapter are made for demonstration purposes. For the latest support information, see the Certify tab at https://metalink.oracle.com.
Table 15-1 lists the Microsoft components required to integrate with SPPS.
Table 15-1 Microsoft Requirements
| Component/Feature | Requirement/Comment |
|---|---|
|
Operating System |
Windows Server for the SPPS host. Note: Any of the five editions is acceptable. Also: The Active Directory Domain Controller must reside on a Windows Server 2003 machine, although that machine doesn't have to be the one hosting SPPS. |
|
Extended Services |
|
|
Directory Service |
Active Directory. You install this after installing Windows Server 2003. You can connect SPPS directly to the Active Directory Domain Controller or to a different instance of Active Directory.
Note: For all scenarios mentioned here, SPPS can use either Desktop SQL or an instance of SQL Server installed on a machine within the Active Directory domain. |
|
Portal Server |
SharePoint Portal Server (SPPS). After installing Active Directory, you install SPPS on a machine 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 15-2 are required to integrate with SPPS.
Table 15-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 SPPS resources.
Process overview: Request processing with the SPPS integration
The user requests access to an SPPS resource.
The WebGate ISAPI filter protecting SPPS 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 SPPS.
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 SPPS
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 SPPS Integration".
Except where noted, all Microsoft SPPS-related components must be installed on the same host machine, including the following software:
Windows Server 2003
Microsoft IIS v6 Web Server
SPPS (and underlying WSS)
The following Microsoft components can be installed on machines other than the one hosting the main SPPS installation:
Active Directory (see Table 15-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 SPPS. See Table 15-1 for installation location details.
Additional SPPS front end servers.
One or more back end servers containing SPPS resources such as Web pages, documents, or applications.
|
Note: All of the machines hosting the preceding SPPS-related components must be in the same Active Server domain as the SPPS 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 SPPS installation, as described in the appropriate Microsoft documentation.
Install IIS on the machine that will host your SPPS 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 15-1 for installation location considerations.
If SPPS 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 15-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 SPPS, stop and test the installation to ensure it operates correctly before you integrate with Oracle Access Manager.
Task Overview: Creating and setting up a portal
Create a portal.
Upload a test document.
Create audiences.
Edit audiences (if necessary).
Compile audiences.
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 SPPS 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 SPPS must be installed on the same machine as SPPS. 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 SPPS 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 SPPS integration
On either the same machine that hosts SPPS (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 15-2 for WebPass installation considerations.
On either the same machine that hosts SPPS (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 15-2.
On the machine hosting the SPPS 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 SPPS, 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 SPPS 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 SPPS 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.
Setting up impersonation, whether for SPPS 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 SPPS, 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 SPPS 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 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 SPPS 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, as indicated in the following screen shot, 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 Portal 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 SPPS context or test SSO, as described in "Creating an IIS Virtual Site Not Protected by SPPS"
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 SPPS context or to test SSO, you will need a target Web page on an IIS virtual Web site that is not protected by SPPS. You create such a virtual Web site by completing the following task.
To create an IIS virtual site not protected by SPPS
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 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/SPPS integration.
Task overview: Setting up the SPPS integration
Set up IIS security, as described in "Configuring IIS Security".
Configure the wildcard extension for each SPPS 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 SPPS 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 SPPS server you are protecting with your WebGate, then select Properties from the menu.
In the property sheet for the SPPS 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 Portal. Rather, this setting configures IIS to relinquish access control to the Access System. |
You are ready to configure the wildcard extension for each SPPS virtual server for which you wish to enable integration.
To configure the wildcard extension for SPPS 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 SPPS 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 SPPS 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 SPPS 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 SPPS 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 SPPS resources through Oracle Access Manager authentication and SPPS authorization.
Navigate to any SPPS 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 SPPS resource can (before the ObSSOCookie expires) access a non-SPPS 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 SPPS 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.
