Wednesday, April 08, 2009

Multiple authentication providers and SSO into MOSS

Recently I faced a problem where I had to enable a MOSS site to be accessible using three different methods. One was the standard windows authentication, the second was Forms authentication and the third was a SSO method where a user identification token came in the querysting.

Getting the first two up and running is documented in many places so I will not repeat that here. See these links for instance:

What was new for me was the third requirement. The specifics were that the querystring would contain a user token which could then be used to call a web service to authenticate the user. The user would not notice any of this and be logged in automatically. This method was used so that users coming from another portal could enjoy a Single Sign On experience when going to the MOSS site.

I solved this as follows:

  1. I extended the web site to yet another URL.
  2. I changed the login page (in the web.config of the newly extended web app) to a custom login page.  * More on this later
  3. I added another membership provider line in the web.config of all the web applications corresponding to this site (Windows Integrated, Forms, SSO) which was the same as my forms membership provider except for two things:
    • The name of the provider has to be different
    • The applicationName is different
    This ensures that any users created to work with the SSO site will not be available for the forms site, while I can still use the database created for the Forms authentication provider. 
  4. I added a new role provider that is again the same as the role provider for Forms, just with a different name.  (This I did since MOSS does not allow you to use the same membership or role provider for different zones)
  5. I then went to central admin and changed the authentication type of the zone corresponding to the SSO web app to forms.  I specified the new authentication and role providers.  Even though the authentication type is forms, the user never gets a chance to enter a username or password due to the code in the login page. 
* This login page has logic in it to call a web service which accepts the token and returns the user name (if token is valid). It then uses the standard memership methods to authenticate the user based on the returned username and a static password that is the same for each user. These users are stored in the same database as the Forms users but with a different application name so that they can only be used from the SSO site.

I had also created some tools for user management that I then updated to be aware of multiple membership providers.  For example, my web part that created a new users has a radio button choice in it that forces the choice of a Forms user or an SSO user.  This drives which provider is used to create the user.  Similar logic is used in user editing, listing, etc.  

There are a number of alternatives to this solution such as creating a new user database for the SSO membership provider or even creating a new membership provider, however I found this technique to be the least amount of work and quite effective. 

No comments: