Microsoft Office SharePoint Server 2007 (referred to throughout this document as “MOSS”) is a software platform that is used to create web-based portal solutions such as Corporate Portals, Corporate Web Sites, Extranets, Intranets, and Internet Sites. A web application built using MOSS is essentially a fully packaged ASP.NET application including management and configuration tools, integrated Web Part architecture, and an end-to-end security model. It also includes features that provide site provisioning, business intelligence, business process management, collaboration, content management, and enterprise search.

Introduction

In order for a web application to exist in today’s business environment, it must stand up to modern day information security standards. Additionally, organizations maintain their own sets of information security policies, corporate compliance requirements and technical specifications. The purpose of this document is to explore the security model of MOSS and to explain how it is equipped to meet corporate security requirements. This document is not intended to recommend how to configure MOSS, nor does it try to answer why an organization should use MOSS.

Web Application Composition

The term web application refers to a single named instance of a MOSS solution such as a corporate portal or a project collaboration web site. A MOSS web application is composed of a collection of web sites (site collections) as multiple web pages are necessary in a solution such as a portal.

It is important to note that these web sites are structured in a hierarchical fashion much like Windows folders. There is one root web site and often this root site is labeled as “Home” and it is the first site the end user sees when he/she enters the portal. Beneath the root site are top level sites. Top level sites may contain multiple sub-sites; sub-sites may also contain more sub-sites, and this pattern can continue downward in the hierarchy.

Each site in the hierarchy contains at least one content page. Content pages include the navigational elements, headings, images, and content that the user sees when they navigate to the site. Content pages also contain web parts.

In order to have a complete understanding of the SharePoint security model, it is important to understand what web parts are and how they are used in content pages. Web parts are the individual building blocks that provide functionality and content on a content page. Web parts have properties. Properties define the appearance, behavior, and other characteristics of the web part. There are different types of web parts and each type of web part serves a distinct purpose for the content page that contains it. For example, a Content Editor Web Part may be used on a site to present a welcome message on that site, while an Image Web Part may be used to position an image on a content page.

For purposes of explaining the security concepts of web parts throughout this document, there are web parts that contain items and there are web parts that do not contain items. Web parts that contain items have additional security capabilities.

One web part that contains items, like records in a database table, is a Custom List. Custom Lists have several properties; list columns are an important example of this. Columns define what type of information is stored in the list pertaining to each list item. Columns can be of a wide range of data types such as single line of text, multiple lines of text, number, currency, date and time, or even the value resulting from a regular expression. An example of a custom list may be a list of departments in an organization. The list can contain columns to track department name, department manager, number of employees, and so forth, as shown in Figure 1 below.

Figure 1

A document library also contains items. Document libraries are intended to store documents and metadata describing the documents. Each document with its corresponding metadata fields make up an item in the document library. For example, a document library may store technical documents and there may be columns for tracking information about the document such as the author, content type, and the date the document was created. An item would refer to the document, and the fields describing the document author, content type, and date created.

Web parts which contain items generally allow file attachments. It is important to note that MOSS has the ability to block certain types of files from being uploaded into a MOSS web application. For example, .EXE files are considered risky because they can contain malicious code and virus. Many organizations choose to block .EXE files from being sent and received within their email systems to eliminate the risk that these types of files could cause ill effect. There is a management screen available in MOSS where a list of blocked file extensions is maintained. File extensions are added to the list to block the file type, and removed from the list to allow the file type. In MOSS, several file types are blocked by default.

Accessibility

MOSS web applications utilize IIS web sites and application pools. As is the case with any web site, a unique combination of IP address, port number, and host header on each web site is required in order for the web site to run properly. Additionally, the web site must maintain a unique identity with respect to other nodes on the network in order for users on the network to be able to access the web application. Network configurations and services that exist between the users and the MOSS server including DNS, WINS, firewalls, routers, switch ports, virtual LANs, must also be configured in such a manner as to permit the user to access the IIS web site. In an Extranet configuration, an externally facing host name or IP address must be published so that users can access the web application. The hardware configuration of the MOSS server, the network configuration of the MOSS network, and the IIS configuration of the web sites for the MOSS web applications provide user accessibility to the web application.

Authentication

In order for people to use a MOSS web application, the web application must validate the person’s identity. This process is known as authentication. MOSS is not a directory service and the actual authentication process is handled by IIS, not MOSS. However, MOSS is responsible for authorization to MOSS sites and content after a user successfully authenticates. Authentication happens like this: A user points their browser at a MOSS site and IIS performs the user validation using the authentication method that is configured for the environment. If the user authentication is successful, then MOSS renders the web pages based on the access level of the user. If authentication fails, the user is denied access to the MOSS site.

Authentication methods determine which type of identity directory can be used and how users are authenticated by IIS. MOSS supports three methods of authentication: Windows, ASP.NET Forms, and Web Single Sign-On.

Windows Authentication is the most common authentication type used in MOSS intranet deployments because it uses Active Directory to validate users. When Windows Authentication is configured, IIS uses the Windows authentication protocol that is configured in IIS. NTLM, Kerberos, certificates, basic, and digest protocols are supported. When Windows authentication is configured, the security policies which are applied to the user accounts are configured within Active Directory. For example, account expiration policies, password complexity policies, and password history policies are all defined in Active Directory and not in MOSS. When a user attempts to authenticate to a MOSS web application using Windows authentication, IIS validates the user against NTFS and Active Directory, and once the validation occurs the user is authenticated and the access levels of that user are then applied by MOSS.

Figure 2 below, taken from Microsoft TechNet, illustrates the MOSS authentication process.

Anonymous access is considered to be a Windows authentication method because it associates unknown users with an anonymous user account (IUSR_MACHINENAME). Anonymous access is commonly used in internet Web sites and in situations where web site users will not have their own user accounts. Since exposing content to unknown users is risky, this configuration is disabled by default. In order to configure anonymous access to a MOSS web application, anonymous access must be enabled in IIS, enabled in the MOSS web application, and the anonymous user account must be provisioned throughout the MOSS Web application. Even when anonymous access is configured, there are still several limitations compared to a Windows user. By default, anonymous users are only allowed to read, and they are unable to edit, update, or delete content. Additionally, anonymous users are not able to utilize personalization features such as Microsoft Office integration, check-in/check-out and email alerts.

The ASP.NET Forms authentication method is commonly used in situations where a custom authentication provider is required. In other words, where a custom LDAP, SQL Server, or other type of identity repository will be storing user account information. This is common in extranet environments, such as partner collaboration sites, where it is not practical to create Active Directory user accounts for users or a different type of directory is required.

The Web Single Sign-On authentication method is used in environments that have federated identity systems or single sign-on systems configured. In this type of environment, an independent identity management system integrates user identities across heterogeneous directories and provides the user validation for IIS. Some examples of identity management systems with single sign-on capability include Microsoft Identity Information Server with Active Directory Federation Services, Oracle Identity Management with Single Sign-On and Web Access Control, Sun Microsystems Java System Identity Manager, and Netegrity SiteMinder. Large enterprises often implement federated identity models to ease the administration of user provisioning and de-provisioning for systems that span across companies. Single Sign-On systems are used to consolidate user accounts across heterogeneous systems, allowing the end user to authenticate to systems with one set of credentials, rather than to use a different set of credentials for each unique system.

In MOSS, it is possible to configure web applications to use a combination of authentication methods. This provides a great deal of flexibility because it makes it possible to serve a web application to different user bases which have different identity requirements. For example, an organization may have a Project Collaboration Web site that is used by employees and partners. For security and compliance reasons, it is necessary to store employee user accounts in Active Directory and partner user accounts in a SQL Server database. In this case, MOSS can be configured to use Windows authentication and ASP.NET Forms authentication. This is achieved by defining various zones and associated authentication methods to the zones. In the example above, an intranet zone would be configured with Windows authentication and an extranet zone would be configured with ASP.NET Forms authentication.

Access

As explained in previous sections, the composition of a MOSS web application includes sites, content pages, and web parts. MOSS has several management controls in place for provisioning access to and within a web application.

Users, groups, permissions, and permission levels are used to configure access within a MOSS Web application. MOSS provides management and configuration functionality for these objects. In MOSS, users are added from the directory service such as Active Directory. Once users are added to a site collection, they are added to groups and assigned permissions on sites, lists, and items. MOSS supports the creation of SharePoint groups, for which the memberships are maintained within MOSS. Additionally, Active Directory security groups may also be used directly in MOSS. Active Directory group memberships are managed in Active Directory.

Users and groups gain access or are restricted access to sites and Web Parts based upon permission levels set for the users and groups. Permissions are individual rights that may be performed by a user in a site, list, or item and so these types of permissions are referred to as Site Permissions, List Permissions, and Item Permissions, respectively. There are over thirty permissions in MOSS.

Permissions are applied to users and groups using permission levels. Permission levels allow roles to be defined, consisting of unique combinations of individual permissions. MOSS provides some default permission levels such as “Contribute and “Full Control,” but in addition to using the default permission levels, custom permissions can be created in cases where a more appropriate name is required or a unique combination of permissions is more appropriate than what is available by default. Existing permission levels may be copied and used as starting point when creating custom permission levels. Permissions are assigned to users and groups in a similar fashion as in the Windows operating system. Much like the access control lists that allow assigning permissions to users and groups on Windows folders, MOSS provides similar access control lists on sites, lists, and items.

The relationship between sites, lists, and items is hierarchical in nature and the default behavior within MOSS web applications is that the permissions are inherited by child objects from the parent objects. In cases where business requirements are such that a child object is required to have different permissions than the parent object, then the permission inheritance chain may be broken manually using the access control list of the child object and the child object may be configured with permissions different from its parent. When this type of modification is made then all child objects of the modified object inherit the new settings.

To provide an example of this, imagine a MOSS site that contains a document library, which contains a set of documents. By default, the document library will inherit permissions from its parent site and each document contained within the document library will inherit permissions from the document library. Say, for instance, that there is a requirement that the document library has different permissions than the site; perhaps a group of users should be able to read contents of a site, but not be able to view contents of a document library. The permissions for the document library may be configured accordingly. Doing so will achieve the desired result and not affect the permissions of the parent site. Additionally, individual document (item) permissions may be configured so that they have different permissions than the modified document library. Keep in mind that since the relationship between the objects is hierarchical, users must at least have read access to the parent in order to gain access to the child object.

Figure 3

The access control lists for sites, lists, and items are very similar. However, lists provide one additional configuration menu called advanced settings, which allows an added layer of security to be set on the child items. Within advanced settings specifications may be made such that users can view all items or view only their own items. There is also a setting for specifying that users can edit all items, their own items, or no items in the list.

Figure 4

Additionally, document libraries can contain folders and it is possible to set permissions on these folders.

Figure 5

Audiences

Not all MOSS Web Parts have access control lists: only those Web Parts which contained items such as lists and document libraries. However, all Web Parts do support audiences. Audiences are used to target content to users. SharePoint Groups, AD Groups, AD Users, and global audiences may be used to define the audience of a particular Web Part. Audiences allow the restriction and filtering of certain content that exists on a content page to users who otherwise have some level of access to the page. For example, an organization may have a MOSS portal that serves employees, contractors, and partners. Perhaps there is an employee announcement Web Part on the home page. It may not be appropriate for contractors and partners to view the employee announcements. It is possible to target the employee announcements Web Part to a specific audience, in this case a security group called employees.

Figure 6

Search

In MOSS, users are able to search for content across many different content sources such as MOSS portals, Web sites, network file shares, structured data stored in line of business systems, and people profiles stored within Active Directory and other custom data sources. The MOSS security model is fully integrated with the search feature and therefore all of the content access concepts that apply to sites, web parts, and items also apply to search results. For example, if a user does not have read access to a particular document library and the user performs a search, that user’s search results will not include any links to the document library or any documents contained within that document library. Likewise, if a user only has read access to a particular document and the user opens a link to that document from a search results page, that user will be unable to edit that document.

There are several management controls available with MOSS that allow for custom tailoring of how content is crawled, what content can be searched, and how the search results appear to the end users who are performing the search. Using these controls, MOSS search can be configured to meet unique security and compliance requirements for searching content.

Administration

In MOSS, there are two types of administrators that are configured, which allows the responsibilities associated with server component configuration to be separated from those responsibilities associated with content management and content access management.

Central Administrators are used to configure SharePoint components on a server. By default these administrators don’t have access to modify content contained within site collections. Central Administrators are able to grant themselves access to content contained within site collections and events related to this are tracked in the event log for auditing purposes.

Site Collection Administrators are assigned at the site collection level and have full control over content contained in that site collection. Site Collection Administrators are able to perform all the necessary tasks involved with administering content including the ability to restore content that has been deleted from the Recycle Bin and override check-out of documents. Site Collection Administrators are configured in a separate menu than where other types of users are provisioned and it is impossible for other types of users to revoke permissions from Site Collection Administrators.

Hardware, Software, and Network

Beyond the context of the MOSS application itself, there are several security related topics that have to do with the way MOSS is installed and configured in a network environment. It is important to understand the server and network topology of a MOSS deployment because many of the security considerations exist at this level.

The major software components included in a MOSS installation are the Windows Operating System, IIS, .NET Framework, SQL Server, and MOSS. As an ASP.NET application, the principles of .NET code access security apply to MOSS installations. Configuration files on MOSS servers such as machine.config and web.config are used to prevent or allow code from being run on MOSS systems.

MOSS is designed to be scalable so that it can be configured to serve small workgroups, large enterprises, or serve public Internet sites. The MOSS application is divided into several different services that can run on one server in a single server deployment or divided across multiple servers in a server farm deployment. Servers in a server farm can have various roles, meaning that they have certain services running on them. For example a two-server farm may include a database server that runs only the database components and a web server than runs the web applications and application services. MOSS servers are required to communicate with each other and with end users and this communication occur on channels. It is certainly possible to secure these channels, and MOSS does support doing so. For example, it is possible to use SSL to secure a channel between a Web server and a client machine or IPSec to secure a channel between two servers.

On the network, there are several other areas that relate to the security of MOSS. Servers exist as nodes on a TCP/IP network and networks can be running a wide variety of hardware including switches, routers, firewalls, and load balancers. The network security of a MOSS server farm depends upon the configuration on these network devices. For example, a network may be configured with multiple network segments, DMZs, or VLANs. MOSS servers can be configured to operate in unique TCP/IP network environments.

Conclusion

Microsoft Office SharePoint Server 2007 is equipped to meet complex business requirements pertaining to security and compliance for Web applications in every security context. MOSS has a robust security model that provides management capabilities for controlling how MOSS is configured in a network, controlling how users access web applications, and controlling user access to content within web applications. The security model integrates seamlessly with Windows Server, Active Directory, Exchange Server, SQL Server, IIS and the .NET Framework. MOSS can be configured in many different ways to meet varying needs. The platform is also highly customizable, so there are virtually no hard limitations when building a web application solution using MOSS.