.net from身份验证的配置介绍
1、关于登陆验证和授权
很多网站都有登陆对话框，让事先已经注册的用户验证，以便为他们提供个性化的服务等。可以把这个过程看作是两件事情的发生：验证和授权！登陆的作用是验证请求登陆的用户是否合法，而授权则是验证合法的用户在请求资源时，根据他们的权限决定是访问还是拒绝。
以上这种网站本身提供对话框的作法在.NET中被称之为Forms验证模式，接下来将会讲述这种验证模式。在以前ASP陈序员或者其他程序员，要想保存合法用户的验证，在以后的访问授权中使用，不得不使用写Cookie或者将信息保存在Session中的方法，而在需要授权的页面加载前添加一堆繁琐的代码来验证制定的用户是否具有访问权限否则的话就不能显示页面的内容，最恼火的是在授权页面上添加这些代码让人觉得重复和繁琐，而且可能不是最安全的，有一些比较隐蔽的方式可能会轻易绕过这种验证，因此程序员将来要做的很多事情就是再修改代码已堵住在运行过程中才发现的漏洞。在.NET的System.Web.Security中提供了一些网站安全方面的解决方案，尽管验证用户合法和授权的基本思路没有变化，但是授权的工作几乎已经交给.NET框架了，我们些代码之需要自己验证用户合法，并且告诉框架这个用户合法即可。
2、使用Forms验证模式
要使用启用Forms验证模式，请在网站根目录下的web.config文件中添加如下配置：（注意区分大小写）
程序代码：
<forms name="kcs"loginUrl="~/login.aspx"defaultUrl="~/XXX/Admin_Index.aspx"slidingExpiration="false"path="/"protection="All">
</forms>
</authentication>
这将告诉.NET，你的网站使用Forms验证模式，.NET将不参与验证用户的工作，而是将这个工作交给你完成，你必须自己编写一些代码来验证用户合法，并且报告给.NET用户是合法的。.NET将会发送一个验证Cookie到用户，随后的访问中，.NET以此Cookie为依据，来执行授权的操作。
例如我们在login.aspx界面中放置两个接受输入的文本框txtUserName和txtPassword，在数据库中，保存了用户名UserName和密码UserPassword，使用btnLogin按钮的Click事件来验证用户：
程序代码：
{
stringsql ="SELECT userid FROM Users WHERE UserName = '"+txtUserName.Text.Replace("'","_") +"' AND UserPassword = '"+System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(txtPassword.Text, "md5") +"'";
//使用上面类似的SQL语句向数据库执行查询，如果用户是合法的，将会返回数据。
if(...) //根据条件判定用户是合法的
{
//下面的语句告诉.NET发送一个验证Cookie给用户：
System.Web.Security.FormsAuthentication.SetAuthCookie(userid, false)
Response.Redirect("afterlogin.aspx"); //定位到登陆后页面
}
else
{
//用户不合法，提示错误信息
}
}
以上代码中，
txtUserName.Text.Replace("'","_")将用户输入的文本中单引号替换为下划线，以防止SQL注入攻击。
System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(txtPassword.Text, "md5")方法将txtPassword.Text转换为MD5散列值，注意，在用户注册的时候，同样使用此方法将其输入的注册密码转换为散列值存储在数据库中，这里将用户输入的散列值进行对比以决定是否合法用户。任何时候不要将敏感的文本信息以明文方式存放在数据库中。通过MD5加密，即便此密文被截获，攻击者仍无法获得真实的密码。
当确认用户验证是合法的，则调用System.Web.Security.FormsAuthentication.SetAuthCookie(userid, false)方法，发送验证Cookie，此方法传递两个参数，一个是代表用户的标示，一般来说，在接下来确认用户唯一身份的就是从数据库中获得的userid。第二个参数告诉.NET是否写入持续的Cookie，如果为true，则Cookie将被持续，下次用户再次访问时，Cookie仍存在（相当于记住用户，可以提供这样的复选框让用户来决定是否持续Cookie）。发送了Cookie后，即可调用跳转语句跳转到指定地方。
另外还有一个方法：Web.Security.FormsAuthentication.RedirectFromLoginPage(string UserName, bool);将发送Cookie，并且根据传递的ReturnUrl参数来跳转到指定的页面（相当于将上面的两个步骤合为一步）。因此login.aspx隐含可以传递ReturnUrl，如果没有这个参数，这个方法将用户跳转到Default.aspx页。
3、授权资源的访问
一旦验证了用户合法，接下来要做的事就是对于用户请求的资源，授权他们是否能够访问。重新回到web.config文件中，在网站的任何目录中都可以使用web.config，他们的设置是传递继承的。
例如在users目录中存放的均是当用户登录后才能访问的页面，则在这个目录中创建一个web.config文件，内容如下：
程序代码：
<configuration>
<system.web>
<!--授权
此节设置应用程序的授权策略。可以允许或拒绝不同的用户或角色访问
应用程序资源。通配符: "*" 表示任何人，"?" 表示匿名
(未经身份验证的)用户。
-->
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</configuration>
上述内容中deny users="?" 将告诉.NET，此目录拒绝匿名用户的访问，也就是没有验证的用户。当用户试图请求此目录中的资源，将会被重新定向到login.aspx页面，要求登陆。没有登陆的情况下是无法访问的。
上述仅对目录进行定义，程序员不用在页面上添加任何代码，即可完整地实现了授权方案。
当然，这种仅针对目录的授权配置可能有时候又会缺乏灵活，因此，.NET也提供location配置节，可以对指定的资源定义授权：
程序代码：
<location path="userabc.aspx">
<system.web>
<authorization>
<allow users="a,b,c"/>
</authorization>
</system.web>
</location>
</configuration>
其中path是资源相对路径。
如果这还不够灵活的话，.NET也提供了在代码中使用的方法，ASP.NET页全局隐含了一个只读的User对象，通过获取User.Identity.IsAuthenticated属性，可探知用户是否验证（即是否登陆），User.Identity.Name属性可以获得用户的Name，即在验证时的SetAuthCookie方法中传递的userid。
4、基于角色的授权
上面我们讲述的用户验证，只可能有两种情况，要么用户通过验证，可以授权访问资源，要么用户没有通过验证，不能访问需要授权的资源。但是即便是验证通过的用户，可能他们所持用的权限还需要再进一步区分。例如普通用户和管理员同样是需要验证通过的，但是普通用户显然不能够访问管理页面，而管理员可以。面对这种情况，.NET可以使用基于角色的授权模型。
其基本原理是，一旦用户验证合法，他们就被分配角色，用户可以使一个或者若干和角色，而资源的授权面向角色，这样，针对不同的角色，就可以授予不同的权限，没有某种角色类型的用户试图访问需要这种角色的资源将会被拒绝。
当网站开始接受用户请求时，就伴随着验证，将激发Application_AuthenticateRequest事件，在Global.asax文件中写代码以响应此事件。角色的分配工作就需要再这里进行。
程序代码：
{
//Application_AuthenticateRequest事件和Application_BeginRequest事件是在每次访问aspx文件都会触发。但是Application_BeginRequest中不能对已经经过FROMS身份验证的身份ticket票进行识别。所以只能放到Application_AuthenticateRequest中去。
if(this.Request.IsAuthenticated)
{
//这里简化了操作，可以从数据库中获得角色信息用以构造rolesStrArr数组。作为示例，我们为除了a之外的用户分配了管理员角色
string[] rolesStrArr=newstring[]{};
switch(this.Context.User.Identity.Name)
{
case"0":
case"1":
rolesStrArr =newstring[] { "admin"};
break;
default:
rolesStrArr =newstring[] { "普通用户"};
break;
}
this.Context.User =newSystem.Security.Principal.GenericPrincipal(this.User.Identity, rolesStrArr);
}
}
以上代码清晰明了，因此不再赘述。虽然在全局性有User对象，但是只有Context上下文中的User对象是可以写入的，我们调用System.Security.Principal.GenericPrincipal方法，在原有User对象的基础上为其加入角色。角色列表示一个字符串数组。
一旦用户被授予访问角色之后，在web.config中就可以配置针对不同角色的访问。例如在管理员admin目录内
<location path="userabc.aspx">
<system.web>
<authorization>
<allow roles="admin"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
</configuration>
上述配置只允许管理员角色才能被授权。资源默认是任何人都访问的，所以要在下面再添加<deny users="*" />表示对任何用户拒绝。
注意，无论对角色或者对用户指定资源的访问，如果对于多个角色或者读个资源，他们之间使用半角逗号隔开。同样，也可以使用上面讲到的方法，对指定的资源进行配置而不是对整个目录。
全局的User对象提供了一个方法IsInRole(string RoleName)方法用来在代码中检测用户是否拥有某种角色。如果他拥有这种角色，将返回true。
