ssoCookie:max-age=1000000 (Table 19–30)
Where, time-in-seconds represents the time interval when the cookie expires. For example, ssoCookie:max-age=3600 sets the cookie to expire in 1 hour (3600 seconds).
4. Save the change.
5. Configure centralized logout for the 10g WebGate, as described in Chapter 25.
51.10 Configuring Single Sign-off for Microsoft SharePoint Server
Manual Logout occurs when the user clicks the Logout button from SharePoint Server.
See Also: "Synchronizing User Profiles Between Directories" on page 51-38
See Also: "Testing the SharePoint Server Integration" on page 51-38
Note: For integration based on Windows Native Authentication, you need not set the persistent cookie parameter.
Configuring Single Sign-off for Microsoft SharePoint Server
when a user clicks the Logout button from SharePoint Server site, Access Manager logout is also triggered.
Cookie time-out occurs when the overall user session is controlled by ObSSOCookie.
Consider the following use-case:
■ FedAuth cookie time-out and ObSSOCookie is still valid: The user won't be challenged again because the ObSSOCookie is present. A new FedAuth cookie is generated (using the same flow described earlier).
■ ObSSOCookie time-out and FedAuth Cookie is still valid: Since each request is intercepted by the WebGate, the user is challenged for credentials again.
Access Manager provides single logout (also known as global or centralized log out) for user sessions. With Access Manager, single logout refers to the process of
terminating an active user session.
This topic describes how to configure single sign-off for integration with SharePoint.
Single sign-off kills the user session.
■ Configuring a Custom Logout URL in SharePoint Server
■ Configuring Logout in SharePoint Server With Impersonation
51.10.1 Configuring a Custom Logout URL in SharePoint Server
To configure a Custom Logout URL in SharePoint Server
1. From the generated artifacts for WebGate, add logout.html to the SharePoint Server Site
2. Locate C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES.
3. In \CONTROLTEMPLATES, change the welcome.ascx by adding the following tag. For example:
<SharePoint:MenuItemTemplate runat="server" id="ID_OverrideLogout" Text="Custom Logout"
ClientOnClickNavigateUrl="/logout.html?end_url=_layouts/SignOut.aspx"
Description="My Custom Logout"
MenuGroupId="200"
Sequence="100"
UseShortId="true" />
4. Click Save.
5. Protect the two URLs /_layouts/SignOut.aspx and /_
layouts/closeConnection.aspx in an Application Domain using Anonymous authentication.
6. Proceed to Configuring Logout in SharePoint Server With Impersonation.
Note: Closing the browser window after sign-off is always recommended, for security.
See Also: Chapter 22 for details about configuring centralized logout for 10g WebGate with OAM 11g Servers
Setting Up Access Manager and Windows Native Authentication
51.10.2 Configuring Logout in SharePoint Server With Impersonation
You can skip this procedure if you do not have Impersonation configured.
To configure Logout in SharePoint Server 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 in the case of Impersonation.
5. Proceed with "Testing Your Integration".
51.11 Setting Up Access Manager and Windows Native Authentication
This section provides the following topics:
■ Setting Up Access Manager WNA
■ Setting Up WNA With SharePoint Server
■ Installing Access Manager for WNA and SharePoint Server
■ Testing Your WNA Implementation
51.11.1 Setting Up Access Manager WNA
Configure Access Manager to use Windows Native Authentication, as described in Chapter 49.
51.11.2 Setting Up WNA With SharePoint Server
The following overview outlines the tasks that must be performed to set up WNA with Access Manager and the SharePoint Server.
Task overview: Setting up WNA with SharePoint Server 1. Complete the following prerequisite tasks:
■ Perform tasks in "Required Microsoft Components" on page 51-7.
■ Create a SharePoint Web site, as described in "Creating a New Web Application in Microsoft SharePoint Server" on page 51-11.
■ Configure the SharePoint site collection, as described in "Creating a New Site
Setting Up Access Manager and Windows Native Authentication
■ Test the configuration to ensure that users who are present in the directory server can log in to the SharePoint Web site and get proper roles, as described in your SharePoint documentation.
2. Install Access Manager as described in "Installing Access Manager for WNA and SharePoint Server" on page 51-36.
This step includes installing the WebGate for IIS and configuring Webgate.dll for the individual SharePoint Web site.
3. Configure the Active Directory authentication provider, as follows:
a. Login to the WebLogic Console.
b. Go to Security Realm and click the realm being used.
c. Go to the Provider tab provider, click New.
d. Enter the provider name, select the Type ActiveDirectoryAuthenticator, click OK.
e. Select the newly created Provider, change Control Flag to Sufficient, and Save.
f. Go to Provider Specific tab, enter details for your Active Directory, and save these.
4. Perform "Testing Your WNA Implementation" on page 51-37.
51.11.3 Installing Access Manager for WNA and SharePoint Server
You perform this task after you perform all prerequisites described in step 1 of the
"Task overview: Setting up WNA with SharePoint Server". Installing most Access Manager components for this integration scenario is the same as for any other situation.
Installing the IIS WebGate is similar to installing any other WebGate. The WebGate should be installed with the IIS v7 Web server; later it can be configured at the specific SharePoint Web site level to be protected. For IIS, the WebGate must be configured at the "web sites" level. For Microsoft SharePoint Server, you must configure the WebGate for the specific SharePoint Web site level to be protected.
To install Access Manager for WNA and SharePoint Server
1. Install Oracle Access Management Access Manager as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access
Management.
2. Install the ISAPI WebGate using steps in Chapter 25 for:
■ Installing WebGates
■ Installing Web components for the IIS Web server
Next, you configure Webgate.dll at the SharePoint Web site that yo want to protect. Configuring Webgate.dll at the "Website level" protects all Web sites on the IIS Web server. However, configuring Webgate.dll at the "SharePoint Website" protects only the expected Web site.
3. Configure Webgate.dll at the SharePoint Web site that you want to protect. For example:
a. Start the Internet Information Services (IIS) Manager: Click Start, Programs, Administrative Tools, Internet Information Services (IIS) Manager.
b. Select the hostname from the Connections pane.
Setting Up Access Manager and Windows Native Authentication
c. From the host name Home pane, double-click ISAPI Filters, look for any Webgate.dll; if it is present, select it and click Remove from the Action pane.
d. In the Connection pane, under Sites, click the name of the Web Site for which you want to configure a WebGate filter.
e. In the Home pane, double-click ISAPI Filters.
f. In the Actions pane, click Add…
g. In the Filter name text box of the Add ISAPI Filter dialog box, type WebGate as the name of the ISAPI filter.
h. In the Executable box, type the file system path of the WebGate ISAPI filter file or click the ellipsis button (...) to go to the folder that contains the Webgate.dll ISAPI filter file, and then click OK.
WebGate_install_dir\access\oblix\apps\Webgate\bin\Webgate.dll
4. Creating a Virtual Directory
a. Expand the Sites pane and select the Web Site for which you just configured the ISAPI filter (Webgate.dll).
b. On the Action pane, click View Virtual Directories and then select Add Virtual Directory.
c. In the Alias field, specify access and the physical path to the WebGate \access folder (or click the ellipsis button (...), go to the \access folder, then click OK).
WebGate_install_dir\access\
5. Set permissions on the Virtual Directory:
a. Select the "access" virtual directory created in Step 3.
b. From the access Home pane, double click Handler Mappings; from the Action pane, select Edit Feature Permissions….
c. Select Read, Script, and Execute, then click OK
6. Configure Access Manager to use Windows Native Authentication, as described in Chapter 49.
7. Configure Microsoft SharePoint Server Authentication to Classic Mode
Authentication while creating a new Web Application in Microsoft SharePoint. In the Authentication Provider section, select Negotiate(Kerberos).
8. Go to IIS newly created SharePoint site and:
a. Open Authentication, Windows Authentication, Advance Settings.
b. Select Enable Kernel mode authentication.
c. Select providers, delete NTLM provider.
d. Add Negotiate:Kerberos and move it to the top level.
e. Restart IIS.
9. Proceed to "Testing Your WNA Implementation".
51.11.4 Testing Your WNA Implementation
Use the following steps to confirm your WNA implementation is working properly.
Synchronizing User Profiles Between Directories
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.
51.12 Synchronizing User Profiles Between Directories
Unless explicitly stated, this task should be performed for all integration scenarios in this chapter.
You need to synchronize user profiles between the SharePoint Server directory and the Access Manager directory:
■ Uploading user data—If your Access Manager installation is configured for any directory server other than SharePoint Active Directory, you must load the user profiles that reside on the other directory server to SharePoint Active Directory.
Proceed to "Testing Your Integration"
51.13 Testing Your Integration
After you complete the tasks to enable integration, you should test to verify that integration is working.
This section contains the following topics:
■ Testing the SharePoint Server Integration
■ Testing Single Sign-On for the SharePoint Server Integration
51.13.1 Testing the SharePoint Server Integration
You can verify that a user can access SharePoint Server resources through Access Manager authentication and SharePoint Server authorization.