ASP.NET: 验证与授权完全解析
例如博客园, 它允许未注册的匿名用户可能查看帖子, 但是不允许他们发表帖子. 为了能够发表帖子, 匿名用户必须先注册为正式用户. 在注册为正式用户的过程中, 通常需要如下一些共通的步骤.
(1). 建立一个 Users数据表来存放注册用户的信息.
(2). 建立一个注册页面 (Register.aspx)让匿名用户注册.
(3). 建立一个登录页面 (Login.aspx)让注册用户登录系统.
(4). 建立一个机制记录住用户状态, 这样当用户发帖或者回复时不用再次登录.
但是仅仅验证了用户还不够, 系统还需要获取用户所具有的权限, 也就是注册用户可以做什么, 不可以做什么. 仍以博客园为例, 大家都知道, 同样是注册用户, 版主可以修改他人的帖子, 而系统管理员又可以任命各个版块的版主. 为了实现这种功能就需要引入权限管理, 通常需要如下一个些共通的步骤:
(1). 建立一个 Roles 表存储用户的角色 (例如管理吊, 版主等).
(2). 建立一个 Users-Roles 表映射管理对用户的管理.
(3). 建立一个管理员页面, 以便让管理员对用户进行设置.
(4). (不是必须的), 可能需要一个邮件发送页面, 这样当用户在密码丢失后可以找回密码.
看来验证和授权有着某种 "暧昧"的关系, 这里就先从验证开下手吧.
一. 身份验证: 简单的讲, 就是系统需要采用什么样的一种方式来验证. ASP.NET提供了3种用户验证模式, 分别是 Windows ( 使用直接通过 IIS 提供的身份验证), Forms 窗口验证 ( 使用应用程序特定的逻辑进行验证 )和 Passport护照验证(由 Microsoft提供的集中身份验证服务).
身份验证模式在 web.config中指定.语法如下:
<authentication mode= " windows | Forms | Passport | Node ">
</authentication>
由于平时用的较多的为窗体验证模式 ( Forms), 这里就 forms验证作一详细的分析 .
窗体验证将登录信息记录在 Cookies 中, 一般情况下我们都会在此设置中将未通过验证的用户重定向到登录界面.
Forms验证常用的属性有:
(1). loginUrl: 如果找不到任何有效的身份验证 Cookie, 将请求重定向到用户登录的 URL.
(2). Name: 指定要用户身份验证的 HTTP Cookie. 如果正在一台服务器上运行多个应用程序且每个应用程序都需要唯一的 Cookie, 则必须在每个应用程序的 web.config文件中配置 Cookie名称. 默认为 ".ASPAUTH".
(3). Path: 为应用程序发出的 Cookie 指定路径.默认是斜杠 ( / ), 注: 要区分大小写.
(4). Protection : 安全设置.
(5). Timeout: 指定 Cookie 过期的时间.
这里以一个简单的例子更进一步说明上面的属性是如何应用的.
<authentication mode= "Forms ">
<forms name=".MyCookie" longinUrl="Login.aspx" protection ="All" timeout="30" path= "/">
<credentials passwordFormat="Clear">
<user name="admin" password="amdin" />
<user name="A" password="a" />
</credentials>
</forms >
</authentication>
<authorization>
<deny users=" ?" /> //授权管理, 后面马上讲到.
</authorization>
这样我们基本上完成了一个最简单的验证, 下面将与验证结合来分析授权管理.
二. 授权管理: 授权决定了是否应授予某个标识对特定资源的访问权限. 即你有无权限访问某一个网页或某一类网页. 在ASP.NET中, 有两种方式来授予对给定资源的访问权限.
1. 文件授权: 文件授权由 FileAuthorizationModule 执行. 它检查 .aspx 和 .asmx 处理程序文件的访问控制列表 ( ACL), 以确定用户是否该具有对文件的访问权限. ACL 权限用于验证用户的 Windows 标识 ( 如果已雇用 Windows 身份验证 ) 或 ASP.NET 进程的 Windows 标识. 这种方式在平时的设计中用到的机率一般不大.
2. URL授权: URL授权也是我们最常用的也一种授权方式. 由 UrlAuthorizationModule 执行, 它将用户和角色映射到 ASP.NET 应用程序中的 URL. 这个模块可用于有选择允许或拒绝特定用户或角色对应用程序的任意部分 ( 不过, 一般都选择目录作为授权对象) 的访问权限.
下面我们就重点来分析 URL授权方式.
(1). 通过 URL 授权, 可以显式允许或拒绝某个用户名或角色对特定目录的访问权限.为此, 在该目录的配置文件中需要创建一个 authorization 节. 若要启用 URL 授权, 就在配置文件 authorization 节中的 allow 或 deny 元素中指定一个用户或角色列表. 为目录建立权限也会应用到到子目录, 除非子目录中的配置文件重写这些权限.
(2). Authorization 节的定义较为简单, 语法如下:
<authorization>
<[ allow | deny ] user /roles/verbs />
</authorization>
其中 allow或deny 元素是必须的. Allow 和 deny 元素分别授予访问权限和撤销访问权限.
(3). Allow 和 deny 元素支持的属性有 user, roles, verbs. 解释如下:
Users 属性: 标识 allow或 deny元素的目标身份(即我们常叫的用户账户), 具体定义为用问号 (?) 标识匿名用户, 用星号(*)指定所有经过身份验证的用户.
Roles: 为被允许或被拒绝访问资源的当前请求标识一个角色 , 即某一类用户是否被允许进入某一个网页或某一类网页.
Verbs: 定义操作所要应用到的 HTTP 谓词, 如GET, HEAD, POST等. 默认为*, 指定所有谓词.
(4). 以例为例: 下面的操作对 用户A 和 Admins 角色的用户授予访问权限. 同时对 B ( 注: 如果 B用户属于 Admins 角色则具有访问权限 ) 和所有匿名用户拒绝访问权限.
<authorization>
<allow users="A" />
<allow roles="Admins" />
<deny urses="B" />
<deny users=" ? " />
</authorization>
到此...
希望对初学者有所帮助.
