The hoops of Internet-enabling a SharePoint site – Part 2

Sunday 13 July 2008 - Filed under Tech Notes

Part 1 of this discussion touched on some background as to why Internet-enabling a SharePoint site constitutes a fair bit of work. Now, to the actual work – here’s a list of hoops to jump through, in the preferred sequential order:

• Create a forms-based authentication (FBA) user store.
• Create an initial FBA administrator account.
• Extend an existing SharePoint application to add an FBA site.
• Modify the configurations of the extended SharePoint application as well as those of Central Administration, the Shared Services Provider site, and the My Sites host site.
• Set FBA authentication membership providers and role providers.
• Set site collection administrators.
• Set alternate access mappings.
• Set anonymous access options.
• Create FBA accounts and add them to the extended SharePoint application.
• Address the ActiveX bug in Internet-facing SharePoint sites.
• Customise the sign-in page.
• Find a way to manage FBA user accounts.

I should make a note that a large proportion (but not all) of the technical how-to’s associated with the above points comes from the book Real World SharePoint 2007, which has an entire chapter, authored by Stacy Draper, dedicated to forms-based authentication in SharePoint. Dan Attis has made his adaptation of the material available online. Both guys have done a great job on what Microsoft neglected to put together.

With that in our arsenal, let’s take a step back and look at it from a higher level. Below are my notes, links, caveats, or best practices applicable to each of the “hoops” listed above.

Create an FBA user store.
An FBA user store is simply a database that stores user accounts. It is an SQL Server 2005 (or 2008) database created on a server that is visible to the SharePoint site we are trying to Internet-enable. In a small-scale roll-out, there is no reason why the user store couldn’t be created on the same server as SharePoint. Obviously, it would be wise to spend some time thinking about where to create it if we foresee more than one SharePoint site from more than one SharePoint server under our care being Internet-enabled, in which case we might choose to have just one user store for all Internet-enabled SharePoint sites as opposed to creating a separate user store for each site.

We use aspnet_regsql.exe in the .NET Framework directory to create this user store. One of the things that needs to be decided at this point is the choice of database authentication mode, which by the way has nothing to do with SharePoint’s forms-based authentication. SQL Server can do either “Windows Authentication” or “SQL Server Authentication.” Windows Authentication (for databases) normally works for a single-server or single-domain scenario. But choose SQL Server Authentication if our SharePoint site needs to connect to a remote database server, i.e., on a different subnet or domain. As for the user store database itself, don’t worry about what goes in it just yet. We are simply creating an empty out-of-the-box ASP.NET database with an easily identifiable name.

Create an initial FBA administrator account.
Using Visual Studio, create an empty Web site project with a Web.config file that establishes a connection to the FBA user store that has been created. The configuration file will define a connection string, a membership provider, and a role manager provider for the user store. It is advisable to give each of them a nice, short, easy name such as wssCS, wssMP, and wssRP, respectively. Running the ASP.NET Web Site Administration Tool within Visual Studio then creates all the necessary tables for an ASP.NET user store. Using the same tool, create an FBA administrator account with a not-so-cryptic name such as wssAdministrator and give it a cryptic password. And yes, we do need Visual Studio to do all this in 5 minutes, although it’s quite odd that there is no ready-made user store setup interface accessible straight from SharePoint.

Extend an existing SharePoint application to add an FBA site.
From SharePoint Central Administration, extend the SharePoint application that we want to Internet-enable. The obvious assumption here is that there is already a SharePoint application (and hence site) created that is not yet Internet-facing. Extending a SharePoint application is essentially creating a new SharePoint site collection and binding it to the content database of another SharePoint site collection, so that the two site collections become a single “application.” When extending an application, there is a choice between a new port and a new host header. It’s all about what address we want to give to the Internet-facing portion of our SharePoint application – for example, “www.companyname.com:34567” or “extranet.companyname.com.” There may be significant infrastructure policy- and security implications to such a decision.

Modify the configurations of the extended SharePoint application as well as those of Central Administration, the Shared Services Provider site, and the My Sites host site.
Internet-enabling a SharePoint site means we need to enable FBA on that site, Central Administration and SSP as well as My Sites (assuming we are going to use My Sites). Enabling FBA in itself does not expose a site to the Internet; rather, the site merely becomes aware of an alternate method of authentication. Only the SharePoint application that has been extended from earlier steps will be made Internet-facing in the end. Note that Central Administration needs to default to “AspNetWindowsTokenRoleProvider” instead of our own FBA role provider. Other than that one exception, it’s a matter of copy-pasting the same lines of code onto each of the four Web.config files.

Set FBA authentication membership providers and role providers.
Now that our SharePoint sites have become aware of the FBA user store, we need to tell them to use FBA. This is done from SharePoint Central Administration by punching in the names of the FBA membership and role providers under each application. Do this on SSP and My Sites as well.

Set site collection administrators.
Add the name of the FBA administator account we created earlier to the list of site collection administrators of our Internet-facing SharePoint site, SSP, and My Sites. That FBA administrator can now manage all FBA-enabled SharePoint sites.

Set alternate access mappings.
This article from the Microsoft SharePoint Team Blog seems to give a thorough examination of the topic of alternate access mappings (AAM). But in a nutshell, we must make all internal and external Web addresses of our SharePoint applications known to SharePoint Central Administration. For example, if our Internet-facing SharePoint site has two addresses, one for internal users and the other for external/anonymous users, both addresses must be declared explicitly under alternate access mappings in order to be found by both groups of users. This works on top of IIS-level configurations. Crudely put, access mappings amount to an added layer of firewall security.

Set anonymous access options.
If our Internet-facing SharePoint site is to allow anonymous access at all, the anonymous access checkbox on the Authentication Providers page of Central Administration needs to be checked. The FBA administrator can then go to the FBA-enabled site and give anonymous users read access to the entire site or parts of it. If we don’t need to provide anonymous access, don’t bother.

Create FBA accounts and add them to the extended SharePoint application.
Now that our extended SharePoint application has a functioning FBA site, it’s time to add the actual accounts. This is a two-step process: create FBA accounts and then add them to SharePoint.

The quick-and-dirty method of creating FBA accounts is to use Visual Studio again. But this is highly inflexible and can only be done by the person (usually the developer or the administrator) who configured the entire FBA setup in the first place. A better way is to have some kind of a user management application, but Visual Studio can still get us started if we don’t need many user accounts and if those users don’t need to change their details (including passwords) any time soon.

Once accounts have been created in the FBA user store, they can be brought into SharePoint. Sign into the FBA site as the FBA account administrator we set up earlier, create new user groups as needed, and add individual FBA accounts to them. Now users can sign into SharePoint through forms-based authentication… almost.

Address the ActiveX bug in Internet-facing SharePoint sites.
There is a confusing/annoying behaviour of SharePoint 2007 that has yet to be addressed as of Service Pack 1. Upon signing into the FBA site, Internet Explorer asks the user to install an ActiveX control called “Name.” Installing it seems to do no harm, but ActiveX? It’s one of those things that should not be seen around SharePoint. This needs to be addressed by the SharePoint implementer or administrator as it involves modifications to master pages. The Mossman’s blog explains how to fix this ActiveX issue. The same fix also needs to be carried out on the “application.master” file in the way endorsed by Microsoft. This job overlaps with another broad discussion of customising the look-and-feel of a SharePoint site, but we will investigate that another time.

Customise the sign-in page.
Unless anonymous access has been enabled, the FBA site will throw a generic-looking sign-in page when users connect to it. This page (login.aspx) can and should be customised to provide necessary information for the users of the site. For example, it is advisable to ask the user to ensure that the “Sign me in automatically” checkbox is checked, or to simply have it checked by default programmatically. That will help with the user experience in terms Office integration, among other things. When configured correctly, the SharePoint developer or implementer can use Visual Studio to add to the sign-in page some useful ASP.NET controls such as password recovery.

Find a way to manage FBA user accounts.
Unless we are provisioning a primitive, pilot-type SharePoint application, FBA user accounts will need to be managed by both the administrator and the users themselves. The difficulty is that there is no out-of-the-box facility for that. The ASP.NET Web Site Administration Tool in Visual Studio lets the administrator create and delete users, but that simply doesn’t work for real-world applications. There are two options: installing a SharePoint feature that allows the management of FBA users from within SharePoint; and creating a custom ASP.NET application that handles FBA user management. The SharePoint feature, which is a community project in its pre-beta phase, can save a lot of effort if it works. Building a custom application to manage FBA users, on the other hand, is probably a more suitable long-term solution, but obviously requires extra development effort and may constitute an entire development project in itself.

Conclusion: Need this remain rocket science?
This has been a lengthy discussion even without getting down to the nitty-gritty of the individual how-to steps. It is puzzling why implementers and developers of SharePoint must jump through so many hoops in order to make a SharePoint site available on the Internet when it is just another Web site from a user’s point of view. Would it be too much to expect something remotely simpler than this in the next release or Service Pack of SharePoint?

2008-07-13  »  JK