Beginning SharePoint 2010 Development: Chapter 12: Securing Your SharePoint 2010 Applications

Summary: This chapter discusses user authentication in SharePoint 2010, the difference between farm-level solutions and sandboxed solutions, and federated authentication using forms-based authentication and claims-based authentication.

Applies to: Business Connectivity Services | SharePoint Foundation 2010 | SharePoint Server 2010 | Visual Studio

This article is an excerpt from Beginning SharePoint 2010 Development by Steve Fox from Wrox Press (ISBN 978-0-470-58463-7, copyright © 2010 by Wrox, all rights reserved). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Contents

• Introduction

• Authorization

• Solution Trust

• Secure Store Service (SSS)

• Federated Authentication

• Summary

• Recommended Reading

• About the Author

  Download code

Introduction

SharePoint security is a vast topic that can't be covered fully in a single chapter. You could likely dedicate an entire book to SharePoint security. This is because when you talk about security and SharePoint, you're not just referring to SharePoint. SharePoint is built on ASP. NET, which has its own security architecture and framework. It is deployed to Internet Information Services (IIS), which also has its own framework and configuration. And SharePoint itself has its own security infrastructure that leverages Active Directory (AD), among other security technologies. The goal of this chapter, therefore, is to provide a high level introduction to a set of SharePoint security topics.

SharePoint 2010 has a flexible security infrastructure that supports a number of different technologies (such as AD, claims-based authentication, forms-based authentication, Kerberos, and many more). The different types of security in SharePoint support different scenarios. For example, if you're trying to grant access for an individual or group to content on a site within your organization, then you would leverage AD, and assign permissions to specific site content to individuals or groups. If you were trying to federate that access to an external system (for example, integrating SAP data within a SharePoint site), then you might use the Secure Store Service (SSS) or claims-based authentication to provision access.

When you're developing for SharePoint, you develop and deploy applications at different security levels. For example, you can build either a farm-level solution or a sandboxed solution for SharePoint 2010. You also need to think about those users who have access to specific service-based applications, such as applications based on Business Connectivity Services (BCS). Exposing augmented permissions to all users could result in unwanted deletions, corruptions, or, worse, data mismanagement or public exposure.

The key take-away here is that you have many different ways in SharePoint to negotiate and configure security.

In this chapter, you'll start by becoming familiar with the authorization fundamentals using AD. You'll then see how you can develop farm-level and sandboxed solutions to get a sense for how they're different. You'll also see how you can use SSS to provision access to external systems for BCS applications. And, finally, you'll learn about federated authentication for SharePoint through forms-based and claims-based authentication.

Authorization

In Chapter 1, you saw a high-level architecture of a SharePoint farm and walked through an example where you assigned permissions to a specific user in a SharePoint site. Within this architecture, you had one or more servers (constituting the "farm"). You had IIS running on the servers, and then you had Web applications within IIS that hosted the SharePoint site collection and the Central Administration site collection. Within this architecture, there are a couple of fundamental security items to call out.

The first is that, because SharePoint is built on ASP.NET, and IIS supports ASP.NET, IIS is agnostic to the Web application being a SharePoint site. It treats it just as it would any other Web application. Of particular significance is the fact that each Web application runs inside an application pool, which is an isolated environment where your Web application runs its worker processes. This is a protective measure to isolate site processes to not bring down all Web applications on IIS by all sites using the same application pool — although you could theoretically connect all of the Web applications to the same application pool, which would increase your failover risk significantly.

The second is that, by default, SharePoint leverages AD to help manage permissions. AD is a Windows-based technology that provides a number of key network and security services, such as directory services, Domain Name System (DNS–)-based naming and network information, network authority management, central identity storage, and so on. The goal with AD is to have one standard approach for the Windows environment that helps manage policies and authorization for a team or organization. Using AD, you can manage authentication that scales across tens of thousands of users, and manage different domains and servers that cut across a global server farm.

One of the fundamental aspects of SharePoint is the management of different permission levels using AD records. A record is an individual entry within AD. For example, Figure 1 shows a set of Users within Active Directory.

What this means is that site collection administrators can provision access to individuals who have a record in AD. You can also give a user different levels of permissions (such as view, contributor, or full control), or you can add the user to a higher-level security group that you can then use to manage security within your site. (For many administrators, the group is the preferred way to manage security because it provides a more controlled and manageable approach.) For example, in Figure 2, you can see that Arlene Huff (one of the records listed in AD from Figure 1) is now being added with full control to a SharePoint site.

Figure 1. Active Directory User group

 

Figure 2. Adding a user to a SharePoint site

Because many of you who will develop against a site collection may also be the administrator for that site, it's important to understand how you provision access to not only the content on the site, but also the applications you are developing for your site. (You will likely also want to understand — and test — what the user experience is against your solution at the various permissions levels.) Provisioning access within your organization using AD is the first step in this regard, and you can do this by clicking Site Actions, and then Site Permissions from your SharePoint site.

Within SharePoint's Central Administration site, you also have a granular set of security management features, as shown in Figure 3. To access these features, click Security in Central Administration. You'll then see security features for user management, general security, and policy management.

Figure 3. Security in Central Administration

If you are the person who administers security and permissions for your site, you'll want to manage them carefully. As you might imagine, you can assess permissions on a very discrete level in SharePoint (for example, at the site, lists, and document libraries levels). What this could result in is splintered or disjointed authentication, where security inheritance is broken (that is, a site does not inherit the permissions set by the parent site collection, and overall security is difficult to manage). The implications of mismanaging role-based security are quite far-reaching. For example, if you do "break the inheritance model," then you may run into issues with security governance in your organization, and management of security can become very difficult.

This is where the role of the site collection administrator is an important one. Not only does this person need to ensure a pragmatic and consistent approach to security in SharePoint, but this person also must ensure that it is implemented with governance and the appropriate restrictions in place.

This is where security groups (and defined security policies) can come into play to help you manage authentication for your SharePoint site. For example, leveraging groups in SharePoint can help avoid the management of discrete, individual-level permissions that may be assigned to sites. Users will, of course, want to restrict access to specific document libraries and lists when information should not be widely shared. However, at the site collection and site level, you can leverage security groups to your advantage.

To create a security group, click Site Actions, choose Site Settings, and then click Create Group from the ribbon. Before clicking Create to complete the creation process, you can complete fields such as name, description, group administrator, level of permissions for the group, and so on.

AD also provides a way to federate security through the use of claims providers. This functionality was introduced with Active Directory Federation Services (ADFS) 2.0. A claims provider issues claims, and then packages those claims into security tokens that are used to authenticate a user. Using a claims-based approach to security can augment credentials from outside systems, and make it possible for you to add these credentials to AD, thus providing access to SharePoint assets and lighting up these users in features such as the People Picker. For more information on claims providers, see Getting Started with Security and Claims-Based Identity Model.

Solution Trust

Another type of security issue that you should be aware of in SharePoint is the use of farm-level solutions versus sandboxed solutions — that is, setting the specific trust level for your SharePoint solution. This is less about the user accessing SharePoint as a collaborative resource (that is authorization) and more about you deploying the solution into SharePoint with specific levels of access to SharePoint resources.

Farm-level solutions are scoped at the SharePoint farm level, so they have full-trust access to all the resources and functionality in SharePoint. Sandboxed solutions are solutions that run in the context of a site collection. Sandboxed solutions are restricted — for example, they cannot connect to resources that are not on the local server, access a database, call unmanaged code, write to the system disk, or access resources in a different site collection. Sandboxed solutions, though, do have the capability to monitor and shut down applications, should they have any performance issues. The metrics by which you can control and monitor sandboxed solutions are also configurable. (Of note is the fact that sandboxed solutions are one of the key ways in which you build and deploy SharePoint 2010 solutions to SharePoint Online.)

For most of the solutions in this book, you've built and deployed your applications as farm-level solutions. However, there are many interesting types of solutions that can be built using sandboxed solutions. For example, you could have Silverlight-based applications that integrate with Web 2.0, Azure Web services, or other types of Web-based services, and host them in SharePoint. You could build event receivers and workflow against lists, or use lists as data sources, and then code against them (for example, contacts or a vacation list). You can also leverage a growing set of community tools that will push the boundaries of what Visual Studio 2010 ships with (for example, the community Visual Web part created by Wouter van Vugt).

Before you start the following exercise, you must create a simple list called Customers. Change the Title field to be Customer, and then add a new column called Total Sales (of type Currency). Add some data to the list so that it looks like Figure 4.

Figure 4. Customer list

Try It Out: Creating a Sandboxed Solution

Sandboxed solutions are excellent ways to create and deploy solutions that can run within a site collection.

To create a sandboxed solution

1. Open Visual Studio 2010, click File, choose New, and then click Project. Navigate to the SharePoint 2010 node and select Empty SharePoint Project. Provide a name for the project (for example, SandboxedSolution), and then click OK. In the SharePoint Customization Wizard, select Deploy as Sandboxed Solution and then click Finish.

2. Right-click the Visual Studio project from the Solution Explorer, select Add, and then choose New Item. In the Add New Item dialog box, navigate to the SharePoint 2010 node and select Web Part. Provide a name for the Web part (for example, SSWebPart), and then click Add.

3. In the main Web part class file (for example, SSWebPart.cs), add the following bolded code to the project.

   using System;
   using System.ComponentModel;
   using System.Web;
   using System.Web.UI;
   using System.Web.UI.WebControls;
   using System.Web.UI.WebControls.WebParts;
   using Microsoft.SharePoint;
   using Microsoft.SharePoint.WebControls;
   using System.Text;
   
   namespace SandboxedSolution.SSWebPart
   {
     [ToolboxItemAttribute(false)]
     public class SSWebPart : WebPart
     {
       Label lblTitle = new Label();DataGrid dtgrdLists = new DataGrid();ListBox lstbxCustData = new ListBox();Button btnGetData = new Button();
   
       protected override void CreateChildControls()
       {
         this.Controls.Add(new LiteralControl("</br>"));lblTitle.Text = "List Data";lblTitle.Font.Bold = true;this.Controls.Add(lblTitle);this.Controls.Add(new LiteralControl("</br>"));this.Controls.Add(lstbxCustData);this.Controls.Add(new LiteralControl("</br>"));btnGetData.Text = "Get Data";this.Controls.Add(btnGetData);btnGetData.Click += new EventHandler(btnGetData_Click);}void btnGetData_Click(object sender, EventArgs e){lstbxCustData.Items.Clear();SPSite mySiteCollection = SPContext.Current.Site;SPWeb mySPSite = SPContext.Current.Web;SPList custList = mySPSite.Lists["Customers"];foreach (SPListItem item in custList.Items){lstbxCustData.Items.Add(item["Title"].ToString());lstbxCustData.Items.Add(item["Total Sales"].ToString());}}
     }
   }
   

4. In the .webpart file (for example, SSWebPart.webpart), amend the Title and Description properties to be more intuitive for the user, as per the following code snippet.

   …
     <properties>
       <property name="Title" type="string">SS Web Part</property>
       <property name="Description" type="string">
         Sandboxed Solution Web Part.</property>
     </properties>
   …
   

5. After you finish, click Build, and then Deploy Solution. This builds and deploys your sandboxed Web part to SharePoint.

6. After Visual Studio deploys successfully to SharePoint, click Site Actions, and then Site Settings at your top-level SharePoint site. Then, under the Galleries section, click Solutions. You will now see the sandboxed solution added to the Solutions Gallery — which is where SharePoint stores all of the sandboxed solutions for your SharePoint site. Note that when the solution is added to the Solutions Gallery, as shown in Figure 5, SharePoint activates it for you.

   Figure 5. Solutions Gallery

   

7. Now, browse to your top-level SharePoint site, click Site Actions, and then Edit Page. Click anywhere on the page. Then, click the Insert tab and select Web Part. Navigate to the Custom Web Part group and then select your sandboxed solution. It should look similar to Figure 6 when you click Get Data.

   Figure 6. Sandboxed Solution Web part

   

How it works

On the SharePoint server, sandboxed solutions run in a separate worker process called SPUCWorkerProcess.exe that isolates them. Farm-level solutions are hosted in the IIS worker process (W3WP.exe) and have access to all farm resources. Running code within the SPUCWorkerProcess.exe runs code that can only affect the site collection where you've deployed the solution.

In this exercise, you created a simple Web part that accessed data in a SharePoint list called Customers. And, while the presentation of the Web part wasn't what you'd call advanced design, one of the key pieces was that you were interacting with a list within the site collection. This was done when you called the btnGetData_Click event, set the current SharePoint context to Current.Site, retrieved the Customers list, and then added information from the Customers list to the lstbxCusData list box.

void lnkbtnGetData_Click(object sender, EventArgs e)
  {
    SPSite mySiteCollection = SPContext.Current.Site;
    SPWeb mySPSite = SPContext.Current.Web;
    SPList custList = mySPSite.Lists["Customers"];
    foreach (SPListItem item in custList.Items)
      {
        lstbxCustData.Items.Add(item["Title"].ToString());
        lstbxCustData.Items.Add(item["Total Sales"].ToString());
      }
  }

If you had been trying to access resources outside of the scope of the site collection, this application would not have worked.

Secure Store Service (SSS)

In Chapter 8, you learned about Business Connectivity Services (BCS) and how you could build SharePoint solutions that integrate with external data systems. One of the primary ways to integrate security with the external data systems to BCS is the SSS. These external data systems can use SSS when they do not share a username and password with the AD-based users of SharePoint.

SSS is a shared service that provides the storage and mapping of user credentials from an external system to SharePoint. SSS stores account usernames and passwords, and maps these credentials to solutions (for example, external content types) by way of an application identity (Application ID) or group of identities.

A real-world example of this security integration is if John Doe has an account that lives in AD, and he has another account that lives in a separate system such as PeopleSoft, SSS can be used to link his external system (that is, the PeopleSoft system) credentials to his Windows credentials. Thus, when he tries to load an external list with data in it, the external content type can rationalize the two sets of credentials, and load the data for John to see. It does this by way of your configuring the external content type to map the Application ID of the SSS to the external data system with the credentials that are stored in it.

Let's say that you've created a new BCS solution (for example, an external list that surfaces CRM data in your SharePoint site) that requires you to map the separate set of user credentials with SharePoint. How do you go about configuring SSS to map the external content type that surfaces that data?

To configure SSS, you must first create a new instance of SSS by clicking Central Administration, Application Management, and then Manage Service Applications. On the ribbon, when you click the New drop-down arrow, you'll see an option where you can create a new SSS, as shown in Figure 7.

Figure 7. Creating a new instance of a Secure Store Service

This prompts the Create New Secure Store Service Application dialog box shown in Figure 8, where you can type information about the SSS (for example, Service Application Name, type of credentials to use with the database that stores the external system credentials, application pool to use, and so on).

Figure 8. Creating a new SSS application

Because you will be storing sensitive data in the SSS application database, after you've created the new SSS application, you must encrypt it by clicking Generate New Key on the ribbon. You will be prompted for a strong passphrase, after which you can walk through a wizard to create the Application ID — this includes adding the external data system credentials. In Figure 9, you can see that the Application ID MyCRMSettings now exists, and you can use it to map John's external credentials to the BCS application.

Figure 9. Target Application ID

With the Application ID created, you can now begin to use it when you are creating new external content types. For example, Figure 10 shows a dialog for creating a new connection (when creating an external content type in SharePoint Designer 2010). Note that the SSS Application ID that is being used is the one described earlier. Thus, all user credentials stored in the MyCRMSettings Application ID will now have access to the external list that is surfaced in SharePoint.

Figure 10. Using the target Application ID

Federated Authentication

While you may build solutions to a SharePoint site that members of your organization use (thus authorized through AD), you may also want to expose content and solutions to those who are not in your domain. To provision connectivity that is not for anonymous access, you must have a "single sign-on" process, which can be implemented in different ways. This section examines the concepts of forms-based authentication and claims-based authentication.

Forms-Based Authentication

Forms-based authentication (FBA) is based on ASP.NET, and provides users access to a system using a prompt (or login page) that will collect a username and password from the user trying to access the system. You'll see this quite a bit when you want to provide access to registered users (to add content to a site, for example), but the users do not exist as a record within AD.

FBA is a cookie-based authentication system that either prompts or redirects users to a login page, where the user provides the appropriate credentials to access a SharePoint site. When the user enters his or her credentials into the login page, there is a comparison with a credential store. If there is a match, then the user is allowed to access the site. If there is not a match, then the user is denied access.

The custom identity store (or membership provider) can manifest in a number of ways, such as an XML file, SQL Server database, Access database, and so on — although, SQL Server is the easiest of the these options to set up and use. You store what is referred to as membership information in the custom identity store, which includes information about roles, profile, and personalization information.

There are a number of steps when setting up FBA for SharePoint that you'll need to walk through. At a high-level, these steps are as follows:

1. Create an identity store/membership provider.

2. Provision access to the membership provider.

3. Configure IIS to support the new membership provider.

4. Create a new Web application that enables FBA in the Default zone.

Figure 11 shows where you enable FBA when you create a new Web application in SharePoint Central Administration. You get here by opening Central Administration and then clicking Manage Web Applications and New on the ribbon to create a new Web application. This creates a new Web application in IIS that supports FBA. You select the Enable Forms Based Authentication (FBA) checkbox, and then provide a membership provider name and a role manager name.

Figure 11. Enabling FBA

When using FBA, note that you must amend SharePoint's web.config file to include information to support. For example, you may need to include the connection string to your membership provider and PeoplePicker wildcards in the web.config file.

Claims-Based Authentication

SharePoint Server 2010 incorporates a powerful and flexible approach to authenticating users. It works with any organizational identity system, including AD, Lightweight Directory Access Protocol (LDAP), system-specific databases, and more Web-centric models such as LiveID. This approach is known as claims-based authentication.

Claims-based authentication was created around the concept of an identity, and is based on accepted industry standards such as WS-* and protocols such as the Security Assertion Markup Language (SAML).

SAML is an XML-based standard for exchanging authentication data between an identity provider and a service provider that live on different domains. At the heart of this data exchange is a SAML token, which essentially provides information about the users trying to authenticate themselves against a particular system. The SAML token is essentially the "claims" part. It provides information that makes a claim as to who users are, and what they have access to. You might think of a token as metadata about the users that stays with them throughout their sessions.

While AD provides limited claims (or information) about a user, you can create an identity through information such as a name, email address, phone number, title, and so on. This is one of the reasons why claims-based authentication is a more flexible model than AD. You can provide as much information as you want within a claim, and then use standards to communicate that claim across systems and domains.

The identity delivers important aspects of an application, such as identifying the user who is trying to access the system, the permissions that should be granted to the user, and how the application interacts with the user. Through the exchange of the SAML token, it is possible, then, to federate your identity across systems — systems that cross the boundaries of server farms, domains, platforms, and, of course, networks.

When it comes to SharePoint, claims-based authentication can involve custom code. This is because you must understand how you can validate the SAML tokens that are exchanged across the domains. For example, you can use the Windows Identity Foundation (WIF) with your WCF or ASP.NET applications to manage SAML tokens.

As mentioned earlier in the chapter, leveraging claims-based authentication will also involve having an issuer in place, such as Active Directory Federated Services (ADFS) 2.0. The issuer is the service that issues the tokens. With the issuer and the SAML token, you must also ensure that the application is using the token trusts and is aware of the issuer.

Summary

There are many different types of security within SharePoint. This chapter provided a high-level view of some of the different types of security that you will come across when developing (and administering) SharePoint.

For example, this chapter discussed authorization and Active Directory (AD), developing solutions that run at different levels of system trust, connecting external data systems to SharePoint using Secure Store Service (SSS), and, finally, federated authentication through forms-based and claims-based authentication. You will definitely want to further explore these and other security topics for SharePoint as you move forward in your SharePoint development activities.

Exercises

1. Create a security group in your SharePoint site using members from AD. Provision access to the site as full control to that security group.

2. Create a more complex sandboxed solution that reads and writes data within a site collection.

3. Create a new Application ID in the SSS. Add your credentials as the only set of credentials to the new Application ID, and then use it in a BCS-based application.

4. Set up a SharePoint site to use FBA.

What you learned in this chapter

Items	Description
Active Directory (AD)	AD is a Windows-based technology that provides key network and security services, such as directory services, Domain Name System (DNS) based naming and network information, network authority management, central identity storage, and so on.
Farm-Level Solution	A solution that runs with full trust and access to farm-level resources in SharePoint.
Sandboxed Solution	A solution that runs in an isolated worker process (SPUCWorkerProcess.exe), and provides access to a restricted set of APIs and objects within SharePoint.
Secure Store Service	A service that provisions secure connections between external data systems and BCS applications.
Forms-Based Authentication	An ASP.NET method of authentication that prompts the user (through a form) for a username and password.
Claims-Based Authentication	A form of authentication that uses claims (that is, SAML tokens) that contain information about the user.

Recommended Reading

For more information, see the following resources:

• Beginning SharePoint 2010 Development: Chapter 10: Developing Service-Oriented Applications for SharePoint 2010

• Channel 9: Sandboxed Solutions

• Channel 9: Claims-Based Security

• Forms Authentication in SharePoint Products and Technologies (Part 2): Membership and Role Provider Samples

• Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Authentication vs. Windows Authentication

• SummitCloud Blog: Forms-Based Authentication (FBA) on SharePoint 2010

• Plan Authentication Methods (SharePoint Server 2010)

About the Author

Steve Fox is a senior technical evangelist in the Developer Platform Evangelism group at Microsoft. He has worked in the IT industry for more than 15 years, and has worked in natural language, search, developer tools, and, more recently, Office Business Application and SharePoint development. Mr. Fox also presents at both domestic and international conferences (TechEd, PDC, DevConnections, and SAP TechEd, among others), and has written several books, including Professional SharePoint 2007 Development using Silverlight 2 (Indianapolis: Wiley, 2009) and Microsoft .NET and SAP (Redmond, WA: Microsoft Press, 2009), and articles for MSDN Magazine and other technical magazines. Mr. Fox lives in Redmond, Washington.