Microsoft Office SharePoint Server 2007 provides the Microsoft Single Sign-On (SSO) service for storage and mapping of credentials for use in connecting with third-party or back-end systems.

By examining various scenarios, MOSS SSO proves to be a good fit in SharePoint projects which requires user impersonation into service accounts to enable end users to access secure web services & legacy systems. User Impersonation allows SharePoint to execute a task in an external system or a remote web service using the security context of a specific service account. SSO supports mapping end users credentials into the same or multiple service accounts for each external/back-end system. Even better, SSO can map end users from different domains into the same or multiple service accounts, which means that you can use SSO to implement a fairly complex identity management system out of the box.

One good SSO example is when it is used to resolve the "Double-Hop" issue which is an NTLM authentication issue where credentials used to access resources on a 2^nd tier server (IIS Server) can not be used from that server in the request of resources in a 3rd tier server (a server other than the IIS server) due to delegation restrictions inherent to the NTLM authentication system used by Microsoft Windows. This issue is common in InfoPath forms which consume external web services. As MOSS SSO Service lives in the 2^nd tier (IIS Server), it can impersonate end users using a predefined service account credentials to enable access to the 3^rd tier resources (external web services).

SharePoint SSO also allows customization & extendibility.  It enables developers to create their own custom SSO provider to replace the standard SSO provider in SharePoint 2007. Developers can customize how users are authenticated or control the user mapping; this can be done by building a class that implements the Microsoft.SharePoint.Portal.SingleSignon.ISsoProvider interface.

Depends on what are you using  Single Sign-On for, you may also consider extending  the standard SSO Provider rather than creating a new custom SSO provider, so that developers have to only customize the methods they want and benefit from what is available in the built-in SSO Provider.

Before you start extending the SSO Provider, you will need to configure your MOSS SSO.  A good article that describes how to do that can be found at this link.

 After you have configured MOSS SSO, you can use the following 2 steps to create your own SSO provider:

1) Implement a custom SSO Provider class that inherits from the standard SSO Provider "SpsSsoProvider" as explained in the following code example. Notice that MyCustomSSOProvider class customises "GetCredentials" method to check if the user is active in a legacy system before mapping the user into the stored service account.

 

namespace EMCConsulting.SSO
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using System.Reflection;
    using System.Threading;
    using Microsoft.SharePoint.Portal.SingleSignon;

    /// 
    /// MyCustomSSOProvider. Custom SSO Provider which inherits 
    /// the standard MOSS SSO Provider
    /// 
    public class MyCustomSSOProvider : SpsSsoProvider
    {
        #region ISsoProvider Members

        /// 
        /// Gets the mapping credentials for the current user
        /// 
        /// The SSO application definition Id
        /// Service Account SsoCredentials object
        /// Because GetCredentials is not overridable, I hide its 
        /// implementation in the base class using the "new" keyword
        public new SsoCredentials GetCredentials(string AppID)
        {
            SsoCredentials creds = new SsoCredentials();

            try
            {
                // Do further authentication checks for the current user
                // before mapping the user into the stored service account
                if (IsUserActiveInOurLegacySystem(Thread.CurrentPrincipal.Identity.Name))
                {
                    creds = base.GetCredentials(AppID);
                }
            }
            catch (SingleSignonException ex)
            {
                System.Diagnostics.EventLog.WriteEntry(
                  "MyCustomSSOProvider", ex.ToString());
            }
            catch (Exception ex)
            {
                System.Diagnostics.EventLog.WriteEntry(
                  "MyCustomSSOProvider",ex.ToString());
            }

            return creds;
        }

        #endregion

        #region Private Methods

        private bool IsUserActiveInOurLegacySystem(string currentUser)
        {
            // Do any further checks in the current user
            return true;
        }

        #endregion
    }
}

          

2) Install the Custom SSO Provider with SharePoint, SharePoint allows only one SSO Provider to be active at the given time.

To install the MyCustomSSOProvider implemented in the example above, you must do the following:

A. Register it in the global assembly cache

B. Register it with the ProviderAdmin console application (By default, located in C:\Program Files\Microsoft Office Servers\12.0\Bin). Notice that you must register the new SSO provider with each computer in case you have a server farm environment.

C:\Program Files\Microsoft Office Servers\12.0\Bin>
Microsoft.SharePoint.Portal.SingleSignon.ProviderAdmin.exe
"EMCConsulting.SSO, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ed92a9d1a761f390"
"EMCConsulting.SSO.MyCustomSSOProvider"

You can also remove the installed custom SSO provider and restore the standard SSO provider by executing the following command:

C:\Program Files\Microsoft Office Servers\12.0\Bin>
Microsoft.SharePoint.Portal.SingleSignon.ProviderAdmin.exe /u

Happy Coding!

Mohammad