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 users without ever resorting to Windows accounts. In addition, the credentials store is well-designed, using the latest best practices for credential management (password salting, secure stored procedures, and so on). This infrastructure provides a high-quality, secure solution and helps productivity, saving ASP.NET developers valuable time and effort.

This appendix presents a set of interacting helper classes that enable a Windows Forms-based Intranet application to use the ASP.NET credential-management infrastructure with the same ease as if it were an ASP.NET application. Doing so provides Windows Forms-based Intranet applications with the same productivity benefits as those enjoyed by ASP.NET applications, and it offers a unified credentials store regardless of the application user interface.

One of the hallmarks of a well-designed middle tier is that it can be accessed uniformly by any frontend, such as a browser, a web service, or a Windows Forms application. Providing a unified solution decouples your business logic components from your presentation tier, so you can switch frontends at will. You will also see that providing a custom credential-management solution requires a holistic approach that takes into account the application deployment and code access security needs, as well as scalability, extensibility, design-time integration, and reuse contexts. This appendix also makes use of some little-known yet very useful .NET programming techniques as well as best practices mentioned throughout this book.