One of the biggest improvements in Windows SharePoint Services 3.0 is the fact that it is built on top of ASP.NET 2.0. This enables SharePoint sites to use the membership provider model that abstracts the identity and authentication store away from application and makes it more pluggable. In addition, in Windows SharePoint Services 3.0, administrators can now create multiple entry paths into a SharePoint site collection, with each one having its own authentication configuration.
Creating multiple authentication mechanisms requires no code; it requires only configuration changes within the Web.config file of the SharePoint Web application and also a few modifications from within the Central Administration site. Developers are free to create custom authentication providers when one of the included providers does not satisfy the requirements. In this Microsoft Office Visual How To, a site collection is configured with two entry points, each using a different authentication mechanism. One entry point uses the default Windows authentication, and the other uses forms-based authentication that stores the user and role information in a Microsoft SQL Server database.
First, you create a new site collection in a new Web application. This Web application uses Windows authentication. Next, you create a second Web application by extending the first Web application. This second Web application is configured to use forms-based authentication. There are now two paths and two URLs, providing entry points into the same site collection.
Updating the Web.config File for Forms-Based Authentication
The next step in creating a new authentication mechanism is to add new membership and role providers to the Web application's Web.config file. These two providers should go inside the <system.web> node, as shown in the following code.
System.Web, Version=184.108.40.206, Culture=neutral,
<!-- role provider -->
<roleManager enabled="true" defaultProvider="LitwareFbaSqlRoleProvider">
Version=220.127.116.11, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Both providers use the ASP.NET 2.0 SQL Server database that contains the user authentication information. Thus they point to a connection string that you must add to the <ConnectionStrings> section in the Web.config file.
connectionString="server=LitwareServer; database=LitwareFBA; Integrated Security=SSPI;"
You must implement these changes in the Web.config files for both Web applications that act as entry points to the site collection (even the Web application that uses Windows authentication), and also in the Web.config file for the Web application that hosts Central Administration. The only difference is that you must set the default role provider (specified on the opening <RoleManager> node) to AspNetWindowsTokenRoleProvider. This is because Central Administration must always use Windows authentication as the primary authentication mechanism.
Configuring the Web Application to Use the New Providers
Follow these steps to configure the Web application.
To configure the Web application to use new providers
Browse to Central Administration, and click the Application Management tab.
In the Application Security section, select Authentication Providers.
Change the Web application to be the URL of the primary Web application, and then select the zone selected when you extended the second Web application.
Change the authentication type to Forms.
Set the membership provider and role provider to the values specified in the Web.config file: LitwareFbaSqlMembershipProvider and LitwareFbaSqlRoleProvider.
The second Web application is now configured for forms-based authentication, providing two entry points with different authentication mechanisms into the same site collection.
Now that Windows SharePoint Services 3.0 supports multiple authentication mechanisms for the same site collection, administrators can offer site collections to a broader audience. For example, you can use a site collection as a client-facing extranet. One entry point is provided to company employees, forcing them to use their Active Directory Domain Services (AD DS) credentials, and another entry point is provided that authenticates the client against a custom SQL Server database. This enables administrators to keep the corporate AD DS clean and secure without adding accounts for non-employees.
Watch the Video
Length: 12:50 | Size: 10.0 MB | Type: WMV