Single Sign-On in SharePoint: Why I Like Secure Store Service

SharePoint isn't a product created to function alone. Many of its features allow data or the functionalities from external systems to be integrated with SharePoint. It has several APIs to integrate with web services and Business Connectivity Services to integrate data from other sources.

Most organizations have integrated SharePoint with Windows Authentication, so the user doesn’t have to even type credentials to log into SharePoint.

But how about allowing a SharePoint user to sign into another system for another functionality? Is there something like a single sign-on (SSO) that keeps the user from having to enter credentials to the same service again and again?

The SSO feature was introduced with Microsoft Office SharePoint Portal Server 2003 and improved with SharePoint Server 2007. SSO allowed one to retrieve information from external systems such as ERPs and CRMs by just signing in once through SharePoint. SharePoint then stored credentials and prevented prompting again and again in subsequent attempts to access those services.

Secure Store Service was introduced as a replacement to the SSO feature in SharePoint 2010.

One example of how it’s useful is it can allow a company's SharePoint intranet users to access the HR Management System (HRMS) available on another platform.

The administrators of the SharePoint intranet aren’t the same administrators of the HRMS. In that case, the employees of the HR Department require high privileged access over others and should be able to view every employee’s information. Everyone else in any other department is just a member of the HRMS who can only view their own data.

With Secure Store Service the employees of the HR department can be given higher privileges to the HRMS while other users get limited privileges if necessary.

What Happens Behind the Scenes?

Secure Store Service contains a physical database and runs on an application server. This database stores the user names, passwords, and other user-defined fields that are specific to a user or a group.

There can be multiple sets of credentials that are used for multiple back-end systems stored in this database.

The Secure Store Service accepts and decrypts security tokens provided by the applications in order to identify the application ID. These security tokens are issued by the Security Token Service (STS) when an application requests authentication. Once the token is authenticated, the credentials are used to authorize access to the resources.

Applications That Use Secure Store Service

SharePoint has its built-in services that can be supported through Secure Store Service. They are as follows:

Audit Logs

Secure Store Service allows you to maintain audit logs. However, this is disabled by default. Given the possible security threats, this is a good way to track the service’s actions by means of the time they were performed, whether they succeeded, or to track reasons for failure.

Deployment Recommendations

Deployment of a Secure Store Service using the SharePoint interface is similar to the deployment of any other service application. But there are some best practices or recommended guidelines that you need to be aware of.

Also it’s recommended to store the backups in a secure media to reduce the threats of misusing the credentials.

The best thing about Secure Store Service is that it solves the problem of having to sign into many applications and entering different usernames and passwords. This is managed through the SharePoint administration and keeps the credentials stored secure and safe within a secured storage.

With Secure Store Service and Windows Authentication integrated, access to all my organizational applications is just one sign-in to the Windows OS.