Controlling SharePoint Access

SharePoint 2007 provides many mechanisms for controlling user access to resources. It provides flexibility in authenticating and identifying users as well as granularity in authorizing what users can do once they’ve been identified. Understanding Share- Point’s end-to-end security model and the major components of the authentication and authorization architecture will help you design a security model to suit your business needs. In this article, I use the term SharePoint to refer to both Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007, and I’ll call out specific product names when necessary.

The Site Framework—Web Applications and Site Collections
Understanding the authentication and authorization process requires an appreciation of what I term the site framework—in particular, Web applications and site collections. SharePoint is a Web-based application, and it’s Microsoft IIS running on Web front-end servers that initially processes user requests. Ultimately these requests come in the form of a URL (e.g., http:// friends.laphroaig.com, http://islay.com/sites/ardbeg, or http://islay.com/sites/friends/laahs/ myplot.doc), and therefore SharePoint-specific processing must occur based on the incoming URL.

IIS can support multiple Web sites, and each site is uniquely defined using a combination of IP address, port number, and host header. When you want SharePoint to handle incoming URLs, essentially you extend an IIS Web site turning it into a SharePoint Web application, whereupon SharePoint handles the URL requests. (In WSS 2.0 and SharePoint Portal Server—SPS—2003 terminology, a Web application is known as a virtual server). And just as IIS can host multiple Web sites, so too can you have multiple Web applications.

Do you need multiple Web applications? That’s a question you need to ask as part of your deployment planning, and many factors will influence this decision, such as differing security needs, need for content isolation, and namespace requirements. From a security standpoint, it’s the Web applications that essentially control the authentication method that SharePoint uses for a particular URL namespace. Given that you can have different Web applications pointing to the same content, you can use different authentication schemes for different scenarios (e.g., accessing a SharePoint site from the Internet as opposed to accessing it from the Intranet).

In a SharePoint 2007 farm, all Web applications exist on all Web front-end servers with their definition being automatically replicated by the topology platform service so that the same authentication method is used consistently, regardless of which Web front-end server receives your initial request. (In WSS 2.0 and SPS 2003, you had to manually clone any virtual servers across physical Web frontend servers).

Web applications host one or more site collections. As the name suggests, this is a collection of sites consisting of one top-level site and one or more subsites. All the sites in a site collection will be part of the same URL namespace from the top-level site down. So, for example, if http:// laphroaig.com/sites/friends is your top-level site, then a subsite called plots will have the URL http:// laphroaig.com/sites/friends/plots. Each site within the collection then houses its own content in terms of items contained within lists and libraries, both of which can contain any number of folders. Do note that various resources, such as site-wide columns and quotas, are shared among the different sites in a collection. Also, site collections are essentially the unit of administration, are wholly contained within a single content database, and can be backed-up and restored into a different content database, even within a different SharePoint farm. You can see in Figure 1 how site collections are organized within a farm, and Figure 2 provides a sample deployment that supports multiple namespaces through multiple Web applications.

Granting users the rights to perform different actions on the resources within a site collection is what we mean by authorization. However, before you can do this you need to be able to identify who someone is via authentication.

Authentication
IIS manages the authentication process for SharePoint 2007 and, unlike WSS 2.0/ SPS 2003, SharePoint 2007 no longer limits you to standard Windows authentication methods. Most current SharePoint implementations use Active Directory (AD) as the identity management system against which users are authenticated, but with the support of ASP.NET pluggable authentication, SharePoint 2007 has now opened the door to any number of authentication methods and, by implication, to any number of identity management systems. For example, you can now choose to verify who someone is against a simple list of usernames and passwords held in a file or database or against an enterprise directory system of your choice.

This functionality requires something called a membership provider, which can query the specific repository and validate whether a particular user exists based on a supplied username and password. The username and password are collected from the requesting user via a form and passed to the membership provider. ASP. NET 2.0 (upon which Share- Point is built) ships a SQL membership provider, and MOSS provides an LDAP one, but you can also roll your own if needs dictate. Optionally, you can implement a role provider that can define groups of users within your overall membership, and these groups, as well as individual users, can subsequently be used to authorize access to SharePoint resources.

When you create a Web application, you define the authentication method to use for identifying users who want to access content in the site collections that are within that Web application. A Web application can have only one authentication method associated with it. Therefore, if you want to access the same content via a different mechanism, you need to extend the existing Web application to another zone. There are five available zones: Default, Internet, Intranet, Extranet, and Custom. Each one is essentially just another IIS Web site configured with a suitable authentication method. The Default zone is automatically used when you first create a Web application, and the authentication method on this zone has to be Windows. The names of the other zones are simply descriptive and don’t enforce any specific processing, but their names certainly reflect the most common scenarios in which you might deploy Share- Point content.

When you extend an existing Web application into another zone, you supply the URL for that zone. Thus different URL namespaces can invoke different authentication methods for the same content. We can see this in action in Figure 3, page 64, in which I’m attempting to access the same content via two different URLs—one using Windows authentication (http://employees.laphroaig.com) and one using forms with a SQL membership provider (http://friends .laphroaig.com). You can also use Alternate Access Mappings to support other namespaces, but that’s outside the scope of this article.

With an extended zone with an authentication provider applied to it, you essentially have two sets of security principals that can now be used to authorize access to resources. When you define a membership provider, you give it a name, which is subsequently used to identify members within that provider. In this case, I have named my provider “Friends.” You can see in Figure 4 that when I browse for users with a name of “Kevin,” users from both the current Windows AD domain (ISLAY\Kevin) and the membership provider (Friends:Kevin) are returned. Now that you can identify who people are, let’s see how you can grant them access to SharePoint resources.

Continue on Page 2

   Previous  [1]  2  Next