Programming .NET Components, 2nd Edition

Appendix B. Unifying Windows Forms and ASP.NET Security

By default, .NET role-based security uses Windows user groups for roles and Windows accounts for security identities. There are several drawbacks to this default policy. The security policy is only as granular as the user groups in the hosting domain. Often, you don’t have control over your end customer’s IT department. If you deploy your application in an environment in which the user groups are coarse or do not map well to actual roles users play in your application, or if the group names are slightly different, .NET’s basic role-based security will be of little use to you. Role localization presents yet another set of challenges, because role names will differ between customer sites in different locales. Moreover, using Windows accounts for security identity means role-based security can work only if the users have accounts on the hosting domain or have a trust relationship with the domain that manages the user accounts. Consequently, Intranet applications often resort to storing their user credentials in a database, even when they’re deployed in a homogenous Windows environment. Such applications should use a Windows Forms frontend, and they can be deployed using ClickOnce.

ASP.NET applications accessed over the Internet using a browser hardly ever use Windows accounts and groups. .NET 2.0 provides out-of-the-box custom credential management for ASP.NET applications. In ASP.NET 2.0, you can easily authenticate and authorize ...