Share Point Access Management

  • Published on
    21-Apr-2015

  • View
    39

  • Download
    5

Embed Size (px)

Transcript

<p>A Vordel White Paper </p> <p>SharePoint Access ManagementIntegrating Microsoft SharePoint To Enterprise Access Management </p> <p>Applications Anywhere </p> <p>Copyright 2012, Vordel Inc. and/or its affiliates. All rights reserved.</p> <p>SHAREPOINT ACCESS MANAGEMENT Table of ContentTable 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 </p> <p>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 </p> <p>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 </p> <p>Summary Contact Vordel About Vordel </p> <p>Applications AnywhereCopyright 2012, Vordel Inc. and/or its affiliates. All rights reserved. </p> <p>Page 2</p> <p>SHAREPOINT ACCESS MANAGEMENT </p> <p>IntroductionMicrosoft 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 </p> <p> Enable single sign-on across SharePoint sites &amp; applications in non-exclusive Microsoft environments </p> <p>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. </p> <p>Applications AnywhereCopyright 2012, Vordel Inc. and/or its affiliates. All rights reserved. </p> <p>Page 3</p> <p>SHAREPOINT ACCESS MANAGEMENT </p> <p>SharePoint Access Management And Challenges </p> <p>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. </p> <p> Integrate SharePoint with enterprise-wide access management platforms from CA, Entrust, IBM, Oracle, RSA </p> <p>Integrated Windows AuthenticationBoth 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. </p> <p>Applications AnywhereCopyright 2012, Vordel Inc. and/or its affiliates. All rights reserved. </p> <p>Page 4</p> <p>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. </p> <p> Enable remote &amp; mobile access to SharePoint from any device, anywhere </p> <p>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. </p> <p>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 </p> <p>Applications AnywhereCopyright 2012, Vordel Inc. and/or its affiliates. All rights reserved. </p> <p>Page 5</p> <p>SHAREPOINT ACCESS MANAGEMENT </p> <p>Claim Based AuthenticationSharePoint 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 </p> <p> Enable claim-based User Policies in SharePoint to reduce user account administration overhead </p> <p>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/. </p> <p>Applications AnywhereCopyright 2012, Vordel Inc. and/or its affiliates. All rights reserved. </p> <p>Page 6</p> <p>SHAREPOINT ACCESS MANAGEMENT </p> <p> Avoid fragile custom solutions &amp; invasive agent-based solutions that are costly to deploy &amp; manage Figure 1: Claim-Based Authentication Using ADFS (Diagram Source: http://msdn.microsoft.com/en-us/library/ff359108.aspx) </p> <p>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. </p> <p>Applications AnywhereCopyright 2012, Vordel Inc. and/or its affiliates. All rights reserved. </p> <p>Page 7</p> <p>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 </p> <p> Integrate SharePoint to enterprise security framework &amp; improve governance for SharePoint deployments </p> <p>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 </p> <p>Vordel SharePoint GatewayVordel SharePoint Gateway provides out-of-the-box integrations...</p>