Data content libraries that are trusted with SharePoint Server 2010 use document libraries that contain the PerformancePoint Services data connections. The .PPSDC files are used to manage connections for data sources. This includes Excel Services spreadsheets, OLAP Cubes, Relational databases, and SQL Server databases. The data sources in the Dashboard Designer are defined and stored in a trusted data connection library that SharePoint Server 2010 offers. The trusted data connection library consists of safe documents that belong to that particular library. Users are restricted when it comes to how data source files can be used. They can be read but not modified or deleted. Through PerformancePoint Services a document library is created through a default setting. Administrators do have the ability to manage those data connections on the server. This is accomplished through creating additional data connection libraries. When a user updates data source connections in a document library the information will be shared and updated through Dashboard Designer. There are many trusted lists that can be developed in a trusted SharePoint Server 2010 list. The list or the parent of a list allows the site collection to be trusted during the initial configuration. It can also be done later on through the Central Administrator. These lists include:
With PerformancePoint Services, the security setting for data sources gets stored in each of them. There is a setting that is used to determine if the server is connected with an unattended user account, a customized unattended user account, or an authenticated user. With the SharePoint Server 2010 Secure Store Service (SSS), the ability to securely store data is available. This includes the credentials that are associated with a specific identity or group. The Secure Store Service is available for all of the farms on SharePoint Server 2010. Each of the data sources is configured for a given user to work with the authenticated user credentials. This is referred to as the Unattended Service Account. This is a domain set of credentials that are duplication when a user is connecting to a data source.
The Unattended Service Account is used to manage the data source for the queries. This is done to prevent the PerformancePoint Services from accessing the content database when the query is being executed. With PerformancePoint Services, data is stored and retrieved through Unattended Service Account credentials. This takes place in the Secure Store Service verifications. The server has to keep both the user name and the password of a user so that they can access it. The user name is stored in the PerformancePoint Services and the password is stored in the Secure Store Service. It is important when you create an Unattended Service Account that you make sure it has the right access. There are data sources that that to be in place for it to function properly. Unattended Service Account credentials aren’t cached on a global scale. Instead, they get retrieved from the Secure Store Service as they are needed. When you open a WorkSpace file in Dashboard Designer, the credentials will be cached for the connection. The Unattended Service Account password is retrieved from the Secure Store Service so that it can be the target data source.
With claims based authentication taking place in the SharePoint Server 2010, there is support for many providers. It is used to communicate from the application servers and the front end web servers. PerformancePoint Services allows for the authentication of providers at the same time on one web application. This is limited though to when the Dashboard is used through a web browser. The Dashboard Designer relies on the web application to be extended. It is then configured in order to support the Windows authentication provider.
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.
The security architecture of Microsoft Business Connectivity Services server & client supports a secure environment. They allow for the connection of external content types to the system. There are various options for authorization that are stored. The techniques allow for the security of Microsoft Business Connectivity Services to be cultivated. Part of the security for Microsoft Business Connectivity Services includes the process for authentication of users before they can access external systems. This also requires configurations of permission for the data from an external system. You will find that Microsoft Business Connectivity Service is very flexible. As a result it is able to offer a full range of security methods from the Microsoft Office 2010 as well as the web browser.
It is recommended that you use Secure Sockets Layer (SSL) on all of the channels between computers and end servers. You should be using SSL between servers and external systems anyways.
It is possible to use a web browser to successfully access external data. There are three systems involved in this process:
- The computer a client is logged into
- The web server farm
- The external system
The web browser is going to interact with the external data through the use of a series web parts. The server runtime for front end servers use that data to connect and execute the various operations with external systems. The secure store service stores the credential sets for external systems. Those credentials are used to identify certain individuals or groups. The security token service responds when a request for authentication occurs. They are issued by the security tokens that are part of identity claims based on account information. With Microsoft Business Connectivity Services, there are credentials that have to be passed to claims based authentication aware sub-systems.
External data may be accessed from an office client application. This requires both an external system being used and the client being logged into a client computer. The external data can be retrieved through, for example, the use of either Microsoft Word 2010 or Microsoft SharePoint Workspace. With Outlook 2010, users will be able to access external data including tasks or contacts. With SharePoint Workspace 2010 they can use external lists and use them offline. Microsoft Word 2010 users have the ability to insert the external data into Word documents. With office integration, the runtime is the connection between Microsoft Business Connectivity Services that operate on the client and the supported office applications. When the external data is configured to be used with claims based authentication, the client will interact with the security token service at SharePoint in order for a claims token to be retrieved. On client computers, BDC client runtime will use the data from the Business Data Connectivity Service in order to make the connection. This will also be the method for executing the operations for client access on external systems. The cache will store information from the Business Data Connectivity Service. That is necessary for the secure connection to be made to the external data. When cache is refreshed from the SharePoint farm, the information is updated. The Secure Store Service makes it possible for users to configure security credentials. Microsoft Business Connectivity Services has the ability to pass credentials to a database as well as services that are aware of claims.
The configuration of Microsoft Business Connectivity Services can be configured so that it can pass requests for authentication to external systems. This can be done through either credentials or claims.
- Credentials This is in a format that asks for a name and password. There are external systems that may ask for additional information to validate such credentials such as a PIN.
- Claims External data is passed to claims aware services through Security Assertion Markup Language (SAML) tickets.
In the next BCS post, we will be discussing these details more in depth. In the meantime, since we are talking about authentication, please see the following posts on the site if you need more authentication info (or the SharePoint security category).