Datasheet

Figure 1-6
Within the area of user management, some other features of SharePoint have also migrated into
ASP.NET 2.0. Within SharePoint, it’s possible for authorized users to create new SharePoint sites, new
users, new pages, and perform other administrative tasks.
In ASP.NET 2.0, as part of the personalization framework, it’s possible to implement user management
functions within the site itself (although you still can’t create a whole new Web site from within an
application). ASP.NET even comes with a set of pre-defined user administration pages that you can
incorporate into your site.
Logging in is more than just assigning identities. For sites that have a small number of users, implement-
ing personalization on an identity-by-identity basis is a viable choice. However, as the number of
identities increases, the costs of maintaining personalized information increases. While costs increase
with the number of identities, the benefits of personalization don’t increase. In all likelihood, the cus-
tomizations made for one identity will be applicable to other identities. In any user community, you can
probably break your user community up into several groups. This can be handled by assigning individual
users to roles and implementing customizations on a role-by-role (group) basis. As a result, you need a
mechanism that not only assigns identities to users but also assigns users to roles.
The next component of the personalization framework, the membership provider, handles this. The
membership provider is the glue that binds the site to the users that access the site and binds the site’s
functionality to the various user roles. Membership providers also handle all the tasks around storing
user and role information. Two membership providers come with ASP.NET 2.0: one for storing informa-
tion in Microsoft SQL Server and one for storing information in a Jet database. If you want, you can even
build your own membership provider to connect to other data stores.
A provider is a component that extends or replaces some existing ASP.NET function. Any part of
ASP.NET that is implemented through a provider model can be enhanced or replaced with a provider
written by you (or some third party, such as IBM’s Tivoli for transaction management). Once you have
built a new provider, you plug it in to the list of available providers and select it when you build your
application (which is why providers are said to be “pluggable”). The main requirement of a provider is
that it has to reproduce the interface (methods, properties, events) for the provider that it extends or
replaces. However, what happens behind that interface is up to the developer that creates the provider.
20
Chapter 1
05_57860x ch01.qxd 10/4/05 9:26 PM Page 20