Welcome to the third installment of my SharePoint BCS overview series.

If you wish to see part 2 of the series please click here.

Today I would like to discuss the different methods of authentication with Business Connectivity Services (BCS).  There are actually many ways to perform the authentication.  You can use methods such as connection strings and OData Authentication Providers.  However, if you want to go with a total no-code solution (as discussed in this series) SharePoint Secure Store Service is the way to go.  You can use a non-code solution that doesn’t make use of the Secure Store as well, and I intend to discuss, but you will soon learn why you don’t want to use this in a production environment unless your system is setup a particular way.  This post will cover those different methods of authentication as well as discuss how you can use the SharePoint Secure Store Service to help you make your BCS connections.

 So what is the Secure Store?

You can find the Microsoft definition of the Secure Store here.  Basically, the Secure Store is a service within SharePoint that allows administrators to map a user to another resource that SharePoint accesses.  This could be anything from Excel Services to an external DB to a external system over web services and even to other SharePoint environments.  You can use the secure store to map your credentials for you or even allow you to impersonate another account.  If it sounds similar to a Single Sign-On authority you would be correct.  In fact, prior to SharePoint 2010, the Secure Store was called the SharePoint Single Sign-On feature.

BCS Authentication Without the Secure Store

SharePoint does actually provide two methods of authenticating without using the Secure Store.  However, I would not advise using them in any sort of production environment.  Let me explain.

Pass-Through Authentication

Pass-Through Authentication (listed as User’s Identity in SharePoint Designer)  basically allows you to use your own credentials when accessing external data. SharePoint will first authenticate you itself and then will pass your credentials on to be authenticated by the external system.  And herein lies the major issue with pass-through.  If you are authenticating via NTLM (pre-SP2013) then pass-through will not work for you.  Pass-through and NTLM suffer from what is called the “Double Hop” bug (though some consider it a feature).  Basically you are authenticating from your client to the SharePoint server and then authenticating to the external system (2 hops).  NTLM does not allow this.  Pass-through and Kerberos authentication do not suffer from this UNLESS you are running in a Kerberos and Claims authentication system.  Basically, in this case you are double hopping again.  This is why you usually only want to use pass-through in Dev environments where you are working directly on the SharePoint server.  However, why use different methods than you would in production?  Keep it consistent.

RevertToSelf Authentication

In the RevertToSelf authentication (BDC Identity in Designer) SharePoint uses the account that runs its own BCS service application pool to authenticate to the external system.  Seems pretty straightforward right?  You are only using one account to connect to the external system.  But let’s think about this for a second.  You are using a highly specialized account to authenticate to an external system.  Do you really think that is a good idea?  Microsoft certainly doesn’t.  In fact they think it is such a bad idea that they actually disabled this option by default.  The only way to enable it is with a PowerShell script.  Kinda makes me wonder why they have the option at all.  If you do want to use this in SharePoint Designer, here is the script:

$spBDCService = Get-SPServiceApplication | where {$_ -match "<Name of your BDC Service>"};

$spBDCService. .RevertToSelfAllowed = $true;

$spBDCService.Update();

 

BCS Authentication Using SharePoint Secure Store Service

If the above options are not going to work for your implementation of BCS then you should consider making use of the Secure Store to authenticate to the external systems you wish to gather data from.  Just a note: there are three authentication types within BCS\Secure Store, but two are actually controlled in the back end and appear as one option in SharePoint Designer.

Windows Credentials

Windows Credentials is a secure store based authentication method  for Windows based databases and web services.  If you are connecting to the external data and it is expecting a Windows logon you would use this method when building your BCS connection.  This method takes your account and replaces it with the windows account stored within Secure Store when authenticating to the external data source.  It is called Impersonate Windows Identity in SharePoint Designer.

Credentials

This is very similar to Windows Credentials except it is geared for accessing web services only that are NOT using windows authentication.  Like Windows Credentials, it replaces your login information with the non-Windows account saved within the Secure Store.  It is called Impersonate Custom Identity in SharePoint Designer

RDB Credentials

This is the other half of Credentials authentication.  It is used for connecting to databases secured with non-Windows accounts.  For example, a SQL server with a SQL account instead of a Windows account.  Like Credentials, it is designated as Impersonate Custom Identity in SharePoint Designer.

 

Benefits of Using Secure Store Based Authentication

I would like to finish off by discussing why you would actually want to use a Secure Store based authentication.  One of the main reasons is it is the easiest method for authenticating to external systems without having to write code.  The other reason is security administration.  You will already be securing your access within SharePoint, why add another system to administer that you can’t share authentication with SharePoint.  If you use Secure Store you can setup a single account at the external data source instead of one for each user within SharePoint that requires access to the system.

 

My next post will provide a walk through of creating a Secure Store connection and accessing data from an external source via BCS.

Thanks for reading!