SharePoint 2010 Business Connectivity Services Security Best Practices – Understanding Security Configuration

The configuration of Microsoft Business Connectivity Services in order to authenticate credentials is very important. A user will offer the requested information for authentication to the external data. There are several methods that can be used to supply such credentials to external data. They can be windows based but they don’t necessarily have to be. Windows authentication can be Windows Challenge & Response (NTLM) or Microsoft Negotiate, or non Windows specific types like Basic, Digest, or Forms Based.

In order for Microsoft Business Connectivity Services to pass the request for credentials, the solution designer has to add authentication information to various types of external content. This includes the authentication mode offering Microsoft Business Connectivity Services the information for processing incoming requests from a user. It allow allows for a map to be implemented which will be passed to the external content system for determining authentication information. This is how the credentials of any user are passed to the external data system. That information can be mapped and then stored in a secure store service before it is passed to the external system.

There are three ways in which such authentication can take place with external content. The external system can be assumed as a web based service. Therefore the Microsoft Business Connectivity Services from the administrative passes can be used to determine the authentication mode. An external content type can be created in either Microsoft Visual Studio 2010 or Microsoft SharePoint Designer. The authentication mode can be created by editing the .XML file which defines the type of external content.

This information will help you to understand the various authentication modes of Microsoft Business Connectivity Services that are offered:

  • Credentials With an external web service this mode relies on Secure Store Service (SSS or trip S) to map the credentials of the user. Those credentials are offered by a service that isn’t Windows based in order to access the external data. This web service can be basic as it will still offer authentication. It is recommended that you use SSL to ensure this mode is secure.
  • PassThrough This passes the credentials of a logged in user to the external system. It requires the credentials of the user to be known to the external system.
  • RdbCredentials With an external database, this is a mode that uses Secure Store Service to map the credentials of a user. They are matched to those credentials supplied by a non Windows based entity. The connection should use SSL or IPS in order to maintain a high level of security while using this mode.
  • RevertToSelf If a web browser is being used to access the external data, this is a mode that has a map of the credentials of the user. This will then be compared to the identity account of the Microsoft Business Connectivity Services account. The credentials are passed through to the external system. If the user is using an Office Client applications then this mode is very similar to the PassThrough mode. This is because it will be operating according to the credentials of the user.
  • WindowsCredentials With this mode a Secure Store Service is used in conjunction with an external database or web service. The credentials of the user are mapped and compared to a set of Windows credentials that are part of the external system.

With Microsoft Business Connectivity Services you will be able to access external data with security tokens. They are incoming and can be passed along to verify security tokens for the external systems. Each security token consists of a particular set of identity claims for a specific user. The use of that information for authentication purposes is, as detailed in multiple places in the site, called claims based authentication.

The process of how the verification and authentication works with claims based authentication is one that offers a high level of security. When a user tries to gain access to any operation on an external list that is set up for claims authentication they will be prompted to enter their information. While this is taking place a request is make to the Secure Token Service (STS) to offer a security token. If the request is granted based on the information that the user submits, the Secure Token Service will issue that security token.

Within that security token that is issued, a set of claims will be included that target a given application. Then the Secure Token Service will return the security token to the client application. The client will pass the token to the Secure Token Service. There the security token will be evaluated using the target application set of identifiers. They are specific in order to return a given set of credentials that will be applied to a particular external system. The client will receive the credentials then pass them to the external system. This allows the user to retrieve, view, and update external data.

The next BCS post we will talk about permissions and how they work in BCS. Baited breathe.


SharePoint Security And Authentication Part 2 – User Management

The proper management of user identity information is very important for any organization deploying SharePoint. SharePoint Server 2010 makes it very easy to process user credentials and identifiers. This can also naturally help you to decide which method of authentication is best for your purposes. User identity information is processed in several ways based on category. They include:

  • Binary ID’s This is where ID’s are created in SharePoint Server 2010. A unique binary ID can be created with the provider name and the user name.
  • Cache This is the process of storing the identity of a user for a period of time. By doing so the process of authentication each time they make a request can be avoided. A cookie that is encrypted will keep the credentials for the user during a given session.
  • Role membership There can be different roles or groups that a given user belongs to. That information is also important during the authorization process. It is used to determine which actions a user is allows to access and perform. Both ASP.NET and Active Directory groups are considers to be the same in SharePoint Server 2010.

SharePoint Server 2010 provides a majority of the tooling or relevant API hooks to handle user accounts and to successfully manage them. The way you select for that management to occur can be influential for your authentication method decision. When users are members of a zone, their accounts can still be managed across all zones with the right permissions being granted. It is important to keep in mind all of these elements of user account management apply with SharePoint Server 2010. It doesn’t matter which is the authentication methods you select.

You can add new users from any zone for any authentication method that you have configured. However, the membership provider and role manager must first be registered with web.config file. SharePoint 2010 resolves the user name against sources:

  • UserInfoList table If a user has already been added to another site they will be found here.
  • Authentication Provider The configuration is for a current zone. That is where SharePoint Server 2010 will check for a membership provider first.
  • All other Authentication Providers If SharePoint Sever 2010 doesn’t find the membership in that current zone, it will look at all of the other authentication providers.

When any account is marked as deleted by the SharePoint Sever 2010 database they will be considered deleted. However, their record isn’t removed. Consider the fancy picture I have made below (select for an automagically larger image):

SharePoint Security Membership Provider

There are many instances when a user account behavior will change within SharePoint Server 2010. It will depend on what type of authentication the provider has in place what the appropriate response is. Understanding how those account tasks can be different with various authentication methods in place is important. They include:

  • Adding new users The user identity is validated using AD DS. SharePoint Server 2010 calls the membership provider and the role manager for verification of that both the user and the roles exist.
  • Changing Logon names When such updates are made they should be immediately recognized by SharePoint Server 2010. However, for this to occur you must delete the old account name and then add a new one.
  • Logging on A user doesn’t have to manually long on to SharePoint sites as long as Kerberos or NTLM is used. The browser also has to be configured for an automated log on to occur. When logging on is required, the user will need to enter a user name and password. This is a standard format for SharePoint Server 2010. Once the log on information is validated a cookie will be issued.

Next we will be talking about claims based authentication. For a refresher, there are about 20 claims articles already written for you review on the site: