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 3 – Claims Authentication Design And Services

With SharePoint Server 2010, claims based authentication and classic mode authentication are both supported. Claims based authentication is part of the Microsoft Windows Identity Foundation (WIF). This is a set of .NET classes that allow for claims to be processed with WS Federation authentication. WS-Federation is a type of protocol for authentication that builds on the WS-Security and WS-Trust. It supports a token based authentication structures so that a web application required to offer security tokens can be accessed. With SharePoint Server 2010, you have the chose if you want to use claims based or classic mode authentication each time you create a new web applications. With classic mode authentication you will have the Integrated Windows model that was supported by SharePoint Server 2007. There aren’t any claims changes that are performed so the new claims authentication features can’t be supported. When you choose to use classic mode authentication you will be able to implement all of the method that were supported by SharePoint Server 2007. You are also under this pretense going to be limited to the use of one form of authentication for each of the zones. With claims based authentication for SharePoint Server 2010, you will be able to use authentication for the entire span of Windows based systems. You can also use it across those systems that aren’t Windows based as well. With claims based authentication, you will support the delegation of a user identity between applications. This allows you to implement multiple forms for authentication in a particular zone.

It is important to understand the basic components of claims based authentication. Yeah this has been covered a lot on the site but its critical. A security token is the main component of claims based authentication. This security token consists of sets of identities about a user. This can include their user name, the role they have in the organization, an employee ID that has been assigned, and other variables that an organization uses. The values of these identities are assigned a value that is in a text string. The security tokens are created and also managed by a Security Token Service (STS). Policies are implemented based on the decisions of the organization about how those security tokens can be distributed based on authentication of a user that proves they are authorized.

With a claims based application, WIF is able to create a WS Federation authentication request. WS-Federation is an authentication protocol used to build on what WS-Security and WS-Trust have instilled. WS-Federation supports the overall architecture of this token based authentication. This process allows the web application to require a security token before the authentication process can be completed. Without it, a user will never be able to gain access to the resources. Once the Windows user identity is created it is converted to WindowsIdentity by SharePoint Server 2010. From there it is converted to ClaimsIdentity. The object is then able to use used for the purpose of creating a token.

A Security Token Service takes on the role of responding when requests for authentication are made. The security tokens for identity claims are evaluated based on the user account information that has been stored in an Active Directory Domain Service, arbitrary LDAP Store, or an SQL Database. Each security token has content in it that is determined by the types of requirements for authentication requests that have been determined with the Security Token Service and the SharePoint web application. The claim rules are also the policies that will be used as requirements to be met before a web application can be accessible. There are two function of a Security Token Service. It can serve as a local Identity Provider Security Token Service when they are in the same web application as the SharePoint farm. When they are located in different farms though the function of the Security Token Service is that of Relying Party Security Token Service.

With Identity Provider Security Token Service, the identity providers and the web application have the same farm through SharePoint. They will provide tokens to users that have been authenticated and that are in the same local stores.

With Relying Party Security Token Service, the partner identity provider has a trust relationship with the Identity Providers Security Token Service as well as the web application. These entities can be located in different SharePoint farms. This is a trusted relationship that allows the Relying Party Security Token Service to authorize an external user even if the credentials of that user aren’t locally stored. As long as the Identity Providers Security Token Service of a user is able to issue a valid security token that process will take place without any problems. It is possible for a new token to be issued that is able to validate a web application that may be local to the Relying Party Security Token Service but external to the user.

There are two types of claims based authentication topologies that can take place. One of them is a single farm that requires the use of a Security Token Service that is local. There is also the use of a multiple farm topology that uses both a local Security Token Service and a Relying Party Security Token Service.

Assume an incoming request for authentication that comes from an external user. The credentials are going to be accessible by Security Token Services. The request is then submitted and processed by the local Security Token Service. In order for that to happen, the policy for a given web application must create a token. This is going to be based on the identity of the user and the values of the store. A valid token will be returned to the user and then it can be submitted to the web application once a cookie has been returned to the user.

When a user has credentials that aren’t directly accessible by a local Security Token Service, the web application is going to respond to the authentication request from an redirect to a partner Security Token Service. This request is submitted due to the trust relationship that exists. An Identity Provider Security Token Service is created for the user and then submitted to the local Security Token Service. There it is deciphered for the token and then it is returned to the external user. Then the web application will return a cookie to the user.

In order to successfully complete crawls of content for any web application, it is important to understand how the authentication works for it. The indexing element of the search server is what is referred to as the crawler. Successfully configuring the authentication for web applications ensures that the content in those applications has been crawled. A farm administrator will create a web application that uses all of the default settings. The zone for that default is created through a web application using NTLM. The farm administrator can change the method of authentication for the default zone through any of the SharePoint Server 2010 supported methods. The farm administrator also have the ability to extend any web application several times so that additional zones can be offered. As many as five zones can be offered for any particular web application. These zone are configured through the use of any of the SharePoint Server 2010 authentication methods. The planning zones for a given web application has to be considered in order for the access zones to be displayed in an orderly fashion. This process will occur then an attempt to authenticate is completed. The order is very important so that the crawler is able to get through the zones that are configured. If the crawler can’t gain access through one of the zones, the authentication will fail and then there is going to be content on the web application that isn’t crawled. It is a good idea to have NTLM zoning configured early in the order. It should be before authentication for basic, digest, or Kerberos.

The zones that the crawler will access will occur in this order:

  1. Default zone
  2. Intranet zone
  3. Internet zone
  4. Custom zone
  5. Extranet zone

These are the actions that will be associated with the call out process:

  1. Crawler uses the default zone to attempt authentication. The crawler will always attempt to use the default zone first for any particular web application.
  2. If a zone has been configured for NTLM then the crawler will move on to try to authenticate that in the next phase.
  3. If a zone has been configured for basic, digest, or Kerberos authentication then the crawler may fail and not continue to crawl all of the remaining content within a web application.
  4. If there aren’t more zones in the order the authentication may fail.
  5. The crawler will them attempt to complete the authentication by moving into the next zone in that order. You must create at least one more zone and configure it use NTLM authentication.

Next in this SharePoint security series, the last post in it, we will be talking about how to build the security design, and what SharePoint security best practices should be implemented in particular environments.