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.