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.
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):
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:
There are numerous authentication methods that are supported by SharePoint Server 2010. Through authentication the identity of a user can be validated. Once that occurs the process of authorization will also determine which sites, what types of content, and which of the features available a given user has authority to access. SharePoint Server 2010 can be considered a type of distributed application. There are three tiers that it is divided into which are all important to consider when determining your authentication strategy:
- Application server
- Back end database
- Front end web server
Each of these tiers offers a sub-system and corresponding authentication. A user has to be authorized before they can go from one tier to the next. The provider has control over what levels of access each user has. Those providers offer various software elements that are used to support a specific method of authentication. With SharePoint 2010 you can use a classic mode of authentication or a claims based method. If you are upgrading from Microsoft Office SharePoint Server 2007 Microsoft documentation will recommended you use the classic mode, personally I think it's advisable to just go claims since you can use the identity generation service to generate Windows identities. If you plan to use a forms based authentication or one that is SAML token based you should use the claims based method. This is because the classic mode authentication will only support Windows authentication.
There are several methods of authentication that can be supported by SharePoint Server 2010. As you explore the basics of them you can decide what will work best for your organization. There are three:
This is the standard method of authentication. There are many methods that fall into this particular category. They include:
- Anonymous This allows users to find and access resources from public areas of websites. They don’t have to provide any credentials for authentication to do so.
- Basic This requires a user to have account credentials that have been assigned ala Windows. There is a web browser that is enabled to provide such credentials when someone makes a request. The credentials of users aren’t encrypted but sent across the network as clear-text. Therefore it isn’t recommended for the use of basic authentication to be used on any connection that isn’t secure. Always use SSL encrypting for additional security.
- Digest This type of authentication is very similar in function to basic authentication. However, it offers a much higher level of security with it. The credentials are encrypted as they are sent across a network. The username and password can’t be deciphered along the way. Valid credentials must be given by a user that belong to the secret password string.
- Certificates This offers an exchange of the public key certifications. The use of SSL encryption is used. These certificates are issued by a Certificate Authority. They have to fit the Public Key Infrastructure. This can be done by selecting Windows authentication in the Central Administration area. Once SSL is enabled then the configured certification can be obtained from Certificate Authority.
- NTLM This is a requirement for any network that receives requests for authentication from client computers which don’t support Kerberos authentication. NTLM is secure and it allows for credentials of users to be encrypted before they are transmitted. Windows NT Server, Windows 2003 Server WorkGroup, and Active Directory use NTLM authentication. It may be the default and need to be disabled if you don’t want to use it.
- Negotiate With negotiate authentication for either NTLM or Kerberos, they client has to choose one of them. The default is Kerberos. The client application has to provide a Service Principal Name and a User Principal Name for the account. When such information can’t be offered then NTLM has to be used for authentication.
This type of authentication offers support for management systems that need to make identifications. They aren’t based on Windows because they make it possible to work with identity management systems. These use the MembershipProvider interface. This includes:
- Custom membership providers
- Lightweight Directory Access Protocol
- SQL Database
This based on ASP.NET as well as role provider authentication. With SharePoint 2010 it is only able to be used when claims based authentication is used. Forms Based Authentication can be used to be able to authenticate other user accounts too when connected to Microsoft SQL Server database. You need to register the membership provider in the Web.config file in order to use this type of authentication.
SAML Token Based
This type of authentication is claims based. It is created to support a Windows Identity Foundation. This is a set of .NET framework entities used for the implementation of claims based identity. They include:
- 3rd Party identity providers
- Active Directory Federation Services 2.0
- Windows Live ID
Next, we are going to be talking about user management in this SharePoint security series.