Implementing Pluggable Single Sign-On in MOSS 2007

The Microsoft Single Sign On Service is one of the most misunderstood and overlooked features of SharePoint. Many people think of it as a federated SSO mechanism by which one would gain a "one sign on for several applications" environment whereby all third party apps could be assimilated into the SharePoint environment using an arbitrary sign on mechanism. It's purpose is rather to integrate and connect to third party base systems, such as SAP, Siebel, or other LOB systems.

The power that it provides, when combined with the Business Data Catalog (BDC), is to eliminate the need to build complex identity impersonation in order to retrieve business data out of those third party systems. Using its structure of Enterprise Application Definitions (EAD) one can build several pass through authentication channels by which business data can easily be assimilated and brought to a web front end application through the use of various webparts, whether it is OOB, or a custom developed solution.

The Default Single Sign On Service
Single sign on in SharePoint needs to be called up by using services.msc. Once you get started, the best next step is to start to plan out how you are going to configure the accounts for SSO, which are:

• Configuration account
• Single sign-on administrator
• Single sign-on service
• Enterprise application manager

You can set the exact criteria of what needs to be satisfied for each account. After the accounts are created you will create the encrypted SSO database where we are going to map and store our third party credentials. Once your database is created, and the encryption key is created, you can create your EAD which is going to define the structure. It says exactly how the retrieval of the credentials are going to be handled.

Pluggable SSO Architecture
The Microsoft SSO Service API is independent of the specific authentication mechanisms. The unique feature of the new MOSS SSO is that the Microsoft Single Sign On service is now a pluggable feature, by which you can leverage whichever SSO provider that you would like. It may be a custom one that you have developed or one provided by a third party. When deploying your own or a third party provider, the default SSO provider, SpsSsoProvider, will no longer be used. Because only one SSO service can be used, it is a one or other choice. A MOSS administrator/architect has to decide whether they want to bind the default SSO provider or use one of their own choosing, each which carries its own implications.

© Copyright 2008, Tomas Elfving