Security features in MOSS 2007

MOSS will often be implemented in an environment with an existing corporate-wide access management solution handling identity management, authentification and authorization. They typically work on a URL level for web applications. MOSS web applications will need to make good use and cooperate well with IAM/IDM solutions. This article looks at security features available in MOSS 2007 explaining the tools available on the portal level to leverage these technologies.

1. Pluggable Authentication Provider
An authentication provider is a component that lets you verify user credentials. The authentication provider is an important security component when setting up Internet-style SharePoint® authentication. MOSS supports the Windows®-based authentication methods available in previous SharePoint versions such as Integrated and Basic authentication, forms-based authentification as well as plain-text userid/pwd. You can add 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, plus a SQL Server™ membership provider and Active Directory® membership provider (available with ASP.NET 2.0). Using the ASP.NET 2.0 membership architecture, it is feasible to create custom providers that use membership stores like 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 hierachy

Note that those services related to crawling and indexing content, must use a Windows account even when using a pluggable provider.

2. Forms-Based Authentication and Web Single Sign-On
Forms-based MOSS authentication is based on ASP.NET 2.0. It 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.

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 useful when setting up more than one entry location for your MOSS 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.


Figure 2 URL Mapping and Zones

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.

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 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).

6. Integrating Pluggable Single Sign-On The MOSS SSO service provides 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.


© Copyright 2007, Tomas Elfving

Yahoo joins OpenID initiative

OpenID is an open SSO-architecture for external sites that makes it unnecessary for site owners to implement their own Identity Management solution. It works pretty much like Microsoft Live (formerly Passport), but with the significant difference that with OpenID there are many "publishers" of login accounts. Any site can start issueing OpenID accounts. For instance, Yahoo announced recently that they are joining the party adding their 248 millions of users to the crowd enabling them to instantly log into all other sites using OpenID. Microsoft and Google has announced that they are backing OpenID, and it appears OpenID has the potantial of becoming the de facto standard for internet SSO during 2008.

Wanna try it out? There is an excellent step-by-step guide at:
http://www.plaxo.com/api/openid_recipe. At http://blog.tomaselfving.com/2007/12/openid-20-released.html there is an list of libraries with APIs encapsulating the OpenID APIs making the implementation even easier.

© Copyright 2007, Tomas Elfving