Learning SharePoint: Setting up Secure Store Service (SSS) in SharePoint 2013

setting up Secure Store Service (SSS) in SharePoint 2013

Secure Store Service (SSS) in SharePoint

The Secure Store Service provides a more flexible and reliable solution to have Single Sign-On. It provides a secure storage of user names and passwords for shared resources and the mapping of users to specific access identities. It is commonly used for access to external data for Business Connectivity Services, Excel Service Applications and Visio Service Applications.

Need of Secure Store Service

When you want to use external data, such as data from your other business applications or partner resources) in SharePoint, you can use Business Connectivity Services (BCS) together with Secure Store Service. And, you can manage BCS and Secure Store right in the SharePoint admin centre. The external data source that you can connect to is called a Secure Store Target Application, or just a Target Application. BCS makes it possible for you to set up a connection to the Target Application, and the Secure Store enables you to manage the credentials that are required by the external data source.

Starting the Secure Store Service application

You can start Secure Store Service Application from the Central Administration itself. Please follow these steps

1. Go to Central Admin

2. Click on Manage Service on the Server

3. Start Secure Store Service application

Creating a secure store service application.

1. From the ribbon, select “new” secure service application

2. Supply values for all inputs

Service Name: Enter the name of the Secure Store Service Application. The name entered here will be used in the list of Service Applications displayed in the Manage Service Applications page

Database: Use of the default database server and database name is recommended for most cases. Refer to the administrator's guide for advanced scenarios where specifying database information is required.

Authentication: Use of Windows authentication is strongly recommended. To use SQL authentication, specify the credentials which will be used to connect to the database.

Application Pool: Choose the Application Pool to use for this Service Application. This defines the account and credentials that will be used by this web service.

Security Account: Select a security account for this application pool

Enable Audit: Specifies if auditing should be enabled or disabled. With auditing enabled, all operations on the Secure Store Service Application are logged to the Secure Store database. Audit log will purge after the number of days specified.

Service application creation process is ready. Secure store service application and secure store service proxy are ready.

Next, click on the MySecureStore Service link

If this is the first time the Secure Store Service has been accessed, you will need to Generate New Key from the ribbon.

Creating a Secure Store Service Encryption Key

To generate a new key you must provide a pass phrase. This is used for encrypting information stored in the secure store so it is wise to choose a strong pass phrase.

At this point the Secure Store Service is ready for you to start adding the target applications that you want to store credentials for. For each application you want to access, do the following:

Creating a new Secure Store Target Application

Click on the New target application ribbon button:

Complete the Target Application Settings using the notes below:

Required Fields in Secure Store Target Application Settings

Target Application ID: The target application id is the unique name of the application (and cannot be changed), although the display name can.

Contact e-mail: Self explanatory

Target Application Type: We get to the Target Application Type, the first choice to make is either:

Individual – meaning that each user connecting to SharePoint will be mapped to a unique set of credentials to connect to this target applications; or

Group – meaning that all users connecting to SharePoint in a specific group will be mapped to a shared set of credentials to connect to this target application.

Now we need to decide whether the type should be normal, Ticket, or Restricted.

Ticket – this applies to target applications who support ticket (or “claim”) based authentication.

Restricted – allows you to provide implementation specific additional authentication in the target application;

Normal – this is the more traditional method of providing authentication credentials (user name, password and maybe other information) with each connection.

I am interested at this point in a connection to SQL Server, and a single set of Windows logon credentials for all users is what I’m after, so I choose Group, and click Next.

Next I’m prompted to specify the authentication field names and type. The default of Windows User Name and Windows Password is exactly what I need