Authenticating to Your External System
When getting acquainted with BCS, most new users work against an unsecured backend. This means they can ignore the issue of authentication and focus on the fun stuff, like making external lists and searching external content. But real world external systems have all kinds of sensitive data: payrolls, inventories, credit card numbers, and more. The permissions built into BCS can help out, but since users could simply connect directly to the external system without using BCS, the external system needs to have its own authentication turned on too.
I’m Adam Outcalt, a Software Development Engineer for BCS, and in this article we’ll look at the authentication modes supported by BCS and how you can use them to make sure you stay in control of your data.
Authentication Modes
Now that we know why backend authentication is important, let’s look at the modes available in BCS. The names are different depending on where you see them, and are summarized in the table below.
Name |
SPD |
Model |
Pass Through |
User’s Identity |
PassThrough |
SSO (Windows) |
Impersonated Custom/Windows Identity |
RdbCredentials / WindowsCredentials |
Revert To Self |
BDC Identity[1] |
RevertToSelf |
Pass Through
Pass Through means to authenticate to the external system with the same credentials that were used to authenticate to SharePoint. Pass Through will not function by default in NTLM, because NTLM does not allow for delegation of identity; if your backend does not allow anonymous logon, you’ll get an error like this one in your external list:
The query against the database caused an error.
And ones like these in the server logs:
The query against the database for LobSystem 'AdventureWorks', LobSystemInstance ' AdventureWorks', MethodInstance 'Read List', caused an error : Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. A severe error occurred on the current command. The results, if any, should be discarded.
The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Negotiate,NTLM'
This is because your identity made two hops to get to the external system: one from the client machine to the server, and the other from the server to the external system. Since NTLM did not allow for delegating identity, the request to the backend was anonymous. You can get around this problem by using a system like Kerberos that allows for constrained delegation of credentials. (This article can help you learn more about configuring Kerberos with SharePoint.)
![clip_image001[6]](https://msdntnarchive.blob.core.windows.net/media/TNBlogsFS/BlogFileStorage/blogs_msdn/bcs/WindowsLiveWriter/AuthenticatingtoYourExternalSystem_F225/clip_image001%5B6%5D.png "clip_image001[6]")
Even without Kerberos, Pass Through is still useful for simple testing during development; if you are working from a development server, in some configurations (like using a browser on the server to connect to a database, or using a browser off-box to connect to a database on the same machine as SharePoint), the whole trip will only be a single hop – just be sure to test it with a proper configuration before deploying!
Pass Through can also work with claims; more info on this soon!
Secure Store
The basic idea of using Secure Store for BCS authentication is to avoid the double hop problem of Pass Through by storing credentials in SharePoint. Since we can use the credentials in Secure Store to sign you in again on the server, the double hop becomes two single hops.
The other great thing about Secure Store is that you don’t have to sign in users as themselves; you can map them to a service account instead, preferably one that has rights to absolutely nothing except the external system you want to interact with. This means that you don’t have to give the actual users permissions to the backend at all! As long as the users don’t know the password for the service account, they will only be able to access the external system through external lists and other web parts, and you can use this to restrict the sort of operations they can perform.
Mapping to a service account also leads to large performance improvements, since all the connections are pooled for the single logon. The disadvantage is that the external system won’t be able to record who executed a particular transaction – you can solve this problem with secondary authentication filters, which we’ll discuss later in this article.
Revert To Self
Revert To Self is a popular authentication mechanism carried over from the last release of SharePoint. Using Revert To Self means to connect to the external system as the IIS application pool that is servicing the request. In external lists, this means the application pool for the content page; for timed workflows it means the process that runs the workflow; and so on. Because the application pool of a SharePoint farm is a very highly privileged account, it is not a recommended security practice to use Revert To Self in deployment environments.
Even if you don’t use the application pool for anything besides SharePoint, the account still has enough privileges to subvert SharePoint itself (for example, being an application pool, it has privileges to write configuration information about the farm). This means that anybody able to create or edit Revert To Self systems in BDC has at least enough power to make themselves administrators of SharePoint. This was fine in the last release of SharePoint, because the only people who could create or edit BDC LOB Systems were administrators anyways. This release, though, there are lower ranks of users like tenant administrators and SharePoint Designers (SPD) who have this power.
To keep SPD users from being able to elevate themselves to administrators, Revert To Self is disabled by default, and if you try to import a model that uses Revert To Self, you’ll get an error message like this one:
Application definition import failed. The following error occurred: The metadata object that has Name 'MyWebService' has a Property with name 'WebServiceAuthenticationMode' and value 'RevertToSelf'. This value indicates that the runtime should revert to the identity of the application pool, but reverting to the application pool must be explicitly enabled for the service application by a farm administrator.
You should think very carefully about the structure of your organization before enabling Revert To Self on a production server. It is almost always preferable to set up Secure Store instead; having a legacy model that uses Revert To Self is in general not a good enough justification to turn Revert To Self on. You should only turn it on if ALL of these are true:
- You are on a SKU like SharePoint 2010 Foundation that does not have SecureStore
- You do not have the resources to create a custom SecureStore
- You completely trust all of your site designers, as though they were SharePoint administrators
- You have locked down the use of the application pool account account, so that if it were subverted by a malicious site designer, your losses would be limited to the SharePoint farm and the external systems.
Don’t do it just because it’s convenient! Of course, this is about production servers. If you are working on a throwaway development farm, you can still turn it on for testing purposes, but be sure to test it in a real configuration before deploying.
In any case, if you have a good reason to use Revert To Self, here’s how to enable it from SharePoint 2010 Management Shell (what’s that?). You must be on the farm that provides the BDC service application to enable Revert To Self; if you consume it from a federated farm, the administrators of the federated farm would need to enable it for you.
$apps = Get-SPServiceApplication
$bcs = #Do something appropriate here to get the app that is
#BCS. If you’re doing this by hand, just type $apps and look
#for the Business Data one, then index into it like $apps[i].
#If you’re doing it for automation, filter by
#$_.GetType.FullName (not $_.TypeName, which is localized).
$bcs.RevertToSelfAllowed = $true
This is an on/off switch that controls whether new models can be created/imported that utilize Revert To Self. If you later choose to turn it back off, that only prevents the creation of new models, but does not prevent you from executing methods in existing models that use Revert To Self; to solve this problem, you should delete all models in the catalog when you turn it back off. Don’t be tempted to turn Revert To Self on, import a model, and turn it back off, since somebody could edit the model to do malicious things once it exists.
As a final note, if you’re playing with a test copy of SharePoint and set RevertToSelfAllowed to true for the sake of science, there are some scenarios (like tenant sites) where we will detect that there is no legitimate reason for using it, and we’ll ignore the property anyways. Don’t rely on this as a safety net for when it’s okay to enable Revert To Self.
Filters for Secondary Authentication
Like we dicussed earlier, you can improve performance of BCS calls by using Secure Store with a service account to have all of the connections run as the same user. This is great, but now the external system doesn’t know who the caller is! You can solve this problem by using filters, which will insert the relevant data for you. The best filter for this scenario is the UserContextFilter which will insert a unique, human-readable identifier for the current user.
Some companies set up their SharePoint and external systems inside a tightly controlled subdomain that is fully secure. In these cases, filters can be used as a primary authentication mechanism, turning off connection level security for a performance improvement. In this configuration, authentication can be handled by using the Username and Password filters, which will use Secure Store to fill in the correct data before making the method call. SsoTicketFilters can also be used to insert a Secure Store ticket, which is similar to a claim.
Keep in mind that filters are only as secure as the connection to the external system. If a user can connect directly to the external system (such as by offlining a virtual list), he can change the values of the filters to make it appear he is a different user, with or without Secure Store. To use filters as a security measure, only rely on them when they come from a trusted source like the SharePoint server.
Anonymous Authentication
It is possible to configure a SharePoint site to be accessed anonymously. The most common scenario for this is a read-only external list on a public-facing site, so that users can see the list without needing to sign in. In this case, Pass Through will go to the external system as anonymous, and Secure Store will not be usable (you cannot map “anonymous” to a service account in Secure Store). In this situation, you must allow anonymous access to the backend, so be sure to give only read permissions.
Other Security Considerations
But what about those rights you can configure in BCS? The BCS execute right is used to filter who is able to make an external system call through BCS. In some systems, this is meaningful security; eg., if you have Secure Store set up to map users to a service account, and only the service account is able to modify the backend. If you configure it so that normal SharePoint users don’t have execute permissions and don’t know the password of the service account, the external system will be secure.
Notice, though, how easily this degenerates into an insecure setup. If instead the backend allowed anybody to log in, all the carefully-crafted BCS permissions in the world won’t matter, since the users could directly connect to the external system. (Incidentally, don’t rely on security through obscurity, expecting BCS to keep the address of your external system a secret. For example, anybody who can access an external list that has been offlined, or edit a model in SPD, can learn the URL directly; others can learn it by monitoring network traffic, etc.)
Another easy way end up insecure is to expect that just having Secure Store makes you safe, since ordinary users can’t directly invoke it. Anybody who makes web parts with the SecureStorePermission on your SharePoint server can make one that invokes Secure Store and connects to your external system, or makes connections as the application pool.
Recap
As we’ve seen, correctly setting up authentication to your external system is crucial to keeping your data secure. Secure Store is the most desirable authentication mode, and Revert To Self should only be used in very specialized corner cases. Pass Through strikes a balance somewhere in the middle, depending on your configuration. Secondary authentication filters can be used in conjunction with Secure Store to improve performance.
I hope this article has helped you pick the configuration that’s right for you and your company’s security policies.
-Adam Outcalt, Software Development Engineer
[1] You can’t discover an LOB with this setting (it wouldn’t make sense), but you can change a LOB’s properties to this.