Security Decisions

The design of the Partner Portal application was strongly affected by security considerations. These considerations can be divided into the following areas:

• Design the logical site architecture and the network topology.
• Authenticate users to establish the end user identities.
• Assign users to zones and roles.
• Secure access to information that is contained within SharePoint.
• Secure access to information that is stored in line-of-business (LOB) systems. For more information, see Integration Decisions.

Designing the Logical Site Architecture and the Network Topology

Many of the decisions about the design of the Partner Portal application's logical site architecture were compromises between security considerations and manageability. The most stringent approach to security is to independently manage every partner in a separate SharePoint farm. This provides complete process, data, and physical isolation for each partner. However, this is a costly solution in terms of physical resources and maintenance. It is only appropriate in situations that require extremely secure environments.

A separate SharePoint Web application is another possibility. This provides process and data isolation when Web applications are assigned to dedicated Internet Information Services (IIS) application pools (otherwise, there is only application domain isolation instead of process isolation). Although this approach is less costly than maintaining separate farms, it is still costly in terms of maintenance and infrastructure costs. For most circumstances, a separate site collection is a good choice as an isolation boundary, especially when both internal and external users read and write information to the site collection.

The collaboration, catalog, and promotion areas each use different techniques to partition and secure information for external users. The following illustration shows this.

Securing functional areas

The decisions about the site architecture determined the possible options for securing data within a site or site collection. Promotions and the catalog are hosted in central site collections because the operational simplicity outweighed any additional security benefits.

The network architecture is a back-to-back perimeter network. For detailed information about the perimeter network, see Understanding Publishing and Content Deployment. The following illustration shows how a perimeter network (also known as DMZ, demilitarized zone, and screened subnet) divides the network that is used by external users from the internal corporate network.

Using a perimeter network

Authenticating Users

Both external users and internal users must be authenticated. The Partner Portal application divides these users into two security areas:

• Internal security. This is the corporate network; it uses Windows Integrated Security to authenticate users.
• External security. This is the perimeter network; it uses forms-based authentication (FBA) to authenticate users.

The external users are only known in the perimeter network; the internal users are known in both the corporate network and the perimeter network. For simplicity, SQL Server is the store for the external users' credentials. In addition, the Partner Portal application uses roles to associate external users with partners. There is one role for each partner company, and all external users who are employees of that company are added to that role.

SharePoint supports zones. Zones enable users who are authenticated with different security mechanisms to access the same SharePoint site. For more information, see Considerations for Extranet Development. The following illustration shows the authentication mechanisms that are used by the Partner Portal application.

Partner Portal authentication mechanisms

Typically, corporations use Windows integrated security for internal users because it provides a high level of security and network administrators already maintain the accounts that are stored in Active Directory. It is possible to use FBA with internal users in addition to the external users. This would allow Contoso employees to access the Partner Portal application outside of the corporate network. However, this places a burden on the Contoso network administrators and requires Contoso employees to remember their credentials for both their Windows accounts and their FBA accounts. To allow their employees external access to the Partner Portal application with only a Windows account requires that Contoso add additional hardware, such as Microsoft's Intelligent Application Gateway.

The following are other alternatives for authenticating external users that were considered:

• Windows integrated security. Windows integrated security requires additional hardware, such as Microsoft's Intelligent Application Gateway, to allow users in the perimeter network to use corporate credentials. In addition to the added hardware costs and operational complexity, external users would either need to be added to the corporate Active Directory or another domain would need to be established for external users in the perimeter network. There are many circumstances where this approach is a good choice, but it was overly complex for the Partner Portal application's business scenario. However, the following are some considerations for using the corporate domain or a dedicated domain:
  • Adding the external users' accounts to the corporate Active Directory adds to the Contoso network administrators' responsibilities. If many external users access the site, there can be an impact on the performance of the corporate Active Directory infrastructure. However, if there is a small set of external users, it may make sense to use the corporate domain and an application gateway.
  • If there are many users, establishing a separate Active Directory domain with an application gateway for external and internal users improves maintainability and scalability. This approach is relevant if there are complex security scenarios. For example, you can also use Active Directory's capabilities to establish trust relationships with other Active Directory forests. This scenario is beyond the scope of this guidance.
• Forms-based authentication using Active Directory Application Mode (ADAM) for Windows Server 2003 or Active Directory Lightweight Directory Services (AD LDS) for Windows Server 2008. These technologies are lightweight directory services that are intended for extranet users. AD LDS and ADAM use FBA, but they replace the SQL Server user store. This approach offers better integration with the SharePoint User Profile store. It also has better user management tools than the SQL Server membership provider. However, it is more difficult to set up and automate their membership stores than SQL Server's. The Partner Portal application uses the SQL Server store in order to fully automate the set up process. However, you should consider using AD LDS and ADAM in a production environment. For more information about using AD LDS and ADAM with SharePoint, see Identity and Access Strategies for SharePoint Products and Technologies on MSDN.

User Profile Integration

The Partner Portal application maps an external user's identity to a partner. Three ways to accomplish this were considered. The first approach that is discussed in the following section, using the SharePoint user profile store, is the one that the Partner Portal application uses. The other two approaches were rejected.

SharePoint User Profile Store

Using the Microsoft Office SharePoint Server user profile store, each user has a profile that can be extended to include custom attributes. The Partner Profile application extends the profile to include an attribute for the partner ID. This is an appropriate choice because there is a built-in user interface (UI) and an API to manipulate and extend the profile information. Also, there are additional capabilities that may prove useful if the application is upgraded in the future. An administrator must manually set up a profile if there is a new user. If either Windows authentication, ADAM, or AD LDS had been used for the credential store, it would have been possible to automatically synchronize a new user to the user profile store and avoid the manual steps. Note that the profile store is not available in Windows SharePoint Services.

The PartnerSiteDirectory class makes it easier to associate a user with a partner. It looks up the partner ID from the user profile store and then looks up the URL of the partner's site collection in the site directory. The Partner Portal application uses this information to redirect users to their partner home page. For more information, see Application Instance Resolution.

Match Role to Partner

The Partner Portal application assigns users to roles that represent their affiliation with a partner. This is done to manage users' permissions to site collections, sites, and list items. Originally, the application iterated through the roles for a user and compared the role name with a mapping table that maintained the partner ID, the partner site URL, and the partner name in a central SharePoint list. This is the equivalent of an in-memory many-to-many join. This operation frequently occurred and could have impacted performance as the number of partners or number of roles grew. For example, if a user belonged to twenty roles, there could be as many as 20 lookups in the list. This was especially true for internal users who typically belong to many roles such as Builtin\users and Builtin\Administrators. This approach is also error-prone because the role name and the central mapping table needed to match. Another option was to use a naming convention for the role to explicitly identify a partner's role, but this approach was also prone to error.

Use a Separate Database or List

Another approach is to store the mapping between the user name and the partner ID in a separate list or database table. This requires a single lookup. This is similar to a user profile store, but it requires custom logic to create the equivalent of an extended attribute. There was no advantage to reproducing a capability that the SharePoint profile store already offers. A separate database or list is a reasonable approach if you use Windows SharePoint Services, which has no user profile store.

Assigning User Zones and Roles

A user's permissions are assigned based upon the user's zone and roles. The Partner Portal application has an intranet zone and an extranet zone. Users are assigned to one of these zones based on where they are authenticated. If a user is authenticated in the corporate Active Directory domain, they belong to the intranet zone. If they authenticated with FBA, they belong to the extranet zone.

Based upon their Windows permissions and group memberships, users who are authenticated in the intranet zone are assigned access permissions to their respective partner sites and the Partner Central site. A group membership is equivalent to an FBA role assignment. or convenience, the installation script for the Partner Portal application creates a Windows group for each partner. It then creates several Windows users and assigns them to these groups. All Windows users have permissions to access the Partner Central site. Anyone who belongs to the Administrator group can access all partner sites, as well as the Partner Central site. In a production environment, IT administrators would determine which groups can access the different sites.

In the current implementation, users are assigned a role that is specific to a partner. This role determines the permissions that grant access to particular sites. In some cases, no extranet users (in other words, no partners), are allowed access to a site or site collection. For example, only intranet users can access the Partner Central site. The following diagram uses two partners, Fabrikam and Litware, to show who can access different sites, based on the zone and the role.

Access permissions based on zone and role

Securing Access to Information Contained Within SharePoint

This section discusses how the Partner Portal application controls access to different types of information. It only discusses extranet users because Contoso employees have unlimited access.

Roles control the information that partners can access. In addition, SharePoint provides its own roles, such as contributor and reader. It is strongly recommended that you use groups or roles to assign permissions. SharePoint also supports permission inheritance within a site hierarchy. You should maintain this wherever possible. The discussion of permission inheritance is beyond the scope of this guidance. For more information, see Plan site security on TechNet.

One of the important decisions about security was to determine the granularity of the permissions. An earlier section of this topic discusses how the site topology impacts the options for security. This is particularly true for ways to secure information. The following sections discuss how the collaboration sites, promotion site, and catalog site are secured.

The Collaboration Sites

Both partners and Contoso employees can read and write information in the collaboration sites. Contoso employees can access all collaboration sites, but partners can only access their own collaboration sites. This protects the privacy of one partner's information from other partners. In this case, permissions are determined at the site collection level. The criteria used is the following:

• Because partners can save information to the site, the Partner Portal application must ensure that the site cannot be compromised because of human or programming errors.

• Because partners can write to the site, and potentially attempt an attack, they can only access their own site collections.

  Note

  You would additionally need to use a unique domain name to access each partner site collection to completely eliminate this risk. The Partner Portal application does not use this approach. For more information, see Considerations for Extranet Development.

• Because permissions are set at the site collection level, the complexity of managing them is minimized.

• Because each site collection has its own site collection administrator, the responsibility of administering the site collections can be delegated to the appropriate Contoso employee. For example, if the partners' account managers are responsible for the site collections, they can manage all the settings, such as security or quotas.

The Promotions Site

There were several ways to manage the promotions site. All of them were compromises between ease of management, flexibility, and performance. Because partners can only read information on the site, security was less of a concern than on the collaboration sites. For more information, see "Techniques for Securing Published Information" in Understanding Publishing and Content Deployment. The possible options were the following:

• The Partner Portal application could assign permissions to each promotion item that is stored in the promotions library page list. This approach is very flexible because any promotion can be assigned to any group of partners. However, promotion permissions must be managed on an item-by-item basis. In addition to the management overhead, filtering on a per-item basis has a performance impact. However, scalability tests showed that performance was adequate for up to several thousand promotions.
• The Partner Portal application could group together partners into different privilege levels, such as gold, silver, and bronze, and assign promotions to a page library for each level. For example, if there are three levels, there are three page libraries. Permissions are assigned to each library. Custom logic that uses configuration data would determine which library to use for a specific partner. This approach makes it simpler to manage permissions and has less impact on performance. The drawback is that it is less flexible, so this option was not used.
• The Partner Portal application could have used content deployment logic that is customized to filter the items in the promotions library while it was still on the authoring site. Only the promotions for a particular partner would be published to a specific page library. The page library would be secured for only that partner. This approach provides optimal performance and flexibility. However, the development and operational costs were too high.

The Catalog Site

Only authenticated extranet users can access the catalog site. The LOB system is responsible for authorization decisions. For more information, see Integration Decisions.

Home page on MSDN | Community site