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.

Share

SharePoint 2010 Business Connectivity Services Security Best Practices – Introduction

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).

Share

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.

Share