SharePoint Server is a Microsoft-proprietary secure and scalable enterprise portal server that builds on Windows Server Microsoft Internet Information Services (IIS) and Windows SharePoint Services (WSS).
SharePoint Server is typically associated with Web content and document management systems. SharePoint Server works with Microsoft IIS web server to produce sites intended for collaboration, file sharing, web databases, social networking and web publishing. In addition to WSS functionality, SharePoint Server incorporates additional features such as News and Topics as well as personal and public views for My Site, and so on.
Microsoft SharePoint Server enhances control over content, business processes, and information sharing. Microsoft SharePoint Server provides centralized access and control over documents, files, Web content, and e-mail, and enables users to submit files to portals for collaborative work.
SharePoint server farms can host web sites, portals, intranets, extranets, Internet sites, web content management systems, search engine, wikis, blogs, social networking, business intelligence, workflow as well as providing a framework for web application development.
When integrated with Microsoft SharePoint Server, Access Manager handles user authentication through an ISAPI filter and an ISAPI Module. This enables single sign-on between Access Manager and SharePoint Server.
SharePoint Server supports the following authentication methods:
Form Based Authentication
Impersonation Based Authentication
Windows Authentication: Used only for the configuration where the information about the users is stored in Active Directory server
The integrations in this chapter provide single sign-on to Microsoft SharePoint Server resources and all other Access Manager protected resources. For more information, see:
This trusted impersonator maintains the identity context of the user while accessing the resource on behalf of the user.
Impersonation is transparent to the user. Access appears to take place as if the SharePoint resource were a resource within the Access System domain.
Note:
Windows impersonation is not used when integrating Microsoft SharePoint Server configured with the LDAP Membership Provider.
With form-based authentication, the WebGate is configured as an ISAPI filter. The form login page of SharePoint RP is customized such that the user is not challenged to enter the credentials by the SharePoint RP. Also, the membership provider is customized such that it just validates the ObSSOCookie set by the WebGate to authenticate the user.
Note:
The WebGate only supports Form Based Authentication using the HTTP validation method (OAMHttp validation mode). The ASDK validation method (OAMsdk validation mode) is not supported for Form Based Authentication.
The following overview outlines the authentication flow for this integration using form-based authentication.
Process overview: Request processing with form-based authentication
The user requests access to an SharePoint Server RP site.
The WebGate protecting the site intercepts the request, determines if the resource is protected, and challenges the user.
The user enters their OAM credentials. Next the OAM WebGate server verifies the credentials from LDAP and authenticates the user.
The WebGate generates the OAM native SSO cookie (ObSSOCookie), which enables single sign-on and sets the User ID header variable (to the user name) in the HTTP request and redirects the user to the SharePoint RP site.
The SharePoint RP custom login page is invoked, which sets the user name to the user ID passed in the header variable, and sets the password to the ObSSOCookie value. The login page also automatically submits these credentials to the SharePoint RP site.
The SharePoint RP site passes the credentials to SharePoint STS, which invokes the custom membership provider to validate the user credentials.
The custom membership provider gets the ObSSOCookie value (passed as a password) and sends it as part of the HTTP request to a resource protected by the WebGate to validate the ObSSOCookie.
If the ObSSOCookie is valid, SharePoint STS generates the SAML token and passes it to SharePoint RP.
SharePoint RP validates the SAML token and generates the FedAuth cookie. The user is then allowed to access the SharePoint RP site.
With the SharePoint 2007 integration, the Access Manager ISAPI extension (IISImpersonationExtension.dll) was used. Because the internal architecture of event handing changed with SharePoint 2010, Access Manager has changed the ISAPI extension to an HTTP module.
The next overview identifies the authentication processing flow with SharePoint Server and Windows impersonation enabled.
Process overview: Integration Authentication with Windows Impersonation
The user requests access to a 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 OAM Server validates them, the WebGate sets an ObSSOCookie in the user's browser, which enables single sign-on. The WebGate also sets an HTTP header variable named "impersonate," whose value is set to one of the following:
the authenticated user's LDAP uid
samaccountname, if the user account exists in Active Directory
The Access Manager HTTP module IISImpersonationModule.dll checks for the Authorization Success Action header variable named impersonate.
When the header variable exists, the Oracle ISAPI module obtains a Kerberos ticket for the user.
This Service for User to Self (S4U2Self) impersonation token enables the designated trusted user to assume the identity of the requesting user and obtain access to the target resource through IIS and the SharePoint Portal Server.
Access Manager provides support for Windows Native Authentication (WNA).
Your environment may include:
Windows 2008/R2 or 2012/R2 server
Internet Information services (IIS) 7.x or 8.x
Active Directory
If the user's directory server has, for example, an NT Logon ID, or if the user name is the same everywhere, then a user is able to authenticate into any directory server. The most common authentication mechanism on Windows Server 2008 is Kerberos.
The use of WNA by Access Manager is seamless. The user does not notice any difference between a typical authentication and WNA when they log on to their desktop, open an Internet Explorer (IE) browser, request a protected web resource, and complete single sign-on.
Process overview: Using WNA for authentication
The user logs in to the desktop computer, and local authentication is completed using the Windows Domain Administrator authentication scheme.
The user opens an Internet Explorer (IE) browser and requests an Access System-protected Web resource.
The browser notes the local authentication and sends a Kerberos token to the IIS Web server.
Note:
Ensure that Internet Explorer's security settings for the Internet and (or) intranet security zones are adjusted properly to allow automatic logon.
The WebGate installed on the IIS Web server sends the Kerberos token to the OAM 11g sever. The OAM 11g Server negotiates the Kerberos token with the KDC (Key distribution center).
Access Manager sends authentication success information to the WebGate.
The WebGate creates an ObSSOCookie and sends it back to the browser.
Access Manager authorization and other processes proceed as usual.
The maximum session time-out period configured for the WebGate is applicable to the generated ObSSOCookie.