PerformancePoint Security Best Practices In SharePoint 2010 Authentication, Trusted Locations

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:

  • Filters
  • KPI’s
  • Reports
  • Scorecards

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.


Secure Store Service Best Practices In SharePoint 2010

With Microsoft SharePoint Server 2010 the legacy single sign on feature has been replaced. The Secure Store Service (SSS) has been introduced to offer a claims authorization service. This includes a database that is secure for the use of storing credentials associated with any given application identification.

The application identification can be used to authorize access to external data sources. As you learn about the Secure Store Service, how to prepare it, ID’s, mapping, and claims authentication you will quickly realize what a valuable access it happens to be.

 The Secure Store Service is a type of service that allows for authorization to be conducted on the application server in the SharePoint server farm. This provides a database that is used for credentials to be securely stored though the use of password and identity verification of the user. With SharePoint Server 2010 there is the use of the Secure Store Database. It is used to store and to retrieve credentials for accessing external data sources. The Secure Store Service also provides support for the storage of credentials to multiple back end systems. They can have multiple application ID’s too.

 There are some very important issues that you need to take into consideration when you are preparing for the Secure Storage Service to be implemented. You need to run the Secure Store Service in an application that isn’t being used for any other services, this is both a logical and technical restraint. You need to create the Secure Store Service database on an application that is running SQL server. You don’t want to use the same SQL server application though that is being used for your content database. Prior to generating your new key for encrypting, you need to back up the Secure Store Service database. It is recommended that you do so right after it is created too. Each time you create a new key, you want those credentials to be encrypted again with it. You never want the key refresh to fail as this can result in the credentials failing to allow you to have access. Never store the backup media to the encrypted key in the same location as the backup for the Secure Store Service database. This is an additional layer of protection that can prevent your database information from being compromised by an unauthorized user.

 There are application ID’s for each of the Secure Storage Service entries. They are used to retrieve a given set of credentials from the Secure Store Database. Each of the application ID’s can be set up with given permissions that have to be applied. This will restrict the users or groups that are able to successfully access those credentials stored within the application ID. The application can be used to retrieve a given data source. These application ID’s are also used to map out users within given sets of credentials. It can be set up for mapping to occur both for individuals and for groups. With individual mapping each user has their own set of credentials that are different from others. If there is a group then each user that belongs to that group gets mapped with the same credentials.

 There are individual mappings and group mapping to consider. The Secure Store Service supports both of them and maintains credentials for the application ID’s of the resources that are stored in the Secure Store database. With individual credentials of an application, they are retrieved from the application ID. This type of individual mapping is beneficial when a user logs in using information to personally identify themselves. With group mapping there is a layer of security in place that will check the credentials of the group. It will look for multiple domain users and compare them to a given set of credentials that are in place to identify a application ID which is stored in the Secure Store database. It is easier to maintain group mapping versus individual mappings so keep that in mind if you are after optimal performance.

Claims authentication can occur within Secure Store Service. It is able to accept security tokens and to decipher the encrypted application ID. From there it is able to look up the information for verification of authentication. With SharePoint Server Security Token Service, a token is created in response to a request for authentication. The Secure Store Service deciphers the token so that it can successfully read the value of the application ID. The Secure Store Service uses that application ID in order to successfully retrieve the credentials that are in the Secure Store database. These credentials will be used to authorize access to the various resources offered.


SharePoint 2010 Business Connectivity Services Security Best Practices – Permissions And Authorization

The various permissions associated with Microsoft Business Connectivity services are all associated in various ways. This can be with an individual account, a group account, or a claim with several different levels of permission in place for a given object within a metadata store. It is crucial that the settings for permission for any object in Microsoft Business Connectivity Services is done correctly. This will allow it to create solutions for securing access to external data. The strategy for permissions needs to be carefully evaluated during the planning stages. It is a good idea to provide specific permissions to each user or each group. The goal is to offer credentials that provide only the privileges that are necessary in order for them to perform necessary tasks. The overall security strategy you have is important. Don’t overlook the value of it for your external systems too. The way in which you will set permissions up can vary by business and implementation purpose. Take various security models and features into consideration before you decide how you will proceed with it.

There is a metadata store that is inside of each instance in the Business Data Connectivity Service. This includes the external content types, methods, external systems, and all the models which have been defined for the purpose of that store. There is a hierarchy among those objects used to determine which of them can be used to gain permission to other objects. Each of the objects will gain permission from parent objects. The idea is to set up the permissions so that all of the settings for children of a given item can be replaced by those of the parent object. There are four permission levels that may be set for the metadata store: Execute, Set permissions, Edit, and Selectable in clients.
There are many objects that have to be taken into consideration to determine what type of permissions to set. As you go through them you will be able to determine what is best for you to use.

External Content Type – The external content type offers a collection of metadata that can be reused. This metadata defines one set of data from others that are used with external systems. All of the connectivity information that is related to certain groups of data is maintained here. There aren’t any edit permissions with the external content type. However, the setting can be used for permissions linking to child objects in the metadata catalog. The user is able to execute permissions and create external lists in client permissions. The user is able to set permissions with external content type.

External System – The external system is a metadata type of support for sources of data. They can be modeled like a database, web service, or .NET for connecting purposes. The user is able to edit the external system so that the permissions are accessible though SharePoint Designer. There aren’t any execute permissions or selectable permissions with the external system. However, the settings can be used to gain permissions to child objects that are part of the metadata catalog. The user is able to set permissions on the external system.

Metadata Store – This is the collection of .XML files that are stored in the Business Data Connectivity Service. Each of them contain definitions for external systems, external content types, and all the models. The user is able to create new external systems if they wish. There isn’t an execute permissions with the Metadata Store. However, it can be used to create permissions in child objects according to what is listed in the metadata catalog. There aren’t any selectable clients in permissions either. Yet the settings can be used to create permissions along with child objects in the metadata catalog as well. The user has the ability to set permissions on any object within the Metadata Store.

Method – The method is the type of operation relating to an external content type. The user is able to edit the method being used. There aren’t any execute permissions or selectable in clients permissions available in method. However, the user is able to set permissions for it.

Method Instance – The method instance is a description for how to use a given method with a given set of default values is in place. The user can edit the method instance. They can also use execute permissions. However, there aren’t any selectable in client’s permissions. The user is able to set permissions on the method instance.

Model – The model is a .XML file that has sets of descriptions for one or more of the external content types. It also contains descriptions for their external systems that relate to it. All of the information that is specific to a given environment including authentication is stored here. The user can edit the model file if they wish to do so. There aren’t any execute permissions or selectable permissions for models. However, the user can change and set the permissions in the models as they see fit to do so.

There are more than just general capabilities when it comes to setting the permissions that were described earlier. There are special permissions to consider with the Business Data Connectivity Service as well:

  • Application Pool Accounts This pertains to front end servers and they must have the same permissions as Farm Administrators to the Business Data Connectivity Service. This is necessary in order to create deployment that will be based on Microsoft Business Connectivity Services.
  • Farm Administration They will have full permission to access the Business Data Connectivity Service. This is so they are able to properly maintain, fix, and update the service as needed. The Farm Administration doesn’t have the ability to execute permissions though on any object in the Metadata Store.
  • SharePoint Designer Users They will be given a series of permissions for the entire Metadata Store. This includes the ability to edit, execute, and select clients. They aren’t given permission though to set permissions. It is possible to limit the permissions of the SharePoint Designer to a subset for the Metadata Store as well.
  • Windows PowerShell The users are Farm Administrators and they have the ability to operate various commands with the Business Data Connectivity Service.

There are plenty of common tasks that take place in the Business Data Connectivity Service. Here are the permissions that are necessary in order to be able to perform them:

  • Adding a new object in the Metadata Store The user has to edit permissions on the parent metadata object.
  • Adding external content type to a model the user has to edit permissions on the model.
  • Deleting an object from the Metadata Store The user has to edit permissions on that object. This includes the parent and all of the child objects.
  • Deploying a package This is generated by the application pool account used by the front end server. This has to have full permissions to the Business Data Connectivity Service for this task to be completed.
  • Exporting models The user has to edit permissions on the model and for the external systems that are within that model.
  • Importing models The user has to edit permissions for the Metadata Store. The user that imported it will typically be the one given permissions for such roles to take place.
  • Setting permissions on the Metadata Store To initially get the Business Data Connectivity Services permissions have to be set. They are empty after first and the Farm Administration has to go to the Metadata Store and install those initial permissions.