第13章成员资格和角色管理.docx
《第13章成员资格和角色管理.docx》由会员分享，可在线阅读，更多相关《第13章成员资格和角色管理.docx（23页珍藏版）》请在冰豆网上搜索。
第13章成员资格和角色管理
第12章成员资格和角色管理
成员资格和角色管理功能的核心是利用自动生成数据库表，多个实现管理功能的API、成员资格和角色管理提供程序，实现模块化和自动化的成员资格和角色管理模式。
具体而言，包括创建和管理用户和角色管理信息、实现对多种数据源中用户和角色信息的管理、验证访问应用程序的用户凭证、支持使用Cookie缓存角色信息实现角色管理和成员资格管理等功能的集成。
12.1身份验证和授权
Web站点创建的页面用于供用户浏览访问。
这些页面可以分为两种类型：
一中是允许所有用户访问，即无论用户身处网络的什么位置，无需用户凭证（如用户和密码）都可以访问页面；另一种是只允许部分用户访问，即所谓的身份验证。
身份验证就是验证标识的过程，即验证某人（或某物）与其声称的人（或物）是否一致。
该人或物称为“当事者”。
身份验证要求证据，称为“凭证”，例如，客户端应用程序可以将密码用作凭证。
所谓授权就是指一旦用户凭证通过验证，就必须确定此用户是否可以访问特定的资源，这个过程称之为授权。
本节主要介绍身份验证概述、Forms验证概述、FormsAuthentication类和用户授权概述。
12.1.1身份验证概述
身份验证是从用户处获取标识凭证（如用户名和密码），并通过某些授权机构验证那些凭证的过程。
如果这些凭证有效，则将提交这些凭证的实体视为通过身份验证。
在身份得到验证后，授权进程将确定该身份是否可以访问指定资源。
ASP.NET2.0身份验证有3种方式，它们分别是Windows验证、Passport验证和Forms验证。
下面将对以上3种验证方法进行详细讲解。
1.Windows验证
在ASP.NET应用程序中，Windows身份验证将MicrosoftInternet信息服务（IIS）所提供的用户标识视为已经通过身份验证的用户。
IIS提供了大量用于验证用户标识的身份验证机制，其中包括匿名身份验证、Windows集成的（NTLM）身份验证、Windows集成的（Kerberos）身份验证、基本（base64编码）身份验证、摘要式身份验证以及基于客户端证书的身份验证。
在ASP.NET中使用WindowsAuthenticationModule模块来实现Windows身份的验证。
该模块根据IIS所提供的凭据构造一个WindowsIdentity，并将该标识设置为该应用程序的当前User属性值。
Windows身份验证是ASP.NET应用程序的默认身份验证机制，并指定作为使用authentication配置元素的应用程序的身份验证模式。
2.Passport验证
Passport身份验证是由Microsoft提供的集中身份验证服务，该服务为成员站点提供单一登录和核心配置文件服务。
Passport之所以让用户受益匪浅，原因在于用户不必登录访问受限制的新资源或站点。
如果希望站点与Passport身份验证及授权兼容，则应该使用该提供程序。
Passport是基于Cookie的身份验证服务。
使用Passport身份验证的示例事务对话的工作方式如下。
（1）客户端向受到保护的资源（如GET请求。
（2）检查客户的Cookie是否具有现有的Passport身份验证票。
如果找到有效的凭据，则站点对该客户进行身份验证。
如果请求不包括有效的身份验证票，则服务器返回状态代码302并将用户重定向到Passport登录服务。
响应在查询字符串中包含一个URL，该URL被发送到Passport登录服务以便将客户定向回原始站点。
（3）客户端执行重定向操作，再向Passport登录服务器发出HTTPGET请求，然后传输来自原始站点的查询字符串信息。
（4）Passport登录服务器向客户提供登录窗体。
（5）客户端填写窗体，并使用安全套接字层（SSL）将POST发送回登录服务器。
（6）登录服务器对用户进行身份验证并将客户重定向回原始的URL。
响应在查询字符串中包含一个加密的PassportCookie。
（7）客户遵循重定向并再次请求原始的受保护资源，这一次使用PassportCookie。
（8）起始服务器上的PassportAuthenticationModule会检测是否存在PassportCookie，并测试身份验证。
如果成功，则该请求通过身份验证。
Passport使用“三重DES”加密方案。
当成员站点注册到Passport服务时，将被授予站点特定的密钥。
Passport登录服务器使用该密钥对站点间传递的查询字符串进行加密和解密。
注意：
若要使用Passport身份验证，在使用前，必须将站点注册到Passport服务，然后接受许可协议并安装.NETPassportSDK。
3.Forms验证
Forms验证是多数Web应用程序使用的身份验证方式。
通过Passport身份验证，可以使用所创建的登录窗体验证用户的用户名和密码。
未经过身份验证的请求被重定向到登录页，用户在该页上提供凭据和提交窗体。
如果应用程序对请求进行了验证，系统会颁发一个票证，该票证包含用于重建后继请求的标识的密钥。
12.1.2Forms验证概述
ASP.NET1.x技术支持Forms验证方式，关键基于Cookie来实现用户身份验证。
然而，某些浏览器并不支持Cookie，或者用户关闭了浏览器中对Cookie的支持功能，那么ASP.NET1.x将无法使用Forms方式实现身份验证。
为此，ASP.NET2.0还保留了对基于Cookie实现身份验证的支持。
Forms身份验证提供了一种方法，可以使用自己的代码对用户进行身份验证，然后将身份验证标记保留在Cookie或页的URL中。
Forms身份验证通过FormsAuthenticationModule参与ASP.NET页的生命周期。
可以通过FormsAuthentication类访问Forms身份验证信息和功能。
若要使用Forms身份验证，可以创建一个登录页。
该登录页既收集了用户的凭据，又包含验证这些凭据时所需的代码。
如果这些凭据有效，可以调用FormsAuthentication类方法，以便使用适当的身份验证票证（Cookie）将请求重定向到最初请求的资源。
如果不需要进行重定向，只需获取Forms身份验证Cookie或对其进行设置即可。
使用authentication配置元素对Forms身份验证进行配置。
最简单的情况是，在Web.config文件或单独的文件中，可以通过指定的URL将未经身份验证的请求重定向到某个登录页，然后提供该登录页的最小实现，并提供有效的凭据。
代码14-2演示配置文件的一部分。
该配置文件为Authentication方法指定了登录页和身份验证凭据。
密码已经使用HashPasswordForStoringInConfigFile方法进行加密。
成功通过身份验证之后，FormsAuthentication模块将会使用经过身份验证的用户信息填充当前的User属性。
代码14-3演示的是如何以编程方式读取经过Forms身份验证的用户的标识。
Forms有关的配置信息都被保存在Web.config文件中，所有与Forms验证有关的设置都放置在配置节中，因此，了解配置节的内容有助于更好的应用Forms验证。
下面应用一个实例说明配置节，代码如代码14-4所示。
在代码14-4中，设置Forms验证的前提是将中的mode属性设置为Forms，然后才能设置设置节内容。
配置节包含了多个属性和一个配置节。
代码中的path属性是为由应用程序发出的Cookie指定路径。
该默认值是正斜杠，因为大多数浏览器是区分大小写的。
所以，如果大小写不匹配，则将不发送回Cookie；protection属性是指定Cookie使用的加密类型；requireSSL属性用于指定是否需要安全套接字层（SSL）连接来传输身份验证Cookie，它一个布尔值；slidingExpration属性用于指定是否启用弹性过期时间，它也是一个布尔值；Timeout属性是用于指定一整数分钟为单位的时间，超过此时间，Cookie将过期，默认值是30。
如果slidingExpration的属性为True，则Timeout属性是一个启用Cookie警告的用户显示多个浏览器警告，在经过了超过了一般的时间后更新该Cookie。
这可能导致精确性上的损失。
持久性Cookie不超时；defaulturl属性是用于指定用户验证之后默认定向的URL地址，默认值为defalult.asp。
domain属性是用于指定在传出Forms身份验证Cookie中的设置的可选域；Cookieless属性是用于指定是否使用Cookie以及使用Cookie的方法，其中包括4个可选项，即UseCookie、UseuUri、AutoDetect和UseDeviceProfile选项。
EnablecrossAppRedirects属性是用于指定是否需要将通过身份验证的用户重定向到其他Web 应用程序的URL。
12.1.3FormAuthentication类
Forms身份验证使不要求Windows身份验证的Web应用程序可以进行用户和密码的验证。
使用Forms身份炎症时，用户信息存储在外部数据源中，如果Membership数据库，或存储在应用程序的配置文件中。
在用户通过身份验证后，Forms身份验证即会在Cookie或URL中维护一个身份验证票证，这样已通过身份验证的用户就无需在每次请求时都提供凭据了。
可通过将authentication配置元素的mode属性设置为Forms来启用Forms身份验证。
通过使用authentication配置元素可要求所有对应程序的请求均包含有效的身份验证票证，从拒绝任何未知用户的请求，如代码14-5所示
在代码14-5中，对作为应用程序的一部分的ASP.NET页的任何请求都需要Forms身份验证提供的有效用户名。
如果用户名不存在，则请求重定向到所配置的LoginUrl。
FormsAuthentication类提供了相应的方法和属性，可以在需要对用户进行身份验证的应用程序中使用它们。
RedirectToLoginPage方法将浏览器重定向到已配置的LoginUrl。
以便用户可以登录到应用程序。
RedirectFormLoginPage方法将通过身份验证的用户重定向回最初请求的受保护URL和DefaultUrl。
如果需要，还可以使用其他方法来管理Forms身份验证票证。
下面首先对FormsAuthentication类的属性和方法进行讲解。
1.FormsAuthentication类的属性
FormsAuthentication类的属性如表12-1所示。
FormsAuthentication类的属性与Web.Config文件中配置节的属性有着对应关系。
FormsAuthentication类的属性
属性
说明
CookieDomain
获取Forms身份验证Cookie的域的值
CookieMode
获取一个值，该值指示是否已将应用程序配置为进行无Cookie的Forms身份验证
CookiesSupported
获取一个值，该值指示是否已将应用程序配置为支持无Cookie的Forms身份验证
DefaultUrl
获取在没有指定重定向URL时FormsAuthentication类将重定向到的URL
EnableCrossAppRedirects
获取一个值，该值指示是否可以将经过身份验证的用户重定向到其他Web应用程序的URL
FormsCookiesName
获取用于存储Forms身份验证票证Cookie名称
FormsCookiesPath
获取Forms身份验证Cookie的路径
LoginUrl
获取FormsAuthentication类将重定向到的登录页的URL
RequireSSl
获取一个值，指示Forms身份验证Cookie是否需要SSL以返回到服务器
SlidingExpration
获取一个值，它指示是否启用可调过期
如表12-1所示，FormsAuthentication类中包含多个属性，利用这些属性，可以很轻松地获得应用程序对Forms验证的配置信息。
其中包含6个ASP.NET2.0中新增的属性，他们分别是CookieDomain、CookiesSupported、DefaultUrl、EnableCrossAppRedirects和LoginUrl属性。
2.FormsAuthentication类的方法
表12-2是FormsAuthentication类的常用方法列表，通过调用这些方法，能够对Forms验证实现管理。
方法
方法
说明
Authenticate
对照存储在应用程序配置文件中的凭据来严整用户名和密码是否有效，如果有效，则返回值是True，否则为False
Decrypt
创建一个FormsAuthenticationTicket对象，此对象将根据传递给该方法的加密的Forms身份验证票证而定
Encrypt
创建一个字符串，其中包含适用于HTTPCookie的加密的Forms身份验证票证
GetAuthCookie
为给顶的用户名创建身份验证Cookie，这不会将Cookie设置为传出响应的一部分，因此应用程序对如何发出该Cookie有更多的控制权限
GetRedirectUrl
返回导致重定向到登录页的原始请求的重定向URL
HashPasswordForStoringInCongigFile
根据指定的密码和哈希算法生成一个适用于存储在配置文件中的哈希密码
Initialize
根据应用程序的配置设置初始化FormsAuthentication对象
RedirectFormLoginPage
将经过身份验证的用户重定向回最初请求的URL或默认的URL
RedirectToLoginPage
将浏览器重定向到登录的URL
RenewTicketIfOld
有条件的更新FormsAuthenticationTicket的发出日期和时间以及过期日期和时间
SetAuthCookie
以重载。
为提供的用户名创建一个身份验证票证，并将起添加到响应的Cookie集合中
SignOut
从浏览器删除Forms身份验证票证
表12-2介绍了FormsAuthentication类的一些常用方法。
12.1.4用户授权概述
用户授权是指确定经身份验证的用户是否可以访问请求资源的过程。
在ASP.NET中，主要包括以下几种授权方式。
1.基于角色
用户被划分为应用程序定义的逻辑角色。
在应用程序中，某一特定的角色的成员将共享相同的权限。
对操作（通常由方法调用表示）的访问是根据调用方的角色成员身份进行授权的。
使用固定标识（如Web应用程序或Web服务的进程标识）访问资源。
资源管理器信任应用程序可以正确授权用户，并且它们将权限授予“受信任”的标识。
对操作（通常是方法）的访问权限是根据调用方的角色成员身份来提供的。
使用角色将应用程序的用户群分为在应用程序内共享相同的权限的用户组，如“高级经理”“经理”和“职员”。
用户被映射到角色，如果用户有权执行所请求的操作，那么应用程序将使用固定标识访问资源。
这些标识被各自的资源管理器（如数据库、文件系统等）所信任。
2.基于资源
单个的资源是通过来提供保护的。
在应用程序在访问资源之前先模拟调用方，这使操作系统可以执行标准访问检查。
对资源的所有访问都是使用原调用方的安全性上下文执行的。
此模拟方法严重影响应用程序的可伸缩性，因为着意味着在应用程序的中间层无法高效地使用连接池。
对于绝大多数在伸缩方面有很高要求的.NETWeb应用程序来说，基于角色的授权方法是最佳的选择。
而对于某些规模较小的Intranet应用程序，如果他们所提供的各自内容来自可通过对单个用户执行WindowsACL检查来说提供访问权限的资源（如文件），则可以采用基于资源的授权方法。
在Web.Config文件配置用户授权的节点的属性列表的常用属性如表14-3所示
表12-3节点的常用属性
属性
说明
Users
表示允许的用户，还有两种特殊的用户，即所有用户（*）和匿名用户（？
）
Roles
指允许或者拒绝访问资源的角色。
允许使用逗号分隔的列表来引用多个角色
verbs
定义操作所应用到的HTTP提交方式，常用的有get、post和head默认值为“*”，表示支持所有的HTTP提交方式
基于角色：
在基于角色（或操作）的安全方法中，对操作（而非后端资源）的访问是根据调用方的角色成员身份进行授予的。
角色（在设计应用程序时进行分析并加以定义）被用作逻辑容器，他们将应用程序中同一安全权限（或功能）的用户集合在一起。
用户被映射到年应用程序的角色。
而角色成员身份用来控制对应用程序公开的特定操作（方法）的访问权限。
在应用程序的什么位置映射角色是设计中应该考虑的一个关键因素。
第一种情况是，可以在后端资源管理器（如数据库）中映射角色。
它要求将原调用的方的安全性上下文通过应用程序的各层一直传递到后端数据库。
另一种情况是在前端Web应用程序中映射角色。
如果是运用这种方法，那么就要通过固定标识来访问下游资源管理器，而这些资源管理器对这些标识进行了授权并愿意信任它们。
第三种选择是在前端层和后端层之间的某个位置进行角色映射，如在中间层企业服务应用程序中。
在多层Web应用程序中，使用受信任的标识访问后端资源管理器为应用程序的伸缩性提供了更多的机会（这得归功于连接池）。
另外，使用受信任的标识减少了在操作系统级传递原调用方安全性上下文的需要，而这本来可能是不太可能的（即使可能，也是很难）实现的。
下面应用一个简单的示例说明一下，代码如代码16-4所示
基于资源的授权方法依赖WindowsACL和操作系统的基本访问控制机制。
应用程序模拟调用方，将执行访问检查的任务留给了与特定资源管理器（如文件系统、数据库等）关联的操作系统。
这种方法通常最适用于利用它们来访问可通过WindowsACL加以个别保护的资源（如文件资源）。
FTP应用程序或简单数据驱动Web应用程序就属于这类应用程序。
如果被请求资源中的数据需要从多个不同来源（如多个数据库、数据库表、外部应用程序或Web服务等）获取和合并，那么这种方法就显得力不从心了。
基于资源的方法还依赖传递到应用程序后端资源管理器的原调用方的安全性上下文。
这可能需要进行复杂的配置，而且会大大降低多层应用程序增加受访的能力，因为使用这种方法就无法在应用程序中间层有效运用集合功能（如数据库连接池）。
下面应用一个简单的示例说明一下，代码如代码16-5所示
在实现用户授权过程中，应该遵循以下两个应用原则。
一是位于较低目录级别的配置文件中包含的原则，优先于较高目录级别的规则。
二是对于给定的URL的一组的合并规则，系统从列表的头开始，检查规则直到找到第一个匹配项为止。
12.2成员资格管理
ASP.NET成员资格可以验证和管理Web应用程序的用户信息。
它提供验证用户凭据、创建和修改成员资格用户及管理用户设置（如密码和电子邮件地址）等功能。
ASP.NET成员资格主要用于ASP.NETForms身份验证，但也可以在ASP.NET应用程序的任意位置使用。
ASP.NET成员资格可以将用户信息保存在所选资源中，同时，还可以管理应用程序的用户身份验证。
由于有成员资格数据源的ASP.NET成员资格用户提供程序，为此，不需要大量代码来读写成员资格信息。
ASP.NET成员资格主要有内置成员资格提供程序组成，这些提供程序与数据源及公开其功能的membership静态类进行通信。
从ASP.NET代码调用membership类以执行用户验证和管理。
membership类是ASP.NET2.0中新增的类（同时还有MembershipUser类）。
成员资格提供程序，实现了模块化和自动化的成员资源管理模式。
本节将详细讲解Membership类、MembershipUser类以及成员资格管理功能的核心内容。
12.2.1成员资格管理概述
ASP.NET成员资格提供了一种验证和存储用户凭据的内置方法。
因此，ASP.NET成员资格可帮助管理网站中的用户身份验证。
可以将ASP.NET成员资格与ASP.NETForms身份验证或ASP.NET登录控件一起使用以创建一个完整的用户身份验证系统。
1.ASP.NET成员资格支持的功能
ASP.NET成员资格支持的功能如下：
（1）创建新用户和密码
（2）将成员资格信息（用户名、密码和支持数据）存储在MicrosoftSQLServer、ActiveDirectory或其他数据存储区。
（3）对访问站点的用户进行身份验证。
可以以编程方式验证用户，也可以使用ASP.NET登录控件创建一个只需很少代码或无需代码的完整身份验证系统。
（4）管理密码，包括创建、更改和重置密码。
根据选择的成员资格选项不同，成员资格系统还可以提一个使用用户提供的问题和答案的自动密码重置系统。
（5）公开经过身份验证的用户的唯一标识，可以在自己的应用程序中使用该标识，也可以将该标识与ASP.NET个性化设置和角色管理（授权）系统集成。
（6）指定自定义成员资格提供程序，这时可以改为用自己的代码管理成员资格及自定义数据库存储中维护成员资格数据。
2.成员资格的工作管理
若要使用成员资格,必须首先为站点配置成员资格,主要步骤如下：
（1）将成员资格选项指定为网站配置的一部分。
默认情况下，成员资格处于启动状态。
还可以指定要使用哪个成员资格提供程序。
（实际上，这意味着指定要存储成员资格信息的数据库的类型。
）默认提供程序要使用MicrosoftSQLServer数据库。
还可以选择使用ActiveDirectory存储成员资格信息，或者可以指定自定义提供程序。
（2）将应用程序配置为使用Forms身份验证（与Windows或Passport身份验证不同）。
通常指定应用程序中的某些页或文件夹受到保护，并只能由经过身份验证的用户访问。
（3）为成员资格定义用户帐户。
可以通过多种方式执行此操作。
可以使用网站管理工具，该工具提供了一个用于创建新用户的类似向导的界面。
或者，可以创建一个“新用户”ASP.NET网页中收集用户名和密码（及电子邮件地址（可选）），然后使用一个名为GreateUser的成员资格函数在成员资格系统中创建一个新用户。
现在，可以使用成员资格对应用程序中的用户进行身份验证。
大多数情况下，将需要提供一个新的登录窗体，它可能是一个单独页或主页上的一个专业区域。
可以使用ASP.NETTextBox控件手动创建登录窗体，也可以使用ASP.NET登录控件。
由于以将应用程序配置为使用Forms身份验证，因此在未经验证的用户请求一个受保护的页面时，ASP.NET将自动显示登录页。
注意：
ASP.NET登录控件（Login、LoginView、LoginStatus、LoginName和PasswordRecovery）实际上封装了提示用户输入凭据及验证成员资格系统中的凭据所需要的所有逻辑。
如果使用登录控件，它们将自动使用成员资格系统验证用户。
如果已手动创建了一个登录窗体，可以提示用户输入用户名和密码，然后调用ValidateUs
升级会员 