Executive Summary: Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) 3.0 provide flexibility in authenticating and identifying users as well as granularity in authorizing what users can do once they've been identified. Understanding SharePoint's end-to-end security model will help you design a security model to suit your business needs and help you safeguard sensitive or confidential SharePoint content.

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

Authorization
Authorizing access is a case of granting permissions to securable objects. When doing so, you need to consider the following five components:

Individual permissions. These permissions grant the ability to perform specific actions. For example, the View Items permission gives the user the ability to view items in a list. The list of individual permissions that are available are farmvaliwide but can be controlled at the Web application level by a farm-level administrator.

Permission level. This component groups individual permissions together for easier management and assignment. WSS has five default permission levels: Limited Access, Read, Contribute, Design, and Full Control. MOSS adds a few more such as Approve and Manage Hierarchy. You can add new permission levels or change the default levels to suit your needs. Permission levels are per-site and can either be inherited from a parent site or explicitly set at a subsite, library, or item level. User. User is a security principal that can be identified using one of the authentication methods associated with the Web application.

Group. A group identifies a set of users. It can be a Windows security group, a role that’s verified via a role provider, or a Share- Point Group such as Site Owners, Site Members, or Site Visitors. SharePoint Groups are new to SharePoint 2007 and essentially replace site groups. Groups provide a way for SharePoint site collection administrators to group users without having to rely on IT to create Windows security groups.

Securable object. Users or groups (either Windows Security groups, Roles or Share- Point Groups) are assigned a permission level for a specific securable object: site, list, library, folder, document, or item. By default, permissions for a list, library, folder, document, or item are inherited from the parent site, parent list, or parent library. However, anyone assigned a permission level that includes the Manage Permissions permission for a particular securable object can change the permissions for that securable object. SharePoint allows item-level permissions, which means that a user could be granted access to an individual document in a document library and not be able to access any other part of the SharePoint site. Access permissions on individual items also comes into play for the security-trimmed UI that SharePoint 2007 employs. You can see only items (including Web Parts) to which you have read access, and you can’t see options whose function requires a permission that you don’t have. For ease of maintenance, always use a group to assign permission levels to a securable object. Granting individual user access should be done only on an exception basis.

Storing User Details and Establishing Permissions So how does SharePoint store information about users such that it can subsequently validate their access to resources? First, users can receive explicit access to objects via their user accounts or implicit access by being members of a security group or role. Furthermore, you can add users, security groups, or roles as individual entities or as members of a SharePoint Group. The latter is the preferred method as it eases overall management.

When you grant a user, security group or role any form of access to any resource in a site collection—either individually or via a SharePoint Group—an entry for that security principal is created in the UserInfo table in the content database that is associated with the site collection. (Their details are also put into the User Information List, which is what you see when you view All People through the browser interface.) Thus, if a security principal has access to multiple site collections, it will have multiple entries in the UserInfo table. This table stores, amongst other things, an internal identifier for the security principal that’s used in many other tables, an indication of whether the principal is a security group or role, and the security identifier of the principal from its authentication provider. For the Windows provider, this is the Security Identifier (SID) of the user or group. For other providers, it’s the unique identifier that that provider has allocated to the principal. If a user has been granted implicit access to a resource via a security group or role, then an entry in the UserInfo table is created for that user account the first time the user successfully accesses a resource in the site collection.

Four other tables come into play when establishing the permissions that a user ultimately has. First, the Groups and Group- Membership tables. When a SharePoint Group is defined, its details are stored in the Groups table, and the GroupMembership table has links to the individual users as defined in the UserInfo table. Thus, when you add security principals to a SharePoint Group, the GroupMembership table for that group is updated to include the internal identifiers for each principal in the UserInfo table. The other two tables are Roles and RoleAssigment. These are the tables that ultimately reveal the exact permissions that a requesting user has, with entries relating back to individual user records in the User- Info table and SharePoint Group records in the Groups table.

Permissions that are associated with your individual user account, security groups, and roles of which you are a member and SharePoint Groups you belong to are aggregated to form your final list of permissions. Well very nearly; there’s also something called Web Application Policies that apply permissions to the Web application as a whole, but detail for this is outside the scope of this article. Just know that these policies take precedence over permissions, and you can use them to globally deny or allow access to the Web application, then the individual user permissions come into play.

Concluding the Authentication and Authorization Process
So we now know how, through authentication providers, we can prove the identity of a requesting user and how we can store information about and assign permissions to known identities. So how does SharePoint validate that a requesting user is allowed to access a securable object?

When you access any resource in a site you’re essentially requesting an item from that site. For example, accessing the site’s home page is actually making a request for default.aspx, and editing an item in a list is a request for EditForm.aspx. If you pass the authentication process, then SharePoint is passed the primary SID that identifies you in the underlying authentication scheme (e.g., your SID for the Windows scheme). This identifier is subsequently used to look up your details in the UserInfo table every time you request a resource. From there, SharePoint can establish whether you have the required permission to perform the task at hand.

It’s important to note that SharePoint checks only your primary SID, which is important for the Windows security provider to know in cases in which your primary SID may have changed. This is typical in any form of domain migration.

Although many domain/user migration tools will retain the old SID in the user’s security token, SharePoint doesn’t check the sidHistory of the requesting user. Thus, there’s no match in the UserInfo table for the new SID, and the user loses access. You can use the –migrateuser switch in the Stsadm utility to replace the old user account with the new user account, but you must take this behavior into account in your rename and migration processes to retain seamless access going forward. You can learn more about the Stsadm tool in “Stsadm: Taking Control of SharePoint Administration” November 2007, InstantDoc ID 97107.

Final Advice
SharePoint 2007 offers much flexibility in terms of authentication and authorization, which, when carefully planned, can result in a very robust and functional environment for sharing resources on many different levels and differing environments. Although you can use multiple authentication schemes, do be aware that there are some functional differences that can result. You can read about these differences in the article “Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Authentication vs. Windows Authentication” (msdn2.microsoft.com/en-us/library/ bb977430.aspx), and because of the way access checks are performed, be aware of the steps you need to take when migrating user accounts, so that users maintain access to their SharePoint content.