SharePoint

7 New Features That Enhance Security in SharePoint

Adam Robert Buenz

 

At a Glance:

  • Authentication providers
  • Native encryption features
  • Alternate Access Mapping and zones
  • Information Rights Management

Implementing effective security measures for your Microsoft Office SharePoint Server (MOSS) 2007 environment can significantly reduce management overhead while allowing teams to

collaborate and share business data in a safe environment. Innovative authentication features built into MOSS 2007 let you employ Web-based security standards through custom authentication providers, Internet-style forms-based authentication, and Web single sign-on (SSO). Furthermore, MOSS offers granular rights management of business assets such as 2007 Microsoft® Office system files, native encryption features, and reduced client authentication obligations.

Here are seven security features provided by MOSS 2007 you can quickly put to work.

1. Pluggable Authentication Provider An authentication provider is a component that lets you verify user credentials. Configuring that authentication provider for your MOSS environment is an important security decision when setting up Internet-style SharePoint® authentication. MOSS continues to support the Windows®-based authentication methods available in previous SharePoint versions, including Integrated and Basic authentication (while adding Digest authentication) for resolving users to tangible Windows identities. However, resolving to a Windows identity is no longer the only option. You can even employ multiple authentication providers so that, for example, internal users log in via Windows authentication while external users do so with a separate, pluggable provider.

MOSS is built upon ASP.NET 2.0, which enables the use of pluggable authentication providers. This lets you use configurable directories for storing user information as long as there's an ASP.NET 2.0 membership provider (and optional role provider) that corresponds to the member data store. Pluggable provider credentials can be hashed, encrypted, or stored in plain-text depending on the node values stored in the machine.config file that correspond to the membership provider. Several membership providers are available for use with MOSS, some of which include an LDAP V3 membership provider (which ships with MOSS), plus a SQL ServerTM membership provider and Active Directory® membership provider available with ASP.NET 2.0.

The membership and role providers that can be implemented are not limited to the shipped providers. Using the ASP.NET 2.0 membership architecture, it is feasible to create custom providers that use membership stores like Microsoft AccessTM or Oracle databases, XML files, or even flat text files. A custom authentication provider inherits from the ASP.NET MembershipProvider interface, which in turn inherits from the ProviderBase class (see Figure 1).

Figure 1 .NET Membership Class Hierarchy

Figure 1** .NET Membership Class Hierarchy **

There are some implications of using ASP.NET 2.0 authentication (as opposed to Windows authentication) with MOSS that should be taken into consideration. The most significant for many users is reduced Microsoft Office client interoperation resulting from the fact that the Web service communication between MOSS and Office clients was originally designed for use with Windows identities.

Additionally, certain MOSS services, notably those related to crawling and indexing content, must use a Windows account even when using a pluggable provider. To do this using an authentication type that doesn't resolve to a Windows identity requires creating an additional MOSS zone that will employ Windows authentication. (I'll discuss zones later in this article.)

If you have a mandated PKI infrastructure based on security mechanisms such as smartcards where public keys or certificates are carried by clients, this typically requires that a Windows identity be resolved for proper client certificate acceptance and authorization, depending on implementation. This may, in turn, require creating an additional MOSS zone or other authentication configurations.

2. Forms-Based Authentication and Web Single Sign-On Another exciting authentication mechanism that is available to MOSS 2007 is forms-based authentication based on ASP.NET 2.0. In previous versions of SharePoint, this could only be achieved through a custom Internet Server Application Programming Interface (ISAPI) extension or by employing the CustomAuth ISAPI extension from the IIS 6.0 Toolkit. And even with those solutions, SharePoint still needs the account to resolve back to a Windows user identity, constraining perimeter-based deployments.

Forms-based MOSS authentication utilizes pluggable authentication and role providers to enable Internet-style security mechanisms that don't restrict customers to an old-fashioned NT login prompt. Instead, you can build a customized login process geared toward your users' needs. To protect the authentication process further, forms authentication cookies and authentication tickets are encrypted and tamper-proof.

The form identity provider does not have to reside locally and can, in fact, plug into an external identity management system, which in turn would provide the validation of the user credentials. This functionality is known as Web single sign-on, and it employs an HTTP module for external authentication. In such a scenario, you can federate identities between your organization and business partners whereby they are able to use their own organizational logins to authenticate to your MOSS implementation.

3. Encrypting MOSS Application Connection Strings It's not good a security practice to place valuable connection string information in plain text in a web.config file. The exposed information could enable a user to create an object instance to the SQL database server and manipulate valuable data. However, using inherent ASP.NET 2.0 functionality you can encrypt the data using either of two available technologies: Windows Data Protection API (DPAPI) or RSA encryption. DPAPI capitalizes on the built-in cryptographic functionality of Windows to encrypt and decrypt using the MOSS server machine key. RSA encryption lets you use public key algorithms, but carries the added overhead of needing appropriate containers for the encryption keys.

For MOSS 2007-and more specifically for the pluggable ASP.NET 2.0 SQL Server authentication provider-you would want to encrypt the <connectionStrings> node in cipher text since it is where the most significant security breach could occur:

<connectionStrings>
<add name="MembershipConnectionString" 
     connectionString="connectionString"/>
</connectionStrings>

Using DPAPI encryption is relatively straightforward and the easiest to implement since it uses native machine key encryption for either a virtual directory or a physical directory. There are other ways to implement this programmatically, but using the following commands in a command prompt is the least painful:

aspnet_regiis.exe -pe section -app MOSS_virtual_directory -prov provider

aspnet_regiis.exe -pef section MOSS_physical_directory -prov provider

Since you are primarily concerned only about implementing encryption for the connection strings node, you can just encrypt that specific section by specifying the section parameter:

aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Provider"

aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Provider"

After implementation, the nodes of sensitive information will be replaced by well-formed XML cipher values:

<connectionStrings confiProtectionProvider=
"EncryptionProvider">
<EncryptedData>
<CipherData>
<CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</CipherValue>
<CipherData>
</EncryptedData>
</connectionStrings>

Like the overall MOSS architecture, this model is pluggable in that you can create your own encryption providers to manage cipher text for relevant MOSS configuration files, such as web.config or machine.config, and, furthermore, you are not limited to RSA or DPAPI encryption.

Using encryption does have some consequences. Because you are using the local machine key for encryption, you can only use this configuration node on the MOSS server it was created on-otherwise the cipher process will fail. If an intruder gained access to the server, they could retrieve the machine key and decrypt the connection string. The decryption process will also cause a minor application performance hit.

4. Alternate Access Mapping and Zones Alternate Access Mapping (AAM) is crucial, especially when setting up more than one entry location for your SharePoint environment. AAM simply enables you to specify different URLs through which users can access a single physical site (see the diagram in Figure 2). AAM can direct users to the same physical path for your MOSS site, but with different authentication providers and Web application security policies. AAM also compensates for using different domains, reverse proxies, and other URL redirection mechanisms. The URL that MOSS will use is already mapped for you by default, but this can be extended to additional URLs that a SharePoint architect explicitly creates to handle different methods of entry. AAM is required to ensure that proper internal and public URL mapping works correctly.

A SQL Server Authentication Provider

Let's walk through the implementation of the pluggable ASP.NET 2.0 SQL Server authentication provider. This provider uses forms-based authentication with encrypted web.config connection strings, a very typical implementation for perimeter (extranet) MOSS deployments.

The first step in enabling the pluggable SQL Server provider is to ensure the database for user credential storage is created on the appropriate SQL Server instance so the service provider will have something to use as the membership data store. To do this, execute the following command from the Run dialog box or a command prompt:

%WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql

This will bring up a SQL Server wizard that allows you to configure the database for storing your member data.

Since most likely you haven't yet set up the membership provider for database storage, configure SQL Server for application services so it will create a new database. If you do have an existing database, you can add the relevant information (if database consolidation is an organizational objective).

The SQL connection string is going to connect to this SQL instance, so you should set up this database to use SQL Server authentication (see Figure A). At this point, I'll use a plain text username and password since, later in the setup process, I'll show you how to use native ASP.NET 2.0 encryption functionality to hide this private connection information in cipher text to prevent possible exploitation.

Creating the Login Form

Forms-based authentication is often used for externally facing sites that are going to reside on a perimeter network and be publicly exposed to all Internet users. With that in mind, when creating an extranet site collection, it is best to choose the Internet presence MOSS template. With this template you won't have to manually create a login form. If you are extending a current site or want to implement a custom login form, it's easy to make one yourself using Microsoft Visual Studio® 2005. Relatively little coding is required.

Start by opening up the site collection physical directory as a Web site through Visual Studio, typically stored in a location like this:

C:\Inetpub\wwwroot\wss\VirtualDirectories\<GUID>

The first step is to add a default.aspx page since this is the default document in the IIS virtual server settings. Use the Add Item command in Solution Explorer, then add a login control to the newly created Web Form surface through the Visual Studio Toolbox.

Figure b** Choosing Authentication Provider through the Application Management Screen **(Click the image for a larger view)

On the same page, ensure that the provider being used for authentication in the membership provider section is specified as AspNetSqlMembershipProvider and that Role manager name is AspNetSqlRoleProvider. Specify where you want end users to have anonymous access by navigating to /_layouts/setanon.aspx and selecting either the entire site or the security setting that is most appropriate to your needs.

You'll make the major changes by modifying web.config. Make sure the <authentication> element is set to use the <forms> element. This is usually configured automatically when you switch from Windows authentication to Forms authentication, and it's an important portion of the login process since it will carry the data about the users authentication ticket, which in turn will verify the user credentials on the page postback through ASP.NET 2.0 authentication methods. But web.config is still not aware of the SQL connection to your user store, so you must add the connection string entry to connect to the membership database:

<connectionStrings>
<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="Server=SQLserver;
Database=aspnetdb;uid=username;
pwd=password;" providerName="System.Data.SqlClient" />
</connectionStrings>

Make the same modifications to the Central Administration site web.config file to promote conformity of authentication types, and to ensure that the PeoplePickerWildCard resolves to the AspNetSqlMembershipProvider so that the lookup controls for adding users will know the correct path to search.

Since you are making changes to back-end XML files, MOSS requires that you reset IIS. Once you're connected to the SQL Server database, you can browse the Web site with ease—except you have no site collection owners to administrator the content. In the WAT, go to the Security tab and add a user, then make this user a site collection administrator by going to SharePoint Site Management and adding the appropriate users under Site Collection Administrators. The name should be correct because of the modifications to the peoplepicker node in web.config made earlier.

Lastly, encrypt the connection strings with DPAPI by opening up the run dialog and executing:

aspnet_regiis.exe -pef "connectionStrings"
"C:\Inetpub\wwwroot\WssVirtual\<GUID> " 
—prov "DataProtectionConfigurationProvider"

When the operation completes successfully, you'll receive a dialog confirming this.

Figure 2 URL Mapping and Zones

Figure 2** URL Mapping and Zones **(Click the image for a larger view)

In MOSS, zones are a new feature that allow greater control over the site mapping provided by AAM. Zones let you map different authentication providers to the same physical path and MOSS content depending on the AAM URL mappings through which users are connecting to the content. When specifying AAM URL mappings, although it is not necessary that the zone is bound to an authentication mechanism, it is recommended. An AAM URL mapping to a zone that is not defined in the authentication providers page will use the security setting for the Default zone.

Zones do require some planning since they will heavily impact how people are authenticated and routed through your portal from multiple URL entry points. When extending a new Web application, you can specify the zone you want to use under the Load Balancing URL section of the settings (see Figure 3). It is recommended that you place your most publicly accessible URL (for example, the URL you plan to expose to the Internet) in the Default zone, as this is the URL SharePoint will use if it cannot fully determine which zone you are in.

Figure 3 Configuring MOSS Zones

Figure 3** Configuring MOSS Zones **(Click the image for a larger view)

Within each zone you can bind a global Web application security policy that defines permissions settings for users in the zone. This lets you centrally manage large-scale permissions modifications. Web applications commonly include several sites in various site collections, and permissions management of these sites can become problematic when applications become large and complex. MOSS 2007 allows global security policies that bind policy settings such as full access, full read access, deny-write access, or deny-all access to a specific user or group within the application. These policies can override the granular permission settings provided by MOSS and managed from the SharePoint Central Administration interface, so you'll want to plan your configuration carefully.

Bringing this all together, your externally facing site might have two URLs as defined in your AAM settings: one for your corporate users to enter, and a second for external users. Each has a unique URL-perhaps contoso for internal users, and extranet.contoso.com for trusted external partners. While both of these URLs will map to the same content, each can access the site through its own zone, with its own authentication provider and its own application security policy. Configuring the intranet zone on the internal URL lets internal users resolve to their domain-authenticated Windows identities while external partners log in via Web single sign-on authentication through the extranet zone, which allows them to use their own organization's user credentials. By leveraging the power of binding Web application security policies to zones, it becomes possible to give all trusted external users full-read access, as opposed to manually setting it on an object-by-object basis.

5. Targeted Content for Secure Collaboration Locking down your SharePoint site collections means users will only handle information you authorize them to access. New flexible permission mechanisms allow you greater control over the various types of business information stored in your MOSS environment.

MOSS 2007 gives you the option to bind an identity to a specific object, whether a site collection, an individual site, a document library, a subfolder, a list, or an individual document or list item. This enforces granular access controls and explicit membership to that item, both denying access and adjusting the user interface so that users are unaware of items they don't have access to. This functionality in MOSS is known as Item Level Security (ILS) or Secured Objects (SO). MOSS object permissions are hierarchal in nature, allowing them to scale from individual objects such as list items up to larger items such as a list or document library. Permission inheritance can be implemented, allowing lower-level children objects to optionally inherit permissions from higher-level parent objects. There are 33 unique default permissions that can be given to a user or SharePoint group, each of which can be bound to an object. You can create new permission levels as well.

For example, within a project management site you can allow only developers and project managers access to sensitive development material, such as design specifications and coding techniques built in Microsoft Word documents stored in a document library. The library's permissions by default will inherit from the site permissions, but the permissions can be modified to give access only to developers and project managers, or even so that each Word document can only be seen and accessed by the appropriate project manager and development team. In contrast, non-sensitive material can be made completely public, either at the item, folder, or document-library level.

Permissions can even be specified on event items, such as project due dates in an Events list, so you can ensure that only certain members will see specific events. Furthermore, the ILS functionality extends down to returned search results, which will only return objects that map back to the security context of the person doing the search. All of these controls in effect, will trim the user interface to the exclusive user context.

The permission management architecture has been vastly improved in MOSS 2007. Permissions can be set for both SharePoint groups and domain groups, as well as at the individual level. Several groups are rolled out by default, notably Owners (who get full control), Visitors (who get contributor rights), and Members (who get read rights). Individuals or domain groups can be assigned to these default groups or to custom groups you can create and manage at the site collection level, which can have various unique permission levels.

When creating groups based on roles, you could create "developers" and "project managers" groups. You could then assign granular permissions that would, for example, let developers upload relevant coding documentation, and give read and approval permissions to project managers so that they could evaluate and endorse those documents. Group membership remains consistent throughout the site collection so that the created groups could be reusable across a number of different project sites.

6. Integrating Pluggable Single Sign-On Within a typical computing environment, a user can have access to any number of third-party applications, each with its own authentication criteria, which leads to various security issues and password fatigue. The MOSS SSO service helps to alleviate this problem by providing an encrypted back-end cache of users' credentials for mapping to connected line-of-business systems. This can aid in the retrieval of business-critical information to display through MOSS mechanisms such as the Business Data Catalog (BDC) or SharePoint DataView Web Parts (DVWP).

The MOSS SSO provider, like several of the other application architectural features discussed, is pluggable; you can specify a unique SSO provider outside of the one shipped with MOSS (SpsSsoProvider), though only one SSO provider per line-of-business system can be registered at a time within the environment.

7. Information Rights Management (IRM) Protecting information at the client level even when business information is taken offline is a considerable concern for companies that tend to deal with data of a sensitive nature, especially those that have to deal with legislation such as California Senate Bill No. 1386, Sarbanes-Oxley (SOX Compliance), and the Health Insurance Portability and Accountability Act (HIPAA). Server-side Information Rights Management (IRM) integrates with MOSS repositories to provide a common solution built on the Windows Rights Management (WRM) framework. IRM gives you tight control over business data by imposing access restrictions at the document level, regardless of where the document is stored or who tries to open it. A common IRM implementation lets you allow only authorized viewing or printing, but this can be extended to other scenarios such as requiring user credential verification after a certain time period; not allowing users to upload assets that don't take advantage of IRM; a scheduled expiration tag that will drop the restricting policy; and binding to a global organizational IRM permission policy.

The IRM functionality is provided by a protector, and several are installed with MOSS 2007. A protector is an application that manages the encryption process for a file type; typically all of the files you store within MOSS already have protectors built for them. (Microsoft Office system files are natively supported, along with the OpenXML file formats.) Like other providers within MOSS, however, the application architecture is pluggable so you can implement custom protectors for other file types.

The first step in implementing IRM is to ensure you meet all the requirements in your MOSS environment. You'll need to have WRM Services Client installed on every MOSS front-end Web server, and Microsoft Rights Management Services (RMS) must have connectivity to your MOSS front-end Web servers. Then you must specify the RMS server for MOSS to assimilate through SharePoint Central Administration, either by using the default in Active Directory or by specifying the location.

IRM works directly with SharePoint data store structures such as document libraries to maintain permissions. When a user navigates to an IRM-enabled document library and attempts to download a document, MOSS binds the permissions configured for the document library to the document (see Figure 4). As a result, there's a 1:1 mapping between MOSS and document permissions, translating SharePoint roles related to the document into IRM permission levels on the document itself.

Figure 4 Transition of IRM Premissions from a Document Library

Figure 4** Transition of IRM Premissions from a Document Library **(Click the image for a larger view)

The document is encrypted locally for offline protection and maintained in this state until it is uploaded back into the document library. When the document is uploaded, it is maintained in unencrypted form so the SharePoint gatherer can index its content for full-text searching (though no user account will be able to access the content in unencrypted form).

MOSS 2007 provides a number of new features that can help you implement effective security in your organization without adding a lot of management overhead. Even better, the features are very flexible, allowing a lot of customization that ensures users can access just the information they need. See the sidebar "A SQL Server Authentication Provider" for a simple example.

Adam Robert Buenz is a SharePoint Architect and Developer for ARB Security Solutions LLC (sharepointsecurity.com). He focuses on security-centric collaboration environments. Contact him at adam@sharepointsecurity.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.