Security and Identity

  • Article

Business Connectivity Services (BCS) in SharePoint 2010 supports two different security modes for accessing services and databases—PassThrough authentication and RevertToSelf authentication:

  • PassThrough authentication. This uses the credentials of the logged-on user to authenticate to the Web service or the database.
  • RevertToSelf authentication. This uses the credentials of the process running the application to authenticate to the Web service or the database. This is known as a trusted subsystem model.

By default, RevertToSelf authentication is disabled because it poses a potential security risk and is not permitted in hosting environments. If you enable RevertToSelf authentication in the BCS, a malicious developer or designer could point the service endpoint back to SharePoint and use the elevated privileges of the application pool account to circumvent security restrictions.

The Secure Store Service (SSS) is a BCS component that is licensed with SharePoint Server 2010. The SSS provides additional options for authenticating to external services and databases. The SSS maps SharePoint user identities to other external credentials and supports claims-based approaches to authentication. The SSS provides an impersonation model that provides a trusted subsystem approach in a safer way than RevertToSelf authentication, because the SSS does not use the application pool account to access the external service. For more information, see Business Connectivity Services security overview on TechNet. For more information about the security risk of RevertToSelf authentication, see the blog post Authenticating to Your External System.

Meeting security requirements can become more complex when you use the BCD through the runtime APIs or through external lists. The user security token is not available in every context. Without the security token, PassThrough security will not work. Additionally, you will be unable to use the SSS to map the identity of the user to external credentials. The following are two common scenarios in which the user security token is unavailable:

  • Sandboxed solutions. In the sandbox environment, the SPUser object is available, but the security tokens are stripped from the user context.
  • Workflows. Because a workflow runs asynchronously, the security tokens for the user will not be available. You can create an SPUser context by using impersonation in a workflow, but this will not create an identity token for the impersonated account.

In these situations, you need to work around the lack of an identity token and use a trusted subsystem model where all users will use the same account to access the services or database. The External Lists reference implementation demonstrates how to use the SSS with impersonation to access an external list in the sandbox. In this case, the managed account that runs the user code proxy service (SPUCWorkerProcessProxy.exe) is mapped to the external credentials. A similar approach can be used for workflow, although the workflow scenario is a little more complicated. Workflow can run in the context of several processes, including the application pool identity of the Web application hosting the application (W3wp.exe), the timer job identity (Owstimer.exe), or the user code proxy service (SPUCWorkerProcessProxy.exe). Typically, a workflow runs in the context of the content Web application when it is initiated (although under heavy load it may instead be started by the timer service) and in the OWSTimer process if it is triggered by a timed event, such as a timeout or a timer job. It can also run in the sandbox proxy process if the workflow is triggered by an action that is initiated by sandboxed code, such as programmatically adding an item to a list. In order to use BCS in workflow you will need to map each of the managed accounts for these three processes to the single account used to impersonate to the service or database. You can also use RevertToSelf under these circumstances as long as you are aware of and accept the risks described previously. If you use ReverToSelf, then the service or database must accept the credentials of the three managed accounts.