Have you ever attended a developer conference where a presenter said something like, "Watch, I'll create a sophisticated, full-featured application in
the time it takes you to get a latte"? Instead of getting a latte, you stick around to see the presenter paste onto a design surface hundreds of lines
of code that some poor developer needed a month to write. After a few button clicks, up pops the application, which the presenter walks through in a
carefully scripted way. You look around at the smiling, clapping people. Few of them fully appreciate what those of us in the trenches know: the
development effort that was involved in pulling together that "simple" feat. The next thing you know, you're being asked to create an advanced Business
Connectivity Services (BCS) solution in a few days. Hey, that's just the time it takes to get about 20 lattes, right?
Developing and deploying a working, production-level solution takes longer than a couple days. If you're embarking on your first
advanced BCS solution, you're liable to hit some roadblocks that aren't covered on any presentations about building a create, read, update, and delete
(CRUD)-enabled, database-connected BCS solution in SharePoint Designer (SPD) on a local machine.
This article explores some of the lessons that we had to learn when building advanced BCS code solutions. We hope that these lessons -- along with the
references to some fantastic developer documentation that you'll find within the article -- smooth your development effort. In some cases, we provide
solutions for our lessons learned. In other cases, we point out limitations so that you're aware of them as you design your BCS solutions. Most of our
tips are based on our experience writing .NET Connectivity solutions, but many are applicable to other types of BCS solutions.
Lesson #1: Get a Grip on Your Authentication Approach
There are several areas in which you might struggle with selecting and configuring authentication in BCS to access an external system. Fortunately, the
broad architectural considerations for choosing an authentication approach are the same whether you're connecting to an external system via a custom
web application or from a SharePoint BCS solution. In both cases, start by considering the type of external system, the forms of authentication that it
supports, the form that your connection code will take (i.e., a no-code Business Data Connectivity -- BDC -- Model solution or one backed by managed
code) and the authentication model that you'll use (i.e., trusted subsystem or impersonation/delegation).
You've a tremendous amount to consider when selecting your authentication approach for a particular BCS solution. Thankfully, a lot has been written
about the topic. Start with these resources:
-
To better understand forms of authentication, see the Microsoft article "Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication."
-
Also read the Microsoft article "Plan for Kerberos Authentication (SharePoint Server 2010)"
-
Read about authentication and BCS development in Tom Rizzo, Reza Alirezaei, Paul J. Swider, Scot Hillier, Jeff Fried, and Kenneth Schaefer, Professional SharePoint 2010 Development (Wrox Press, 2010). You can find an excerpt from the chapter about BCS in this MSDN article.
-
For a deeper exploration of BCS development, see Scot Hillier and Brad Stevenson, Professional Business Connectivity Services in SharePoint 2010 (Wrox Press, 2011).
Other great references can help you to understand the various authentication types in BCS:
After you've done your research, consider these salient points (all terminology is covered in detail in one or more of the previous references):
-
Your line of business (LOB) system might be a database, but that doesn't mean you need to create a database-connected BCS solution. You might
decide to write a .NET Connectivity solution rather than writing the solution exclusively inside the BDC Model file, because you want to code your
solution. You might also decide to give the database a front-end Web services layer and choose the LobSystem Wcf connection type.
-
The trusted subsystem model has certain advantages, such as less complexity in implementation, the potential for better authentication
performance via connection pooling, and possibly lower per-user LOB licensing costs. But you also need to be cautious when using this model. A single
account connects to the LOB in this model, so grant the account just enough permission to perform whatever your users need to do to successfully
interact with the LOB. Next, focus on the SharePoint interface and BDC Model permissions for securing access to the LOB, and make certain that users
can't easily log on directly with this privileged account. Finally, if you're going to make your solution available through client applications such as
SharePoint Workspace or Microsoft Outlook, keep in mind that SharePoint UI security (i.e., permissions to access an External List) are irrelevant to
these client applications, which connect directly to the external system.
-
The Secure Store Service is a great way to protect and retrieve credential information. The service removes the poor practice of hard-coding
user account credentials in the BDC Model or in code that backs the model. However, Microsoft makes this important service available only in SharePoint
Server 2010. If you're using SharePoint Foundation 2010, you'll have to find another way to store account credentials securely and have the BDC Model
retrieve the credentials when necessary.
-
To track user access in the trusted subsystem model, you can derive information about users from SharePoint and log their activity in the LOB
system. For example, suppose that you're interacting with a LOB database and you've built a BCS .NET Connectivity solution. You can retrieve properties
about logged-on users from the SPUser object and pass those properties as one or more input parameters to a database stored procedure. The stored
procedure can then separately log users' activity. BCS also supports application-level authentication. With this capability, you can pass user
credential information through to the LOB system, for both secondary authentication and logging purposes.
-
If you're writing a .NET Connectivity Assembly or custom connector assembly and want to use the trusted subsystem model, handle authentication
to the back end in your assembly. The BDC Model includes a reference to the storage location of the credentials, as Listing 1 shows.
-
Authentication from a client such as SharePoint Workspace or Outlook occurs directly from the client application to the LOB system, rather than
through the SharePoint Web Application. ("Business Connectivity Services Security Overview (SharePoint Server 2010)" depicts this approach.) For
example, if your LOB system is a Microsoft SQL Server database, then authentication occurs directly from the client application, over port 1433, to
your database. If your company doesn't allow this access, you either need to convince it to make such access available and protect the access by using
a technology such as IPsec, or consider using a Web Services integration layer as the database front end.