kamagra how much to take

Implementing Pluggable SharePoint Single Sign-On

Implementing Pluggable Single Sign-On
One of the most overlooked aspects in previous versions of SharePoint was the Microsoft Single Sign On Service. This service for most people struck thoughts of a federated SSO mechanism by which one would gain a “one sign on for several applications” environment whereby all third party apps could be assimilated into the SharePoint environment using an arbitrary sign on mechanism.

This common misconception was the reason that the Microsoft Single Sign On service was passed over so heavily. Since it was originally tailored to pull orphaned data out of third party databases, such as SAP, Siebel, or other various LOB backend systems, not being able to sign onto them turned several parties off to the service.

The context of the service remains the same, however the natural power that it provided is still the same, and multiples even further when combined with new functionality such as the Business Data Catalog (BDC) whose main purpose is now to integrate those very LOB backend system databases. Using the native Microsoft SSO, it is possibly to eliminate the need to build complex identity impersonation in order to harvest business data out of those third party systems, but rather using its structure of Enterprise Application Definitions (EAD) one can build several pass through authentication channels by which that very business data can easily be assimilated and brought to a web front through the use of various WebParts, whether it is OOB, or a custom developed solution.

There are several considerations when setting up the SharePoint 2007 (MOSS) Single Sign On Service, and oddly enough, the most difficult of all the tasks isn’t the programmatic hooking of the data into various logic distribution mechanisms, such as a WebParts. One of the most difficult portions for various organizations to grasp was the actual process account setup, and then architecting the proper Enterprise Application Definitions so that the service can be leveraged properly, following, how one can use the powerful classes that exist within the SSO namespaces in order to procure third party forms sign on for a truly federated sign on environment.

The Default Single Sign On Service
Single sign on in SharePoint isn’t just running, the service is halted by default when the machine is started, and therefore you have to call up services.msc from a run and start it up. You will have to start SSO on your job server. Once you get started, the best next step is to start to plan out how you are going to configure the accounts for SSO, which are:

  • Configuration account
  • Single sign-on administrator
  • Single sign-on service
  • Enterprise application manager

You can pull up the exact criteria of what needs to be satisfied for each account. After the accounts are created you will create the encrypted SSO database where we are going to map and store our third party credentials. Once your database is created, and the encryption key is created, you can create your Enterprise Application Definition (EAD) which is going to define the structure, it says exactly how the retrieval of the credentials are going to be handled. The creation of that is pretty self explanatory.

Pluggable SSO Architecture
The Microsoft SSO Service API is independent of the specific authentication mechanisms that are discussed in previous articles. The unique feature of the new MOSS SSO is that the Microsoft Single Sign On service is now a pluggable feature, by which you can leverage whichever SSO provider that you would like, be it a custom one that you have made or one provided by a third party. When doing so, the default SSO provider, SpsSsoProvider, will no longer be used. Because only one SSO service can be used, it is a one or other choice. A MOSS administrator/architect has to decided whether they want to bind the default SSO provider or use one of there one choosing, each which carries its own implications.

Using SSO To Procure Forms Authentication Credentials Passing

Contrary to popular belief, it is possible to use SSO to sign onto other forms-based applications so that the backend credential cache can be used for more than just exposing business data into WebParts. Although this requires some development, it is a powerful feature that allows a fluid experience for your users. Using two separate webforms, along with some minor JavaScript to copy credentials after some code behind is run, this can be easily facilitated:

Firstly, we have to create a separate login form:


Creating the page load event

  1. </span></strong>
  3. private void Page_Load(object sender, System.EventArgs e)
  4. {
  5.    Credentials x = new Credentials();
  6.    string[] z = new string[1];
  7.    string strUserName;
  8.    string strPassword;
  9.    try {
  10.      Microsoft.SharePoint.Portal.SingleSignon.SSOCanaryChecker.AddCanary(Page);
  11.      x.GetCredentials(Convert.ToUInt32(1), "&lt;:Put Here EAD Your&gt; ", z);
  12.    } catch (SingleSignonException ex) {
  13.      if (ex.LastErrorCode == SSOReturnCodes.SSO_E_CREDS_NOT_FOUND) {
  14.        return;
  15.      } else {
  16.        throw ex;
  17.      }
  18.    }
  19.    Server.Transfer("webform1.aspx");
  20. }

Event Handler For Submissions

  1. </span></strong>
  3. private void Button1_Click(object sender, System.EventArgs e)
  4. {
  5.    Credentials x = new Credentials();
  6.    string[] rgSetCredentialData = new string[2];
  7.    rgSetCredentialData(0) = uName.Text;
  8.    rgSetCredentialData(1) = PWD.Text;
  9.    Credentials.SetCredentials(Convert.ToUInt32(1), "&lt;:Put Here EAD Your&gt; ", rgSetCredentialData);
  10.    Server.Transfer("webform1.aspx");
  11. }
  12. }
  14. [/csharp
  16. <span style="text-decoration: underline;"><strong>Webform1.cs
  17. Creating the page load event</strong></span>
  19. <span style="text-decoration: underline;"><strong>[csharp]</strong></span>
  21. private void Page_Load(object sender, System.EventArgs e)
  22. {
  23.    Credentials x = new Credentials();
  24.    string[] z = new string[1];
  25.    string strUserName;
  26.    string strPassword;
  27.    try {
  28.      Microsoft.SharePoint.Portal.SingleSignon.SSOCanaryChecker.AddCanary(Page);
  29.      x.GetCredentials(Convert.ToUInt32(1), "&lt;:Put Here EAD Your&gt;", z);
  30.    } catch (SingleSignonException ex) {
  31.      if (ex.LastErrorCode == SSOReturnCodes.SSO_E_CREDS_NOT_FOUND) {
  32.        string strSSOLogonFormUrl = SingleSignonLocator.GetCredentialEntryUrl("&lt;:Put Here EAD Your&gt;");
  33.        Response.Redirect(strSSOLogonFormUrl);
  34.      } else {
  35.        throw ex;
  36.      }
  37.    }
  38.    strUserName = z(0);
  39.    strPassword = z(1);
  40.    TextBox1.Text = z(0);
  41.    TextBox2.Text = z(1);
  42. }
  43. }

The portion that isn’t handled with the above is that it will work fine if a user has entered, or currently doesn’t have credentials stored, but not if there password has changed, to build this in you would also have to call error codes, something like this:

  1. SSOReturnCodes.SSO_E_CREDS_NOT_FOUND = ssoe.LastErrorCode

You would then have to do a redirect using something like:

  1. SingleSignonLocator.GetCredentialEntryUrl

Then you could handled it. For the actual submission of the credentials, I just use JavaScript to paste them into an impersonated box for submission. One would have to fill in the programmatic name of your EAD between the <> in the codebehind forms for this to work properly. The important methods in here are getcredentials(), which will attempt to fetch the credentials, and setcredentials(), which will set the credentials.


Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>