A Vordel White Paper

SharePoint Access Management

Integrating Microsoft SharePoint To Enterprise Access Management

Applications Anywhere

Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

SHAREPOINT ACCESS MANAGEMENT

Table of Content
Table of Content Introduction SharePoint Access Management And Challenges
Front-End vs. Back-End Single Sign-on (SSO) Integrated Windows Authentication Limitations Other Challenges Claim Based Authentication ADFS As A Trusted Identity Provider Federated Claims Active vs. Passive Clients Limitations And Challenges

2 3 4 4 4 4 5 6 6 7 8 8 8 9 9 9 10 10 11 11 12 12 13 14 14

Vordel SharePoint Gateway Solution Examples

SSO To SharePoint With Oracle Access Manager The Scenario The Solution The Flow Claim Based Access Control With CA SiteMinder The Scenario The Solution The Flow

Summary Contact Vordel About Vordel

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 2

SHAREPOINT ACCESS MANAGEMENT

Introduction
Microsoft SharePoint has gained wide spread popularity as a collaboration platform, a portal, and a document management system. SharePoint is easy to deploy, easy to use, and integrates seamlessly with other Microsoft products, especially Microsoft Office applications. In fact, SharePoint is so easy to deploy, each business department is quick to stand up its own SharePoint site and develop SharePoint applications to meet individual business needs. This has led to a sprawling problem where SharePoint sites and applications are often managed locally and with no integration to an enterprise security platform and standard. This means SharePoint users often cannot single sign-on (SSO) between SharePoint deployments and other non-Microsoft applications. Also, once they are connected, performance can be slow, leading to an overall poor user experience. SharePoint relies on Microsoft security technologies such as Kerberos, NTLM, and Active Directory Federation Server (ADFS) for access control. Whilst this tight integration works very well in an all-Microsoft environment, it makes integration to non-Microsoft enterprise access control and SSO platforms difficult. Most medium to large organizations have implemented some level of SSO and access control with products from CA, Entrust, IBM, Oracle, and RSA. These leading access management products offer poor out-of-the-box integration to the Microsoft technology stack. Enabling SSO across SharePoint applications from tools like CA SiteMinder or Oracle Access Manager usually involves a delicate concoction of agents, caches, and custom code. Remote and mobile access to SharePoint is even more complex than SSO from behind the firewall. Enterprises often resort to point solutions that are designed specifically for SharePoint mobile and remote access. This white paper is written for the enterprise architects and security professionals who need to understand the challenges of integrating Microsoft SharePoint to enterprise access management technologies. This white paper will: Outline the basic access management options available to SharePoint customers Highlight technical challenges involved with third party-integrations, mobile and remote access to SharePoint How to use the Vordel SharePoint Gateway technology to solve these problems

Enable single sign-on across SharePoint sites & applications in non-exclusive Microsoft environments

For additional information on Vordel SharePoint Gateway and other Vordel solutions, please visit www.vordel.com for a wealth of product, case study, and best practice information.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 3

SHAREPOINT ACCESS MANAGEMENT

SharePoint Access Management And Challenges

Front-End vs. Back-End Single Sign-on (SSO)

There are two aspects to SharePoint SSO. There is the SSO into SharePoint from enterprise SSO solutions such as CA SiteMinder and Oracle Access Manager. This is the subject we will cover in this white paper. The ability for SharePoint to single sign-on to backend business systems such as SAP, Siebel, and BizTalk Server to retrieve data is a separate topic that will not be covered in this white paper. There are abundant resources you can find on the back-end SSO topic by searching on keywords such as SharePoint SSO Service or SSOSrv. Vordel SharePoint Gateway can also simplify your backend SSO integrations. Please contact Vordel for more details.

Integrate SharePoint with enterprise-wide access management platforms from CA, Entrust, IBM, Oracle, RSA

Integrated Windows Authentication

Both SharePoint 2007 and 2010 rely on Integrated Windows Authentication service, which consists of Kerberos v5 and NTLM authentication. Kerberos v5 authentication is the default when Active Directory is installed on a domain controller running Windows 2000 Server or Windows Server 2003, and the client browser supports the Kerberos v5 protocol. NTLM authentication is used otherwise. Integrated Windows Authentication also supports the Negotiate authentication method, also known as SPNEGO, a wrapper for Kerberos v5 and NTLM. Negotiate allows a way for the client application to select the best security provider for the situation. You can learn more about Integrated Windows Authentication at http://technet.microsoft.com/en- us/library/cc758557(v=WS.10).aspx This tight integration works well in a homogenous Microsoft environment because Microsoft has done a great job of hiding all the complexity underneath. In the simplest scenario, if a user is logged on to a Windows computer that is part of a Windows domain that the SharePoint is also a member of, Integrated Windows Authentication will automatically log the user into SharePoint without prompting for a user name and password. Limitations However, Kerberos v5 and NTLM have the following known limitations: NTLM is connection-based, thus it cannot reliably work through a firewall. Proxies do not reliably maintain connections. Kerberos v5 requires the client to have a direct connection to Active Directory. This is not the case for most external / Internet / Cloud / Mobile integration scenarios.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 4

SHAREPOINT ACCESS MANAGEMENT

Kerberos v5 requires that both the client and the server have a trusted connection to a Key Distribution Center (KDC) and be compatible with Active Directory. In a heterogeneous environment involving non-Microsoft technologies, an intermediary is often required to broker the connections. Before a service can use Kerberos, it must be registered with a service principal name (SPN) in Active Directory. This registration process is manual unless the service name happens to be the same as NetBIOS or computer name. Kerberos authentication requires a service to be registered with only one account object. Thus, only one application pool that has the service registered can authenticate using Kerberos. So if a website has more than one application pool, Kerberos will require all application pool processes to have the same identifier. A Kerberos ticket only includes a users account and a list of AD Groups the user belongs to. It does not include other useful attributes such as email address and client type that maybe required for further contextual authentication and fine-grained authorization. Extending a Kerberos tickets attributes requires custom programming of Active Directory.

Enable remote & mobile access to SharePoint from any device, anywhere

Other Challenges Without careful setup of Kerberos authentication, these common deployment scenarios will cause Kerberos authentication to fail: If the Fully Qualified Domain Name (FQDN) is not the same as the NetBIOS name, Kerberos authentication will fail. For example, the IIS server hosting the www.vordel.com website is hosted on a server named www01. The authentication process runs under a non-System identity and no SPN is registered for that identity Applications are hosted across multiple servers that use the same computer name All servers in a web farm use one computer name and one SPN. Load balancers distribute requests to multiple servers.

Because of these limitations, Integrated Windows Authentication is really only suitable for intranet deployment scenarios and most suitable for homogeneous Microsoft environments. It is not suitable if any of the following applies to your situation: Connection goes through a HTTP proxy, but NTLM is being used Application users do not have accounts in your Windows domain Multiple Windows forests that do not have mutual trust relationships Integration with Java or other non-.NET Framework applications Support for non-Windows platform such as Mac OS and Linux

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 5

SHAREPOINT ACCESS MANAGEMENT

Claim Based Authentication

SharePoint 2010 introduces an additional claim-based authentication model to address some of the deficiencies associated with Integrated Windows Authentication. You can find the background on this new feature and the general topic of claim-based authentication at the following Microsoft site: http://msdn.microsoft.com/en- us/library/ff423674.aspx. As with most Microsoft solutions, this Microsoft article is written for a Microsoft only environment, utilizing .NET Framework, ASP.NET, Windows Communication Foundation (WCF), Microsoft Active Directory, and Microsoft Visual C#. In a nutshell, claim-based authentication requires the SharePoint Server to grant access based on the claims issued by a trusted identity provider (TIP). The claim can include user identifier such as Windows username, email address, or third-party SSO ID. The claim can also include roles and attribute claims that SharePoint can use to determine the appropriate access level. The authentication of the users identity is delegated to the TIP. SharePoint relies on the claims asserted by the TIP via an explicit trust relationship preconfigured using the WS-Trust or WS-Federation protocols. With a claim-based model, a SharePoint server no longer needs to have knowledge of user accounts. Users can be anonymous to SharePoint. User Policies in SharePoint can simply be role or attribute based, greatly simplifying the administration overhead when compared to managing individual user accounts. ADFS As A Trusted Identity Provider

Enable claim-based User Policies in SharePoint to reduce user account administration overhead

In a Microsoft environment, with Windows Server 2008 R2 Enterprise Edition, Active Directory Federation Services (ADFS) 2.0 can be configured as a TIP to issue claims. ADFS provides a number of options to authenticate users, including Kerberos, forms authentication, or certificates. SharePoint can support multiple authentication schemes, so one can potentially set up both Integrated Windows Authentication and a claimed-based scheme for different user populations or different access channels. Custom coding is required to ensure consistency of the claims generated by the different TIPs and provide the proper user interface to let users select an identity provider at login. Follow this link to learn more about setting up ADFS as a TIP for SharePoint: http://msdn.microsoft.com/en-us/library/hh446525.aspx. For detailed step-by-step instructions on how to setup a TIP for SharePoint and other interesting SharePoint topics, check out this very informative blog at Share-n-dipity blog (http://blogs.technet.com/b/speschka/.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 6

SHAREPOINT ACCESS MANAGEMENT

Avoid fragile custom solutions & invasive agent-based solutions that are costly to deploy & manage

Figure 1: Claim-Based Authentication Using ADFS (Diagram Source: http://msdn.microsoft.com/en-us/library/ff359108.aspx)

Federated Claims In a federated setup, ADFS can also accept a security token such as a Security Assertion Markup Language (SAML) 2.0 token from another identity provider as proof of authentication. The identity provider / claim issuer can be another ADFS instance; a non-Microsoft federation server; a security token service, or a Cloud based federation broker.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 7

SHAREPOINT ACCESS MANAGEMENT

Active vs. Passive Clients The claim-based model can involve active or passive clients. An active client can handle more sophisticated authentication and token management scenarios. Active client in the Microsoft world can leverage the Windows Communication Foundation (WCF) library to handle these tasks using the WS-Trust protocol. In contrast, a passive client uses a much simpler protocol to request and pass around tokens that rely on HTTP primitives such as HTTP GET and POST. The passive-client model is supported by a much broader range of clients, including most web browsers. In the Microsoft world, the simpler WS-Federation protocol is used for this model instead of WS-Trust. Limitations And Challenges

Integrate SharePoint to enterprise security framework & improve governance for SharePoint deployments

The challenges associated with using a claim-based model with SharePoint once again centers around integration with third-party technologies in a heterogeneous environment, especially when other proprietary and legacy technologies are involved. Some of the challenges include: Configuring non-Microsoft access management products as TIPs Interoperate with common proprietary tokens such as ObSSO cookie from Oracle Access Manager or CA SiteMinder session token Deploy and manage additional agents from access management products Mediate claim format from multiple TIPs Deploy mixed claim-based and non-claim-based authentication schemes Deploy advanced access control polices based on network, client, time-of-day and other contexts Token caching to minimize token generation and re-authentication requests. Manage WS-Trust and WS-Federation relationships Manage certificates and integrate with Certificate Authorities Reconcile the Microsoft claimed-based model with other fine-grained authorization technologies for Axiomatics, Oracle and Quest

Vordel SharePoint Gateway

Vordel SharePoint Gateway provides out-of-the-box integrations between SharePoint and all leading identity and access management products, including CA, Entrust, IBM, Oracle, Quest, and RSA. Vordel offers an agent-less, non-invasive solution that is simpler and more reliable than the agent-based solutions offered by access management vendors. Vordel SharePoint Gateway may be the right solution for you if any of the following scenarios apply to your SharePoint deployment: Have deployed SSO solution from a non-Microsoft vendor Have multiple SSO solutions across different domains and business units Have embedded SSO solutions in ERP (e.g. Oracle and SAP) and other business applications

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 8

SHAREPOINT ACCESS MANAGEMENT

Using both on-premise and Cloud-based SSO solutions Need to deployed mixed mode authentication schemes Need to integrate strong authentication solutions Prefer not to use an agent-based solution Prefer not to build and maintain custom integration code Are migrating or plan to change SSO product

Maintain SharePoint integration & update policies with easy-to- use drag-and-drop configuration user interface

Figure 2: Drag-and-Drop Configuration

Please see Vordel.com for more information on the Vordel SharePoint Gateway and other solutions.

Solution Examples
Every SharePoint deployment is unique so every SharePoint SSO problem is a little bit different. Vordel SharePoint Gateway offers drag-and-drop configuration to accommodate the most demanding SharePoint integration requirements. We will examine how the Vordel solution works using representative deployment scenarios from actual Vordel customers.

SSO To SharePoint With Oracle Access Manager

The Scenario The company BigPharma has standardized on Oracle Access Management Suite as the enterprise wide access control and SSO solution. Oracle Access Manager (OAM) is used to protect nearly all web applications within the organization across the globe.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 9

SHAREPOINT ACCESS MANAGEMENT

BigPharmas identity management roadmap calls for future rollout of Oracle Entitlements Server and Oracle Adaptive Access Manager for fine-grained authorization and contextual authentication. There are over 30 SharePoint sites and applications that BigPharma wishes to enable SSO through OAM. BigPharma has decided deploying Oracles IIS based integration on each SharePoint server is not a desirable option and wishes to deploy a more scalable and manageable solution using the Vordel SharePoint Gateway. The Solution In this implementation the Vordel SharePoint Gateway is deployed as a proxy for all SharePoint traffic. All SharePoint requests from the browsers are routed to the Gateway for the purpose of security integration as well as performance acceleration. Vordels OAM Connector is used to authenticate the user against OAM. Vordels Kerberos Connector is used to acquire Kerberos service tickets on behalf of the end user to access SharePoint. Throughout this entire integration, the Gateway has no knowledge of the end users Kerberos password.

Accelerate SharePoint performance by at least 30% & improve user experience

Figure 3: Single Sign-on Using Third-Party Access Management Product

By routing all SharePoint requests through the Gateway, BigPharma has improved SharePoint performance by a minimum of 30%. Performance acceleration is not in the scope of this security white paper. To learn how the Gateway can accelerate SharePoint performance using intelligent cache management, contact a Vordel product expert.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 10

SHAREPOINT ACCESS MANAGEMENT

The Flow 1. 2. 3. 4. The user John enters a SharePoint URL in his browser and the request hits the Gateway. The Gateway instructs the browser to send OAMs ObSSO cookie. The Gateway receives the ObSSO cookie and validates the token with OAM. The Gateway maps Johns OAM username to a Kerberos User Principal Name (UPN). The Gateway queries its Kerberos token cache to determine if a service ticket already exists for Johns UPN and the SharePoint Service Principal Name (SPN). If a ticket is found in the cache, the Gateway further checks the ticket for expiration. If there is no cached service ticket or if the cached ticket has expired, the Gateway invokes the Impersonation Token Service passing the UPN and SPN. The Impersonation Token Service first acquires a Kerberos service ticket for the UPN to access itself via the Kerberos S4U2Self extension. It then uses the Kerberos S4U2Proxy extension to acquire a Kerberos service ticket for the UPN to access the SPN. The Impersonation Token Service acquires these tickets by invoking the Kerberos KDC / Windows Domain Controller The Impersonation Token Service returns the token to the Gateway. The Gateway extracts the service ticket and client-service session key for John to access SharePoint. The service ticket and session key are cached in the Gateway. The Gateway generates the Kerberos SPNEGO token which contains the unique authenticator data and the service ticket for SharePoint. The Gateway inserts the SPNEGO token into the authorization header of the request to SharePoint. SharePoint authenticates John using the SPNEGO token, performs the requested operation, and returns the response to the Gateway. The Gateway then passes the response back to the browser.

Expose SharePoint data & features externally with strong access control & threat protection

5.

6.

7.

8.

Claim Based Access Control With CA SiteMinder

The Scenario The company InsuranceCo plans to upgrade all its SharePoint sites to SharePoint 2010. As part of this upgrade project, InsuranceCo would like to enable SSO to SharePoint via CA SiteMinder and switch to the more scalable claim-based authentication and authorization scheme. CA SiteMinder is the enterprise wide access control and SSO platform. InsuranceCo asked its existing XML gateway appliance vendor to help with this SharePoint integration. After one year of trying, InsuranceCo concluded that its current XML gateway is not capable of handling SharePoint integration without an extensive amount of custom code. Another gateway vendor declined to compete after reviewing the use cases. InsuranceCo selected Vordel SharePoint Gateway for an out-

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 11

SHAREPOINT ACCESS MANAGEMENT

of-the-box solution that demonstrated all of the companys use cases within one week. The Solution In one aspect of this implementation the Vordel SharePoint Gateway is deployed as a trusted identity provider (TIP) to SharePoint. SharePoint authentication requests are delegated to the Gateway. Vordels CA SiteMinder Connector is used to authenticate the user against SiteMinder and retrieve additional user attributes. The Gateway generates a WS-Trust RSTR (Request Security Token Response) with a SAML token. User attributes are inserted as SAML attributes. SharePoint uses these user attributes to make access control decisions, without any explicit knowledge about the user identity. All the SharePoint administrators need to manage are role based User Policies within SharePoint. The Gateway also uses the Kerberos credential to obtain a SiteMinder token for further SSO to other applications.

Monitor, track, audit, & report SharePoint access & transactions

Figure 4: Claim-Based Access Control Leveraging Third-Party Access Management Products

The Flow The user Alex is logged into his Windows PC and domain via username and password. Alex enters a SharePoint site URL in his browser and the request hits the Gateway. The Gateway instructs the browser to send a Kerberos SPNEGO token. The browser obtains a Kerberos ticket for the Gateway from the domain controller. This token is sent to the Gateway in the HTTP headers as a SPNEGO token. Alex is not prompted to enter his credential into the browser. The Gateway maps Alexs Kerberos UPN to a SiteMinder username, authenticates Alex with SiteMinder, obtains additional user attributes, and requests a SiteMinder session token. The Gateway can obtain a SiteMinder session token without knowledge of Alexs SiteMinder password.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 12

SHAREPOINT ACCESS MANAGEMENT

The Gateway packages Alexs email address and a number of attributes into a SAML token, then sends the SAML token to SharePoint using WS-Trust RSTR protocol. SharePoint uses the user attributes in the SAML token to determine access rights using claim-based User Policies defined in SharePoint. Alexs attributes give him limited read-only access for this SharePoint application. Alternatively another user Marys attributes can give her editing rights. When Alex attempts to access other SiteMinder protected applications, the Gateway can use the SiteMinder session token to SSO Alex into those applications.

Deploy a SharePoint access management solution that has great flexibility, scalability, &performance

Summary
Microsoft SharePoint is easy to deploy and easy to use, until you have to integrate it with enterprise access management and SSO platforms. SharePoints reliance on Microsoft security foundation technologies makes integration to third-party security platforms extremely complex and challenging. Instead of cooking up a concoction of custom integration code and deploying intrusive agents into every SharePoint instance, Vordel SharePoint Gateway offers an alternative that is agent-less, non- invasive, easy to deploy, easy to manage, and ready to scale. The Gateway takes care of all the complicated orchestrations between Microsoft and other vendors security products to deliver a seamless experience for the end users and a painless experience for SharePoint administrators.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 13

SHAREPOINT ACCESS MANAGEMENT

Contact Vordel
For more information or sales enquiries, contact sales@vordel.com USA +1 866-460-0987 | EMEA +44 203-427-5082 | APAC +61 28 014 4591 Follow us on: www.twitter.com/vordel http://www.linkedin.com/groups/Vordel-Community-3745749?

About Vordel
Vordel delivers fast, safe, connectivity for SOA and Cloud Services. Vordel Application Gateway provides integration, security, governance, and acceleration for enterprise applications and Cloud based services. Vordel Application Gateway enables Fortune 5000 enterprises and government agencies to extend their enterprise applications and SOA infrastructure beyond the perimeter to enable Cloud based services and mobile computing. Vordel makes it possible to deliver and consume Applications Anywhere with ITs existing applications and infrastructure, without costly upgrades and rewrites.

Applications Anywhere
Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.

Page 14