Coding With SharePoint SSO, Part 1

In this series of three posts, I will attempt to introduce working with the SharePoint Single Sign-On service from a more programming standpoint, and I will pepper in some of the administrative and configuration stuff because I haven’t seen it covered very well at all, either on the web or in books. I will firstly be going over the basic programming stuff in this post, and then we will begin to explore the more advanced SSO programming concepts, and hopefully at the end you will have a viable solution that you can put to work in your environment.

The SharePoint Single Sign-On functionality is provided through the Microsoft.SharePoint.Portal.SingleSignon namespace, however we will be deriving some other minor functionality from other namespaces as well during the duration of this series. Therefore, when working with the Single Sign On functionality, you will have to import this namespace by making a “using Microsoft.SharePoint.Portal.SingleSignon” reference at the top of your class file.

When approaching the Single Sign-On service programmatically, there are some important differences to take account between the 2003 and 2007 version of SharePoint. Most importantly is the concept of pluggable providers, where the default SSO provider can be replaced with a custom SSO provider assuming that the appropriate interface is inherited from within the custom provider. This type of pluggable functionality allows a developer to provide an architect with a more tangible solution whereby the provider effort can be tailored to the environment without attempting to structure the default SSO service towards a specific need, a very powerful option indeed.The primary interface that the developer has to become accustomed to is the ISsoProvider interface, which, since the provider model is pluggable allows a developer to specify an arbitrary provider. When pooling the provider, you will also be using the SsoProviderFactory class that is offered through Microsoft.SharePoint.Portal.SingleSignon, which contains the GetSsoProvider method, which will return the current provider that is implemented within your MOSS environment. Therefore, your first method call will be structured as such:


ISsoProvider l_oProvider = SsoProviderFactory.GetSsoProvider();


The above, when added, as stated, will get you the current provider that is implemented with your MOSS implementation. Following, let’s actually start to retrieve some data from our SSO provider, namely, let’s start snagging some credentials!

In order to harvest credentials, we are going to use the ISsoProvider.GetCredentials method provided out of the Microsoft.SharePoint.Portal.SingleSignon namespace. There is as a string argument this is going to take, the application identifier, which is generally know as the Enterprise Application Definition (more commonly known as an EAD). Therefore, you will have to know what this literal string value is, and it must be in place before you start programming against your SSO environment. Here is an example of starting to use the GetCredentials method, using the previously declared provider object:


SsoCredentials l_oCredentials = l_oProvider.GetCredentials ( “HereYouShouldUseYourEAD”);


When error handling this type of programming tasks, there are some very specific exception types that you can use in order to ensure that the exceptions that you return are correct, and provide more value with your software than orthodox system exceptions. For catching generic SSO system exceptions, it is advisable to use the SingleSignonException object, since it will return an error code that will help you trouble shoot specific exceptions more efficiently.


catch (SingleSignonException l_oException)


For handling method level exceptions, such as when using the GetCredentials method as described in the above, you should use the more specific exception types, namely the SingleSignonCredsNotFoundException. This exception type takes on the form:


catch (SingleSignonCredsNotFoundException l_oSSOException)

Ok, that’s enough for now, in the next post, I will deep a whole lot deeper into programming SSO, and maybe do a prequel to this post for how to correctly architect an appropriate SSO environment.


6 thoughts on “Coding With SharePoint SSO, Part 1”

  1. Glad to finally see someone posting on this exciting and not so popular topic. SSO is vital to offer a true portal experince to corporate end users. Thanks, Adam.

  2. Great article, Adam. Any clue when part-2 and part-3 would be published. Just eager because I’m trying to implement SSO on the company sharepoint portal.

  3. Hi Adam,

    I am working MOSS 2007 and CRM 3.0 integration. For this, I am need auto-logon facility between MOSS 2007 and CRM 3.0.

    Does SSO for MOSS 2007 provide this feature? If yes, can you please help me?

    If not SSO, then what else I need to do.

    I have read lot of blogs regarding SSO in MOSS 2007, but I found that SSO is good for only for third-party database driven tasks.

    Please I need it very urgent.


    Gurjot Singh

  4. Hi,
    I have to use MOSS2007 SSO to connect to a CRM,
    Can you please help me. and let me know did you able to use SSO and connect to CRM.
    Please provide me any information which helps me in configuring SSO with CRM.
    Please help me its urgent.
    Thanks in advance.

Leave a Reply

Your email address will not be published. Required fields are marked *