Skip to main content

Cloud

WSS, ADAM, and Building a Custom Authentication Provider

The post I wrote last year about using WSS 3.0 with ADAM for user authentication has drawn quite a bit of interest — and also some confusion (and, uh, passion) about the licensing. Does it really require a license to MOSS or not? Hopefully this post will offer some clarity — and also some options for those of you running only WSS.

So that there’s no ambiguity, here are the details on the features and licensing:

  1. The ability to use the ASP.NET pluggable membership provider model is supported by WSS without MOSS components.
  2. The LDAPMembershipProvider and LDAPRoleProvider classes that are part of the Microsoft.Office.Server assembly are licensed as part of MOSS

I went back and forth about what to title that post. If I had called it "Using ADAM with MOSS," I would have been flamed for not indicating that you could use membership providers with WSS alone; since I called it what I did, there are those who were annoyed by the MOSS requirement of the provider that was demonstrated.

So what do you do if you’re not running MOSS? You have two options:

  1. Buy a third-party utility (e.g. LDAP Client.NET – though I haven’t tried this one personally).
  2. Write your own.

The point of this post is to demonstrate that creating your own provider for ADAM isn’t as daunting as it might first seem. I implemented the shell of one (code included below) in a few hours.

Here are the steps:

  1. First, brush up on your understanding of the ASP.NET pluggable authentication provider model. There’s no paucity of information on this, and there’s nothing too unique about how the provider will behave with WSS.
  2. Next, create your ADAM user store. The instructions in my prior post walk you through the necessary steps.
  3. Start a Visual Studio project, selecting a Class Library as the project output.
  4. Add references to System.Web and System.Configuration to your project.
  5. Create a new class and inherit from System.Web.Security.MembershipProvider. When you specify that class (which is abstract) as the base class, Visual Studio will give you a nifty context menu option to Implement Abstract Class. You’ll see when you do this that VS adds all of the required items that you need to implement in your class.

    2007-11-20_064102

  6. But there’s good news (at least for a quick start). Per Steven Fowler, the only real methods that you need to implement for MOSS support are ValidateUser(), GetUser(), FindUserByName(), and FindUsersByEmail(). My experience is that you’ll also need the GetUserNameByEmail() method. (Side note: Steven also has an interesting post on how the PeoplePicker interacts with the authentication provider.)
  7. Implement the necessary methods. Here’s my code showing a very basic implementation of the five methods noted above. It’s not production-ready, but it works, and hopefully it provides you with a pattern for approaching the problem.
  8. Sign and GAC the assembly.
  9. Extend your web application and configure the extended app to use the new provider. This post has detailed instructions on the extension and configuration process. The XML I used to register the provider in the web.config for the web applications is shown here:

    <membership defaultProvider="AdamUsers">
    <providers>
    <add name="AdamUsers" type="AdamSecurity.AdamMembershipProvider, AdamSecurity, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8358bf1c61de26eb" applicationName="/" ldapServer="[server name]" ldapPort="[port]" ldapContainer="[ldap container]" ldapUser="[user]" ldapPassword="[password]" />
    </providers>
    </membership>

  10. You should now be able to add ADAM users using the PeoplePicker on the internal application and login as those users on the external side.

    2007-11-20_091845

Hopefully this helps you understand what’s involved with creating your own provider for ADAM and WSS and provides a quick start if this is something you decide to undertake.

In this example, I only showed implementation of a MembershipProvider, but you can use the group definitions within ADAM to support the ability to add groups into SharePoint. To do this, you’d simply need to inherit from the System.Web.Security.RoleProvider class and follow a very similar pattern as the membership provider.

If you want to create a full-blown provider with implementation for all of the required methods and proper instrumentation (error handling, logging, etc.), it will take you a bit of time, but I still don’t think it’s too bad a task.

Resources:

  • Download the code I used in this example
  • MSDN’s provider toolkit with examples of membership and role providers
  • Scott Guthrie’s comprehensive post on ASP.NET 2.0 membership

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Matthew Morse

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram