Adventures in SharePoint Forms Based Authentication – Part 2

As I said in Part 1, you can get FBA fully set up by using Andrew Connell’s cookbook HOWTO: Configuring a Office SharePoint Server 2007 Publishing Site with Dual Authentication Providers and Anonymous Access. Before you dive into the steps, here’s an overview that I hope will give you a mental picture of how the whole thing will hang together once you’re done.

Let’s talk about your users and where you will store their information. They won’t be listed in Active Directory or any other corporate repository. They will be non-employees who will come to your site anonymously and complete a registration form, at which point you’ll create an “account” for them. In this case, the “account” ends up being a record in some storage mechanism, usually a SQL database.

So where does this database come from and how do you manipulate it? There’s good news on this front — you get a lot for free if you’re using SQL Server as your database. Microsoft ships a utility with .NET called aspnet_regsql.exe that will create a SQL Server database containing the tables you need for managing user information. You’ll find the utility in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. (Even if you’re on .NET Framework 3.x, this utility will still be in the v2.0.50727 folder.)

You could run this utility from the command line, but you don’t have to — double-click it and it will give you a GUI-based wizard. You will need to know the answer to an important question, though, which is what capabilities you want the wizard to create tables for. You definitely want it to create tables for managing user identities, but you can also have it create a table for managing user profile information. Profile information is anything ancillary you want to keep track of beyond username, password, and email address. If you want to store profile info in SQL too, and you probably do, have the wizard create the profile table; for command-line invocation, you’d supply the -p option.

There’s a term you’ll encounter that you need at least a passing familiarity with. You’ll see lots of references to .NET’s provider model. This refers to a layer of abstraction that now exists for storing and retrieving certain kinds of data. The smarties at Microsoft know you need a way to store user info, and so you don’t have to code your own, they have created a set of providers — each provider is basically a set of methods your application can call for storing and retrieving some kind of data. What makes this a provider model is that it’s extensible; it’s just an interface agreement. Any body of code that implements the defined set of methods constitutes a provider. A “membership” provider deals with basic, core user info; a “profile” provider deals with additional, ancillary user info.

OK, so the way you manage user info is by calling either a membership or profile provider whose methods let you do the usual things you’d want to do with user info. But where do the providers come from? Do you have to write your own? Again, no. You can, but Microsoft supplies both membership and profile providers for the case when the user info will be stored in SQL Server.

Let’s recap. Your application will store user data in a database, typically SQL Server. You create that database using a Microsoft-supplied utility. You access those tables using Microsoft-supplied membership and profile providers. So does your app have to contain code that directly calls the provider methods? Nope. Microsoft has also supplied ASP controls that you use in your pages to accomplish tasks like creating a new user account and logging in (or denying) a user. For creating new users, you can use the CreateUserWizard control (asp:CreateUserWizard), and for letting users login, you can use the Login control (asp:Login). When a form containing either of these controls is submitted, the controls take care of calling the appropriate provider methods.

The folks at 4GuysFromRolla.com have written some fantastic articles on the .NET provider model, the related ASP.NET controls, and how to work with all of that in applications. The whole series is worth reading; definitely look at the first article for a great overview.

In the next part of this series, we’ll look in some detail at how you create your own forms for creating new user accounts and logging in existing users.

Advertisements
Tagged with: ,
Posted in SharePoint

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: