Security in Windows SharePoint Services 3.0

Authentication in WSS 2.0 was based on Windows accounts and their associated Security IDs (SIDs). In a practical sense this meant that WSS 2.0 was tightly coupled with Active Directory^® when used in anything but the smallest deployments. This dependency wasn’t a problem for companies that deployed Active Directory when they started using WSS 2.0 and SharePoint Portal Server 2003 for building intranet-based solutions. But for companies building extranet-based solutions, it was far more challenging. The tight coupling of WSS to Active Directory forced companies to create and maintain domain accounts for non-company users such as venders and customers.

All this changes with WSS 3.0 because authentication has been redesigned on top of the new authentication provider infrastructure introduced with ASP.NET 2.0. If you don’t want to maintain user accounts for WSS and MOSS 2007 sites inside Active Directory, you simply build or acquire an ASP.NET authentication provider that’s been designed to store and manage user accounts in a different identity repository.

For example, ASP.NET 2.0 ships with the forms authentication provider that allows you to maintain user accounts inside a SQL Server database. This authentication provider can be configured for use in a WSS site. With little effort, you can put a WSS site on the Internet that allows unknown users to register themselves as members. ASP.NET 2.0 provides convenient support for creating and maintaining user accounts and even allows users to change and reset their passwords.