正确设计的授权机制使系统更易部署和治理。基于Active Directory等企业身份验证机制来授权，你的应用程序就能与公司现有的安全策略无缝地集成。在n层应用程序中，每一层都可使用授权，从而创建出更灵活的系统。
在表示层，你可基于授权用户的“角色”来自定义用户界面（例如，为治理阶级的用户显示治理菜单，但在普通用户面前隐藏此菜单）。在业务层，可考虑在代码主体中验证授权，这就使黑客或其他非法用户不易在未经正确授权的情况下使用一个代码小节。在数据层，通过在检索或插入数据之前请求授权，可确保只有合法用户才能更改数据。
授权类型
.NET系统主要运行3种授权类型：Windows授权、代码访问安全性（Code Access Security，CAS）授权或者应用程序专用授权。综合运用这些授权机制，就能创建一个非常安全的系统。下面让我们具体讨论它们。
Windows授权
利用访问控制列表（Access Control Lists，ACL）来设置权限，系统治理员可控制哪些用户有权访问特定的系统资源。通常要由运行应用程序的那个系统的治理员来控制这些设置。由于生产环境和测试/认证环境中的治理员通常是不同的人，所以必须正确文档化特定的授权设置，确保应用程序最终能正确运行。这些设置包括：
Active Directory权限
NTFS治理的文件权限
Web Config设置，它为基于Asp.Net的应用程序限制对特定URL的访问
服务器产品的特有权限，产品包括Microsoft SQL Server（例如表、视图或存储过程）或者Microsoft Exchange（例如邮箱、公共文件夹等）
CAS授权
Windows授权限制对单个对象的访问。相反，CAS授权答应应用程序根据一系列批准的权限（名为权限集）来执行。这些权限集是基于“凭证”（evidence）而建立的，包括代码的来源、它的出版商及其“强名称”。必须注重到，CAS授权独立于其他任何授权机制运行，这样可有效保护系统资源，无论用户被验证成什么身份。
例如，假定一个权限集禁止来自因特网的代码删除用户机器上的文件，那么这个限制将永远有效，无论用户的身份被验证成“系统治理员”，还是验证成“来宾”。可用CASPol.exe命令行实用程序来配置CAS授权，或使用Microsoft .NET Framework Configuration控制台来配置（后者通过控制面板的“治理工具”来访问）。
应用程序专用授权
即使Windows授权用户执行一个操作，而且正在执行的代码具有恰当的权限，但它们还要通过第3道关卡的考验——你的应用程序可决定是否授权特定用户执行操作。通过创建应用程序专用的一个授权框架，就可根据用户的身份验证主体（authenticated principal）来响应不同的用户，并进一步控制用户有权采取的操作。这种授权机制主要用于治理或限制对特定应用程序资源的访问，或根据通过身份验证的主体来强制不同的业务规则。
我在自己的Web和Windows应用程序中广泛运用了应用程序专用授权。在Web应用程序中，我通常用它动态生成菜单，使用户只看到他们有权看到的选项。对于Windows应用程序，我将授权代码嵌入业务逻辑中，防止用户执行需要更高级授权的代码。为了有效地使用和治理授权，你需要一个公共场所来存储权限，而且要采取一种方式为用户分组。这样一来，一旦权限需要更改，就不必单独配置每个用户。
“角色”的作用
.NET框架答应你对一个用户组授权，利用“角色”为组内的所有用户指派相同的安全权限。由于治理的是“角色”而非单独的用户，所以当用户四处移动时，你的应用程序无需改变。另外，假定你治理的是5个角色，而不是500名用户，那么花在治理应用程序上的时间明显少得多。使用Active Directory来存储身份验证信息，你的.NET应用程序就能自动使用Active Directory中内建的用户和角色能力。此外，使用与SQL Server集成的安全机制，可以扩展这些角色，将权限关联到SQL Server对象，从而将安全性提升到一个新台阶，而且无需额外的编码。
即使决定不使用Active Directory，也可直接针对IPrincipal对象和IsInRole方法来编程，从而指派来自外部存储（例如SQL数据库表、XML文件或者使用套接字等接口的一个外部系统）的角色，并验证角色的成员关系。
授权是任何.NET系统的要害设计元素。理解了3种主要的授权类型后，你可在设计自己的系统时选用其中的一种或者多种。
