Implementing single sign-on (SSO) with MOSS 2007

I needed to build up MOSS 2007 portal that would integrate some of the existing Line Of Business (LOB) applications. We also needed to use SSO, because some of the applications weren't AD-enabled. To use SSO, you can create your own custom web part and connect to the SSO services through there.

Enabling SSO

To enable SSO, you need to start the Microsoft Single Sign-On Service in the Services-tool of Windows. You can also do this on the command-line with "net start ssosrv". Keep in mind the service needs to run under an account that has access to the SQL hosting your SSO database. For demonstrational purposes you can use administrator, otherwise create a dedicated account.

Next, go to MOSS Central Admin at https://localhost:port, where port is whatever you specified when installing MOSS. Select Operations-tab, and navigate to Manage settings for single sign-on. If you get this error:

Failed to connect to Microsoft Single Sign-on Service. To configure, please ensure the service is running.

It means your SSO service is not running. Go and doublecheck the settings on that. Then, select Manage server settings, and fill out the fields. Default values are normally ok for those fields that have been prepopulated. Click OK - the database and settings for your SSO service should now be created.

Configuring applications for SSO

Now that you have SSO running, you need to configure which applications are going to take advantage of it. Go to Manage settings for enterprise application definitions (https://localhost:port/_admin/sso/ManageApps.aspx) and click New Item. Enter a display name, application name and contact email address. The important thing here is to enter an application name that is easy to remember and describes the integrated application, such as "Asp3Tools" or "FinanceApp". Fill out rest of the fields as you see fit.

If you're wondering what the five fields under logon account information are for, you can use those to send a maximum of 5 custom fields to your LOB application upon user authentication. Normally you'd use 2, one for username and one for password. MOSS uses these field names and settings to render the authentication form dynamically for you, when logging into the the LOB application for the first time (via SSO).

Creating skeleton web part for SSO

Now that you've successfully configured SSO for MOSS, it's time to create your web part. I'll provide the basic RenderContents() -method for you that walks through the basic step when using SSO:

        protected override void RenderContents(HtmlTextWriter output)
        {
            string[] rgGetCredentialData = null;

                try
                {

                    Credentials.GetCredentials(1, "AppName", ref rgGetCredentialData);

                    ISsoProvider provider = SsoProviderFactory.GetSsoProvider();
                    SsoCredentials creds = provider.GetCredentials("AppName");
                    creds.Evidence = new System.Security.SecureString[2];

                    try
                    {
                    // your implementation of accessing the LOB app
                    }
                    catch (Exception e)
                    {
                     // catch exceptions

                    }

                }

                catch (SingleSignonException ssoex)
                {
                    if (SSOReturnCodes.SSO_E_CREDS_NOT_FOUND == ssoex.LastErrorCode)
                    {
                        string strSSOLogonFormUrl = SingleSignonLocator.GetCredentialEntryUrl("AppName");
                        output.Write("<a href=" + strSSOLogonFormUrl + ">Click here to save your credentials for the Enterprise Application.</a>");
                    }

                }

You can do a HttpWebRequest to your application, parse the HttpWebResponse and render out your application. The important thing is to use the correct application name (AppName) and catch the SSO_E_CREDS_NOT_FOUND exception for first time users. MOSS will then create the initial authentication page for you, hiding possible other authentication pages you have in your LOB system.

Comments

• Anonymous
  April 15, 2008
  I know this is old, and thanks for the sample, but every sample I find on this topic always leaves is up to the reader to actually use the credentials.  The problem is, the credentials are returned in SecureString types, which don't seem to be usable except in a few .NET situations.  I need the credentials to append to an HTTPS URL.