Security Considerations for LOB Integration

Identity and access control are common issues faced by developers of Web-based applications. When you integrate a SharePoint application with a back-end line-of-business (LOB) system, you must consider how to convey the user's identity, or other required information, to the Web service. When a SharePoint application issues a request, the LOB system does not have direct access to the identity of the end user of the SharePoint application. The following are three approaches to this challenge:

• Trusted subsystem. The Web service authenticates the identity of the SharePoint application and then delegates access control decisions to the application.
• Single sign-on. The identity of the SharePoint user is mapped to account credentials that are understood by the back-end system. Access control decisions are the responsibility of the Web service or back-end LOB system.
• Trusted façade. The Web service relies on the SharePoint application to forward the identity of the authenticated user to the back-end system.

For more information about how the Partner Portal application gains access to the LOB systems, see Security Decisions.

The Trusted Subsystem

In the trusted subsystem model, the identity of the calling application is trusted by the service. Typically, the calling application's identity is a process identity. For example, it might be the process identity of the SharePoint Web application's Internet Information Services (IIS) application pool. With a trusted subsystem, the Web service never sees the identity of the user who accesses the SharePoint site. Instead, the service trusts the SharePoint application to protect the information and operations that it provides to SharePoint. The trusted subsystem is supported by the Business Data Catalog (BDC) and by Windows Communication Foundation (WCF)–based services.

The advantage of the trusted subsystem is simplicity. It is best suited to situations where no complex authorization decisions that are based on the user's identity must be made. For more information about the trusted subsystem, see Trusted Subsystem.

Trusted Façade

The trusted façade is similar to the trusted subsystem in that the service trusts the identity of the SharePoint application pool. However, the trusted façade also provides the service with an identity that is related to the user who views the information retrieved from the Web service. SharePoint, in this case, acts as a security façade for the Web service. SharePoint may provide the actual identity of the authenticated user, or it may provide a role that is associated with the authenticated user. The service uses this information to apply more specific authorization rules than are possible with the trusted subsystem. In the Partner Portal application, the pricing service receives the identity of the partner company that employs the user. It applies pricing rules that are based on a contract that the partner has established with Contoso. The trusted façade does not store any additional user passwords in the SharePoint tier. For more information, see The Trusted Façade Pattern.

Single Sign-On

The term single sign-on (SSO) has several possible meanings. In SharePoint, SSO is defined as credential mapping. SharePoint SSO maps authenticated SharePoint users to credentials used to access a back-end system. Microsoft Office SharePoint Server 2007 includes an SSO capability that is integrated with the BDC. This SSO capability uses the Windows identity of the authenticated user accessing SharePoint when performing the credential mapping. When using forms-based authentication, a Windows identity is not established for the user accessing SharePoint; therefore, the SSO capability of Microsoft Office SharePoint Server 2007 cannot be used. For more information, see Plan for single sign-on on TechNet and Single Sign-on on MSDN.

Home page on MSDN | Community site