Integration Decisions

The Partner Portal application uses Web services to integrate information from several simulated line-of-business (LOB) systems. This makes the data that is available in these systems available to many more people than normal without compromising security. This topic describes two aspects of system integration: security and performance. The different types of information have different security requirements, so the means that were used to integrate with the different systems varies. In some situations, the Partner Portal application uses Microsoft Office SharePoint Server's Business Data Catalog (BDC). In other situations, it uses Windows Communication Foundation (WCF). For more information, see Integrating Line-of-Business Systems.

Securing Integrated Services

The following illustration shows the areas of the Partner Portal application that are integrated with LOB systems and the security mechanisms that are used:

Secure LOB system integration

The BDC supports basic Web service capabilities. WCF supports more advanced Web service capabilities. The Partner Portal application uses two models for security, the trusted subsystem and the trusted façade*.*

Decisions about security were based on the following requirements:

• The LOB system should be protected from unauthorized access.
• It should be impossible to retrieve information that an end user is not authorized to view.
• The communication channel between the client and the server should be secure.

The product catalog is protected by a trusted subsystem. This is a commonly used and simple model for securing integrated services. It requires that the service trusts the identity of the calling application. The calling application identity is typically a process identity. For example, the Partner Portal application uses the process identity of its Internet Information Services (IIS) application pool. The service never sees the identity of the actual users who want to access the LOB information. The service trusts the calling application to properly protect the information and operations it provides. This approach is supported by the BDC.

The advantage of the approach is its simplicity. However, authorization decisions can be complex and difficult or impossible to represent outside of the LOB system. The trusted subsystem is appropriate when authorization decisions are straightforward and do not rely on the actual end user's identity. In the Partner Portal application, the catalog is available to all partners, so the trusted subsystem model is sufficient. As a result, the Partner Portal application can use the BDC to access the catalog. The trusted subsystem is also used for the service that creates sites for particular business events. Only internal calls from the LOB systems access this service, so this is another case where the trusted subsystem model is sufficient.

The pricing and incident management information is more sensitive than the catalog information. In this case, the SharePoint application, acting as the trusted subsystem, is not sufficient to apply pricing rules and to filter incidents. The additional security that is required to access the LOB systems relies on WCF features. Two design approaches were considered. They are the following:

• Trusted façade. This is the approach that the Partner Portal application uses. The approach is similar to the trusted subsystem in that the service trusts the identity of the SharePoint application pool. However, SharePoint also conveys the identity of the end user to the service. An alternative to providing the identity of the end user is to provide an identity that relates to the end user. For example, SharePoint may provide the actual user identity, a role identity for the user, or the identity of the partner for the user. The service uses this additional information to apply more specific authorization rules. In the Partner Portal application, the pricing service receives the partner identity for the user and applies pricing rules according to the contract that Contoso has with that partner. Note that no passwords are stored on the SharePoint tier. For more information about the Trusted Façade pattern, see The Trusted Façade Pattern.

• Single sign-on (SSO). This approach stores credentials that are required to access the Web service (or database) in an SSO store. SSO maps a user identity to those credentials. Microsoft Office SharePoint Server has an SSO capability. However, it requires that a Windows identity be available to map to the stored credentials. The Partner Portal application uses forms-based authentication (FBA), which does not establish a Windows identity for the user. Therefore, the SharePoint implementation of SSO could not be used.

  Another possibility was to create a custom SSO that did not rely on the Windows identity. However, there were concerns about properly storing passwords in the SharePoint tier. The SharePoint implementation of SSO has undergone stringent analysis to ensure that the encryption and retrieval of the information was highly secure. Because it would be difficult to reproduce these efforts, the Partner Portal application used a trusted façade.

Another reason to use WCF may be your company's internal IT policy. Typically, the decision about how services are exposed is made by the system administrators. A custom SharePoint application may need to conform to the policies dictated by those administrators. WCF may be required because it has more security options and greater flexibility than basic Web services. Whenever possible, use the BDC because of its metadata and security management capabilities. WCF is a viable alternative when you require more advanced capabilities.

Performance Considerations

Performance issues are an important consideration when you integrate your application with LOB systems. Performance has several facets. Many LOB systems are not designed with Internet-scale performance capabilities. As you integrate information into externally facing sites, you may be substantially increasing the demand on the system and overwhelming it. This affects your internal users who rely on these systems to perform their jobs. Secondly, a line of business system often applies complex rules to its data. For example, it may perform many calculations to derive a price for a product. These computationally intensive operations may make the systems slow to respond. This can affect external users who use your site to access the information.

To make decisions about how to optimize performance, the Partner Portal application used simulated, slowly responding services for the product catalog and pricing LOB systems.

Generally, it is difficult to anticipate how to optimize your code. For example, scale and stress tests identified a serious performance issue when the Partner Portal application logged to the Universal Logging Service (ULS). This performance issue was fixed with a small code change, but there was no way to know in advance whether there would be any problems.

As a general approach, code optimization should be based on test results. However, some bottlenecks are easy to predict. LOB services are often an obvious case, especially if you also want to minimize the LOB system load. The stress and scale tests of the Partner Portal application identified areas, particularly those areas that involved slowly responding LOB systems, that benefitted from performance optimizations.

The Partner Portal application implements the Repository pattern to access BDC and WCF Web services and to access SharePoint lists. A repository provides a central location to implement optimized data access techniques, such as caching. The BDC cannot cache data that it has retrieved. However, the BDC does retrieve, cache, and pre-compile the metadata that describes the systems it accesses.

When you cache data, you must ensure that no authorization rights are compromised. The Partner Portal application keeps the cached, partner-related pricing content reasonably separate and secure from other partners. Cached data is partitioned by partner and resides on the SharePoint application tier. Because the cache is not secured by permissions, the repository logic had to duplicate the partitioning strategy. An error in the caching logic, or a compromised SharePoint process that allowed the cache to be arbitrarily accessed, would in turn compromise the confidentiality of the pricing information. These were considered acceptable risks for the business scenario that is addressed by the Partner Portal application. However, caching data may be too risky if the information is very sensitive. Also, if authorization rules in the LOB system are very complex, it may be impossible to implement logic within SharePoint to ensure the information is properly protected from unauthorized access. In this case, the information should not be cached.

A Note on Approach to Design

The evolving architecture of the Partner Portal application was related to agile development practices. Initial solutions were the simplest that would satisfy the business requirements. The application's capabilities expanded feature-by-feature. A feature had to be simple enough to be implemented in a single iteration (an iteration was two weeks long). Most of the business logic was unit tested. There were also automated continuous integration tests that ran frequently. This approach allows you to constantly refactor and evolve an application's architecture, while remaining confident of its viability.

Home page on MSDN | Community site