How to implement a simple forms authentication provider

This article was been updated for WSS v3 / MOSS 2007 RTM on December 11, 2006. In addition, additional information was added and changed in the section Enabling Anonymous Access when the article was updated for RTM.
Content-centric sites that are managed via a Content Management System typically have very specific requirements. The owners of the content of a content-centric site usually spend most of their time behind the company firewall and login to their corporate Active Directory. Ideally these users need to have a single-sign-on (SSO) experience where they don’t have to remember a special username and password to simply login to a Content Management System to author and manage the content on the company Web site. The public-facing portion of the site needs to allow visitors to browse the site anonymously. However, there may be certain areas of the site that require the user to login. These may include premium content, registration, or an e-commerce solution. While the familiar username/password dialog is acceptable in a corporate setting, it is frowned upon on the public realm of the Internet. Therefore, many companies prefer to implement some type of forms authentication where users login using a username or email address and password to gain access to protected areas.
Web Content Management (WCM), one piece in the Enterprise Content Management (ECM) strategy included in Microsoft Office SharePoint Server (MOSS) 2007 adds the capability of hosting and managing content-centric sites to the SharePoint platform. MOSS 2007 is built on top of Windows SharePoint Services (WSS) v3 which is in turn built on top of ASP.NET 2.0. This means that WSS v3 (and MOSS 2007) have full access and utilize everything that ASP.NET 2.0 has to offer… including the pluggable authentication model. It is this pluggable authentication that I will leverage to provide multiple authentication options for a single Web site. In this article I want to demonstrate how to configure a Publishing Site (aka: WCM site) in MOSS 2007 for the previously described common scenario companies encounter with content-centric sites. The goal is to provide an experience that achieves three requirements:Allow content owners/authors to authenticate on the site using their corporate Active Directory credentials in order to manage the Web site’s content.Allow unauthenticated, anonymous users, to browse the unrestricted areas of the Web site.Require anonymous user to provide a friendly Web-based form to login in order to consume restricted content.
I’ll demonstrate how all three goals can be achieved using MOSS 2007 and WSS v3 in this article. First I’ll set up a database to store the information for users accessing the Web site from the Internet. Once that’s configured, I’ll create two Web applications and a Publishing Site; each Web application, or IIS Web site, will be configured for a specific type of authentication mechanism (Windows Authentication [AD] and Forms Authentication). Then I’ll configure both Web applications so they can access the users and roles that will be granted rights within the site (typically read or contribute rights to protected areas of the site). Once both sites are configured to communicate with the forms authentication-based user and role store, I’ll configure one Web application to allow users to sign-in and authenticate via a common Web-based form. The last step will be to configure the site for anonymous access so they can browse the site and consume the content. Finally, I’ll show you how to require a login for a specific area of the site.
This article is not written as a step-by-step instruction manual on how to configure your site for anonymous access with dual authentication mechanisms. It assumes some experience with WSS v3 and MOSS 2007. While the subject of this article deals with configuring a Publishing Site (aka: Web Content Management Site), everything translates to any type of WSS v3-based site including MOSS sites.Setting Up ASP.NET 2.0 Forms Authentication User & Role Data Store
Before we can do anything, we first need to create a database that will store all the information, credentials, roles, and users for the forms based authentication site. Then we’ll add a single user to this database which we’ll use for testing later. Nothing in this step has anything to do with SharePoint as its just plain ASP.NET 2.0.Create the ASP.NET 2.0 DatabaseBefore we can do anything else, we need to create a database that will store the users and roles. Microsoft has provided a utility,aspnet_regsql.exe, that will create this database for you. It can be found here:%windir%\Microsoft.NET\Framework\v2.0.5027. Executing this file will trigger a wizard that will walk you through creating the ASP.NET 2.0 database. I’ve named my database AcAspNetDb and configured it for Windows Authentication, as shown in Figure 1 below.

Figure 1 – aspnet_regsql.exe wizard (click for larger image)Configure Membership & Role ProvidersNow that our database is configured, we need to add a single user. In my opinion, the best way to do this is to create a new Web site project in Visual Studio 2005. Why? Because not only does it have an easy way to access the ASP.NET 2.0 administration Web site that will let us add users and roles, but we’ll also ensure our database connection strings, membership, and role providers are correctly configured before we bring SharePoint into the equation. I’ll use these same connection string and providers in the SharePoint sites later… so we have a good foundation to copy from.
Open Visual Studio 2005 and select File -> New -> Web Site. In the New Web Site dialog, select the template ASP.NET Web Site, set the location to File System. I like to put all my Web sites in the[drive]:\Inetpub directory so I’ll put mine in the following directory:[drive]:\Inetpub\AC FBA Utility Site(FBA = Forms Based Authentication). The language is irrelevant so you can pick anything… we won’t write a single line of code.

Figure 2 – Visual Studio 2005 New Web Site dialog
Now, add aweb.config file to the site. By default, you’ll see a node within the node. Here you want to specify a connection string to the database you just created in the previous step. For me, I’ll replace the node with the following:
1: 2: 6:
With the connection string set up, now we need to specify the membership and role providers. In this article I’m using the ASP.NET SQL membership and role providers, so I need to add the following to theweb.config file, within the node:
1: 2: 3: 4: 19: 20: 21:  22: 23: 24: 25: 30: 31:
There are a few things you should take note of from the above code (marked in bold). First, note the name and connectionString attribute for the providers. When you install the .NET Framework 2.0, default connection strings and providers are specified in themachine.config file (located in the%windir%\Microsoft.NET\Framework\v2.0.5027\CONFIG). You want to make sure you use unique names here and not the names that Microsoft has included as the default names in themachine.config file. If you elect to reuse their names, you’ll need to explicitly remove each one by name (via the node) or clear all predefined connection strings and providers (via the node). To make it easy, I specified unique names, as indicated in bold.
With everything configured, launch the ASP.NET 2.0 Web administration site from within Visual Studio 2005: Website -> ASP.NET Configuration. When the site loads, the first order of business is to switch it from Integrated Authentication to Forms Authentication. To do this, select the Security link and then select the Select Authentication Type link in the Users container. If it isn’t selected already, make sure From The Internet (aka: Forms Authentication) is selected and click Done.Create A UserNext, we need to add a user that we’ll later use for testing. Select Security again and then select Create User. I’m going to create a new user with the User Name of andrewconnell and Password of password. Note I don’t have to enter a strong password because of some of the settings I changed in the membership provider in the code above. The E-mail address isn’t important, so I’ll just enter and click Create User.
Finally, let’s make sure the markup in ourweb.config file is correct for our membership and role provider. To do this, select the Provider tab and then select Select a Different Provider For Each Feature (Advanced). You should see the membership and role provider that we specified in ourweb.config. Selecting the Test link for either should confirm they are successfully talking to the database.
At this point, we now have our ASP.NET 2.0 user and role database store configured. More importantly we should have a good templateweb.config containing the connection string, membership provider and role provider settings that we can copy from when modifying theweb.config files for our SharePoint sites. Now we need some Web applications to configure!Creating Two Web Applications, One For Each Authentication Mechanism
We need some sites to configure for authentication right? I mean, that’s the point of the article right? Duh!Creating the http://extranet IIS Web siteFirst step is to create a new Web application just like you would any other time. From SharePoint’s Central Administration Web site, select the Application Management tab, then Create or Extend Web Application and then Create a New Web Application. I’m guessing if you’re reading this article, you know how to create a new Web application from here… so I’ll spare the details, but I want to point out is that I specified the following:Set the Description as SharePoint – Extranet 80Set the Port to 80Set the Host Header to extranetPicked NTLM as the Authentication Provider Specified Anonymous Access to No
After creating the Web application, I then created a new site collection in the Web application naming the site Acme and picking the Publishing Portal site template. If you’re having problems and want to see exactly what I selected, you can viewFigure 3 displaying the Create New Web Application page orFigure 4 displaying the Create Site Collection page.
At this point we now have a site, configured for Windows Authentication, named ACME at http://extranet. This is the site our content owners will use to authenticate using their Active Directory corporate accounts in order to add, edit, and manage the content on our Publishing site. Make sure everything is working by browsing to the http://extranet Acme site. You should see the Welcome control and the Site Actions menu in the upper right-hand corner of the page. Assuming everything is working, we have now satisfied the first goal listed in the introduction above! Creating the http://internet IIS Web siteNow we need to extend our Web application to another IIS Web site. This is the site our anonymous, or Internet users, will use to access the site. This site will need to be available to anonymous users as well as provide a mechanism for them to authenticate against, via Forms Authentication, in order to access restricted areas of the site (such as a member’s only section). To extend the Acme Web application to another IIS Web site, from SharePoint’s Central Administration, select the Application Management tab, then Create or Extend Web Application and then Extend an Existing Web Application. Again, I’ll spare you from the details and highlight only a few important points on this page:Make sure you select the Web application you want to extend… in our case we want SharePoint – Extranet 80. Use the Web Application selector at the top of the page to pick the correct application.Set the Description as SharePoint – Internet 80Set the Port to 80Set the Host Header to internetPicked NTLM as the Authentication Provider Specified Anonymous Access to NoSet the Load Balanced URL Zone to InternetWe’ll enable anonymous access later.
Again, if you are having problems, you can see exactly what I selected fromFigure 5. Now we have a site that we can configure for our Internet users to access anonymously and also login via Forms Authentication. However, before we do that, there are a few configuration tasks we have to do.Configure The Web Applications To Communicate With The ASP.NET 2.0 Forms Authentication Data Store
Once you have a Web application created that will host a site, you will need to change its authentication provider to not use Windows Authentication but instead use Forms Authentication as well as configure the site so it can communicate with our user and role data store… the AcAspNetDb we created earlier. To do this, we’ll use the connection string, membership provider, and role provider we created and already tested in our utility Web site’sweb.config file.Configure http://extranet & http://internetFirst, we’ll modify the two IIS Web sites (http://extranet and http://internet)web.config files to include the connection string, membership provider, and role provider information so they can both communicate with our user and role store. It’s obvious why the http://internet site would need these changes, but why make them to the http://extranet site when we’re going to use it for Forms authentication? If we didn’t, it would be somewhat difficult and inconvenient (but not impossible) when we needed to grant any special permissions in the Acme Web application to one of the users or roles in our data store. This way, one of our content owners can authenticate using his/her Active Directory credentials and still grant a user who will authenticate via Forms Authentication access within the site.
Open theweb.config file for the http://extranet Web site, found in the following directory (if you let SharePoint specify the Web site root directory… otherwise, retrieve it from your specified path):c:\Inetpub\wwwroot\wss\VirtualDirectories\extranet80. Add the node, listed above, just after the closing tag and opening tag. Then add the membership and role provider markup, listed above, just after the opening tag and save your changes. Do the same thing for theweb.config for the http://internet Web site, found here:c:\Inetpub\wwwroot\wss\VirtualDirectories\internet80.Configure SharePoint Central AdministrationNow both Web applications are configured to communicate with the data store. There’s one last step we have to do… we need to add the same information to the SharePoint’s Central Administration Web site’sweb.config file. Why? We need to make sure the Central Administration Web site can communicate with the data store in case we want to do any security management of the users and roles in the data store such as configuring policies for the Web application. Repeat the steps above for the Central Administration’sweb.config which should be found here:c:\Inetpub\wwwroot\wss\VirtualDirectories\[#####]. You need to make one small change… change the defaultProvider attribute on the node to AspNetWindowsTokenRoleProvider. This is necessary because Central Administration still uses Windows Authentication for the role provider. The node for the Central Administration’sweb.config should look like this:
1: 2: 3: 4: 9: 10:
Now we’re finally ready to configure the http://internet site for Forms Authentication!Enabling Forms Authentication On One Web Application
Flipping the switch to Forms Authentication is very simple… it’s just all the prep work that’s the complicated part. Browse to SharePoint’s Central Administration Web site, select the Application Management tab, and then select Authentication Providers. First, ensure you are working with the correct Web application by checking the selector in the upper right-hand corner of the Authentication Providers page (as shown in Figure 6). Once you’re on the correct Web application, select the Internet zone link (as shown in Figure 6).

Figure 6 – Authentication Providers page
Note that even though we’ve selected the http://extranet Web application, we are really modifying the http://internet IIS Web site because that’s the one mapped to the Internet zone.
On the Edit Authentication page, we are going to change the Internet zone for the http://extranet Web application to the following settings:Authentication Type: FormsEnable Anonymous Access: checkedMembership Provider Name: AcAspNetSqlMembershipProviderRole Manager Name: AcAspNetSqlRoleProvider
Notice that the names of the Membership Provider Name and Role Manager Name are the names of the providers we entered in theweb.config’s. Now you see why we had some pre-configuration work to do before we actually made the switch. Refer toFigure 7 to see all settings I selected on the Edit Authentication page.
We now have two different ways for users to get to our Acme Web application:Via http://extranet, authenticating using Windows Authentication (using their Active Directory credentials)Via http://internet, anonymously or authenticating using Forms Authentication
Ah.. but we’re not quite finished. Even though the http://internet Web site is now configured to allow anonymous users, the Acme Web application has not been set to grant permission for anonymous users to browse the site. You can prove this by trying to browse to http://internet. You’ll immediately get redirected to the default SharePoint Forms Authentication Sign In page, as shown in Figure 8.

Figure 8 – SharePoint’s default Forms Authentication Sign In Page
Let’s prove that the Forms Authentication is actually working with our data store. First we need to add our user to the site. To do this, browse to the http://extranet Web site, select Site Actions, then Site Settings, then People And Groups. Select the New button to add a user to the site. On the Add Users: Acme page, enter the username of the user we created previously: andrewconnell. Then click the Check Names icon (little icon with a blue check just below the Users/Groups input box… or press [CTRL]+[K]). In the Give Permission section, select Add Users To A SharePoint Group and select Acme Visitors [Read] and finally click OK. We’ve now granted our user access to the site.
To test, open a new browser window and browse to http://internet. You should immediately get sent to the SharePoint Sign In page. Enter the account’s credentials (andrewconnell/password) and click Sign In. You’ll then get signed in and redirected back to the homepage of the site. You can see you’re logged in because you can now see the Welcome control in the upper right-hand corner of the site. Notice how you can’t see the Site Actions menu? That’s because we only have the rights assigned to Visitors, which means we can’t do anything to the site but browse it.
Last step… let’s open the site up for anonymous users…Enabling Anonymous Access
In order for anonymous users to have access to the Acme Web application and browse the site, we need to turn anonymous access on. In our case though, we only want to turn anonymous access on for the external (or http://internet) site. Before we do this, we should create a new account in our ASP.NET 2.0 database that we can use as an administrative account to make changes to our external site. First, create a new account using the same process in the Setting Up ASP.NET 2.0 Forms Authentication User & Role Data Store: Create A User section above. I’m going to create this account with the following credentials:Username: FbaAdmninistratorPassword: password
Next, we need to grant this user ownership-level rights to our http://internet site. WSS v3 introduces a new capability where we can specify a user to have full control over a site via Web Application policies. These policies trump any permission setting within the site itself. We’ll use this


One thought on “How to implement a simple forms authentication provider

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s