Home > .net 1.1, c#, Microsoft, SharePoint 2003 > Creating Single Sign-on Web Parts in SharePoint 2003

Creating Single Sign-on Web Parts in SharePoint 2003

January 28, 2008

Download Code (SharePoint 2003, .NET 1.1)

In our environment, we have several web applications that use forms authentication.  We wanted to, however, move past that on our SharePoint portal and pass that information directly if the user is already authenticated.  We assume that they’re authenticated if they’re on the Portal and authorized if they can see the link (controlled by audiences which are controlled by AD groups).

So, from there, we needed a general web part that we could supply an image (for the button), a bit of descriptor text, a link to the application, and a general format for passing the GUID (we use GUIDs rather than sAMAccountName, you could alter the code for either).

A SharePoint 2003 web part control is a composite control that contains labels, hyperlink controls, and image controls.  Most web parts are at a maximum 200px wide to accommodate modular design or have a height/width public property that can be set through the UI.  We’ll keep those properties in mind when creating our SSO web part.

NOTE: We’re not using the SSO functionalities of SharePoint.  Could this be done through that?  Maybe, but I’ve never tried.  If you have—I’d be interested in hearing how it compares.

Required Assemblies

The following assemblies should be used to generate the web part.

  • Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c
  • All other .NET 1.1 references, such as System.DirectoryServices, which are needed for the operation of the web part.

In addition, I’m using the WebPart template for VS 2003 (I’m running VS2003 in a VM with the SharePoint libraries copied over to the machine).

Fetching the GUID

The following code copies the current user (in the format of “domain\userName”) into the name variable.  Inside the try/catch statement, we’re connecting to Active Directory (using a delegated read-only account—the ONLY way you should be connecting for web applications) and using System.DirectoryServices to filter about by the sAMAccountName.  If an entry is found, the GUID is returned.

private void GetUserADGuid()


string name = this.Page.User.Identity.Name;

       name = name.Substring(name.IndexOf(@”\”) + 1);



              string[] adCredentialsArray =


AppSettings[“adCredentials”].Split(new char[] { ‘/’ });

              string adUserName = adCredentialsArray[0];

              string adPassword = adCredentialsArray[1];

              DirectoryEntry entry = new DirectoryEntry(“”,

adUserName, adPassword, AuthenticationTypes.Secure);

              DirectorySearcher searcher = new DirectorySearcher(entry);

              searcher.Filter =  string.Format(“(sAMAccountName={0})”, name);

              SearchResult result = searcher.FindOne();

              if (result != null)


                      _userGuid = result.GetDirectoryEntry().Guid;



       catch (Exception exception)


              this._userGuid = Guid.Empty;



Consuming the GUID and Rendering the Web Part

The next step is to use our GetUserADGuid method and render the redirection code for the web part (which will use JavaScript). 

private void BuildRedirect()


if (this._userGuid == Guid.Empty)






              string guidString;

              if (_encryptGuid)


                     guidString = this.EncryptString(







                     guidString =

string.Format(“{0}”, userGuid);



UriBuilder builder = new UriBuilder(this.LinkTarget);


string link =






       catch (Exception exception)





The Replace method on _linkTarget does the majority of the heavy lifting for this web part.  Part of the instructions to go along with this part is to include %GUID% on the SharePoint design side wherever you wish the GUID to be placed.

Such as:  http://myapplication.domain.local?uid=%GUID%

The web part would then replace %GUID% with the authenticated user’s GUID.

The EncryptString method is not included in this post (but in the code project attached) and is a simple method that encrypts (using the RijndaelManaged class in System.Security.Cryptography) the string information that is processed.

Finally, the web part overrides RenderWebPart and builds the control based on the properties specified at the web part’s design time (in SharePoint) and the results of the public properties.  When either the logo image or the link is clicked, the BuildRedirect method is executed that evaluates options, such as encryption and “new window”, and then redirects accordingly.  The method that builds the redirection link with the GUID is separated out from the actual redirection action for sake of testing.

  1. October 6, 2008 at 3:58 am


    a more elegant method and secure is to use SAML2 assertions.

    i setup a SAML2 Identity provider (you can do this conceptually by creating another site within IIS)

    my apps are then configured with a public key and the url of the IDP.

    also more and more third parties are supporting SAML out there.

    so we now have SAP single sign on, google apps and others.

    • Kaj
      July 5, 2009 at 1:02 pm

      Can you please let me know how to use SAML for Sharepoint Single Sign on with CRM.
      I have a requirement, we have a sharepoint extranet and customers login to this extranet and they want to connect to another CRM applications with out entering CRM user id and pwd.

      Thanks in advance.

  2. May 22, 2009 at 2:57 am

    Огромное спасибо

  3. juan
    June 10, 2009 at 10:48 am

    Hi,the code project attached i cant download
    please help


  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: