|
ring of role names.
string[] roles = authTicket.UserData.Split(new char[]{''''|''''});
// Create an Identity object
FormsIdentity id = new FormsIdentity( authTicket );
// This principal will flow throughout the request.
GenericPrincipal principal = new GenericPrincipal(id, roles);
// Attach the new principal object to the current HttpContext object
Context.User = principal;
}
基于用户名或角色成员身份对用户进行授权
使用声明性主体权限要求来限制对方法的访问。使用命令性主体权限要求和／或明确的角色检查 (IPrincipal.IsInRole) 在方法中执行细分的授权。
窗体实现原则
•
当使用 HTML 窗体捕获凭证时，请使用 SSL。
无论何时通过网络发送凭证或身份验证 Cookie，除了对登录页使用 SSL 外，还应该对其他页使用 SSL。这样，可以减轻与 Cookie 重播相关的威胁。
•
根据自定义数据存储验证用户的身份。请使用 SQL Server 或 Active Directory。
•
从自定义数据存储中检索角色列表，并在 FormsAuthenticationTicket 类的 UserData 属性中存储分隔的角色列表。这样不必为每个 Web 请求重复访问数据存储，从而提高了性能；而且还免去在身份验证 Cookie 中存储用户凭证的麻烦。
•
如果角色列表很大并且有超过 Cookie 大小限制的危险，请在 ASP.NET 缓存对象或数据库中存储角色的详细信息，并在每个后续请求中检索这些信息。
•
对于初始身份验证后的每个请求：
•
从位于 Application_AuthenticateRequest 事件处理程序的票证中检索角色。
•
创建一个 IPrincipal 对象并将其存储在 HTTP 上下文 (HttpContext.User) 中。.NET 框架还将其与当前 .NET 线程 (Thread.CurrentPrincipal) 关联起来。
•
除非您有特殊的原因需要创建自定义的 IPrincipal 实现，否则请使用 GenericPrincipal 类。
•
使用两种 Cookie：一种用于个性化，另一种用于安全的身份验证和授权。将个性化 Cookie 作为永久性的 Cookie（确保它不包含允许请求执行受限操作的信息；例如在站点的安全部分放置订单）。
•
对于每个 Web 应用程序，请使用单独的 Cookie 名称（使用 <forms> 元素的 Forms 属性）和路径。如果针对某个应用程序验证用户的身份，这可确保在使用同一 Web 服务器承载的第二个应用程序时，不会将这些用户作为已验证的用户处理。
•
确保在客户端浏览器中启用 Cookie。对于不需要 Cookie 的窗体身份验证方法，请参见本章后面的“无 Cookie 窗体身份验证”。
更多信息
•
请参见“How To Use Forms Authentication with SQL Server 2000”。
•
请参见“How To Use Forms Authentication with Active Directory”。
•
请参见“How To Create GenericPrincipal Objects with Forms Authentication”。
承载多个使用窗体身份验证的应用程序
如果在同一台 Web 服务器上承载多个使用窗体身份验证的 Web 应用程序，则在某个应用程序中已验证身份的用户可以请求另一个应用程序，而无需重定向到该应用程序的登录页。第二个应用程序中的 URL 授权规则可能会拒绝该用户的访问，而不会提供使用登录窗体提供登录凭证的机会。
这种情况只在以下情况下会发生：多个应用程序的 <forms> 元素的名称和路径属性相同，而且每个应用程序在 Web.config 中使用相同的 <machineKey> 元素。
更多信息
有关此问题的详细信息以及解决方法，请参见以下知识库文章：
•
Q313116“PRB：Forms Authentication Requests Are Not Directed to loginUrl Page”
•
Q310415“PRB：Mobile Forms Authentication and Different Web Applications”
 返回页首
无 Cookie 窗体身份验证
如果您需要无 Cookie 窗体身份验证解决方案，请考虑使用 Microsoft Mobile Internet Toolkit 所使用的方法。移动窗体身份验证建立在窗体身份验证之上，但使用查询字符串来传递身份验证票证，而不是使用 Cookie。
返回页首
更多信息
有关移动窗体身份验证的详细信息，请参见 Microsoft 知识库文章 Q311568“INFO：How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit”。
返回页首
Passport 身份验证
如果应用程序使用 Passport 帐户，而且您要在其他支持 Passport 的站点上实现单次登录解决方案，则应使用 Passport 身份验证。
当将 ASP.NET 配置为使用 Passport 身份验证时，就会提示用户登录并将该用户重定向到 Passport 站点。成功检验凭证之后，用户就会被重定向回您的站点。
将 ASP.NET 配置为使用 Passport 身份验证
要将 ASP.NET 配置为使用 Passport 身份验证，请使用以下 Web.config 设置。 <authentication mode="Passport">
<passport redirectUrl="internal" />
</authentication>
<authorization>
<deny users="?" />
<allow users="*" />
</authorization>
将 Passport 标识映射到 Global.asax 中的角色
要将 Passport 标识映射到角色，请按如下所示在 Global.asax 中实现 PassportAuthentication_OnAuthentication 事件处理程序。 void PassportAuthentication_OnAuthenticate(Object sender,
PassportAuthenticationEventArgs e)
{
if(e.Identity.Name == "0000000000000001")
{
string[] roles = new String[]{"Developer", "Admin", "Tester"};
Context.User = new GenericPrincipal(e.Identity, roles);
}
}
测试角色成员身份
以下代码片段显示了如何在 aspx 页中检索已验证身份的 Passport 标识和检查角色成员身份。 PassportIdentity passportId = Context.User.Identity as PassportIdentity;
if (null == passportId)
{
Response.Write("Not a PassportIdentity");
return;
}
Response.Write("IsInRole: Develeoper? " + Context.User.IsInRole("Developer"));
返回页首
自定义身份验证
如果 .NET 框架提供的身份验证模块均不能满足您的确切身份验证需要，则可以使用自定义身份验证并实现您自己的身份验证机制。例如，您的公司可能已经制订了一个可由其他应用程序广泛使用的自定义身份验证策略。
要在 ASP.NET 中实现自定义身份验证，请执行下列操作：
•
按如下所示在 Web.config 中配置身份验证模式。这将通知 ASP.NET 不要调用它的任何内置的身份验证模块。 <authentication mode="None" />
•
创建实现 System.Web.IHttpModule 接口的类以创建自定义的 HTTP 模块。此模拟应该挂钩到 HttpApplication.AuthenticateRequest 事件中，并在要求身份验证时对每个应用程序请求提供要调用的委派。
身份验证模块必须：
•
从调用者获得凭证。
•
根据存储检验凭证。
•
创建一个 IPrincipal 对象并将其存储在 HttpContext.User 中。
•
创建并保护已验证身份的令牌，并将其发回给用户（通常在查询字符串、Cookie 或隐藏的窗体字段中）。
•
在后续请求中获得身份验证令牌，对它进行检验，然后重新分发。
更多信息
有关如何实现自定义 HTTP 模块的详细信息，请参见 Microsoft 知识库文章 Q307996“HOW TO:Create an ASP.NET HTTP Module Using Visual C# .NET”。
返回页首
ASP.NET 的进程标识
使用权限最少的帐户运行 ASP.NET （具体来说就是 Aspnet_wp.exe 辅助进程）。
使用权限最少的帐户
使用权限最少的帐户可以减少与进程攻击相关的威胁。如果某个顽固的攻击者设法破坏了运行 Web 应用程序的 ASP.NET 进程，则这些应用程序可以轻易地继承和使用授予该进程帐户的特权和访问权限。配置为权限最少的帐户可以限制可能的潜在危害。
避免作为 SYSTEM 运行
不要使用高权限的 SYSTEM 帐户运行 ASP.NET，也不要授予 ASP.NET 进程帐户“充当操作系统的一部分”的权限。您可能很想使用其中的一种方法，通过代码调用 LogonUser API 以获取固定的标识（通常用于网络资源访问）。有关替代方法，请参见本章后面的“访问网络资源”。
不要以 SYSTEM 的身份运行或不授予“充当操作系统的一部分”权限的原因包括：
•
当系统遭到攻击时，它会大大增加攻击者所造成的危害，但不能增加防范攻击的能力。
•
它破坏了最少权限原则。ASPNET 已被明确配置为运行 ASP.NET Web 应用程序使用的权限最少的帐户。
更多信息
有关“充当操作系统的一部分”权限的详细信息，请参见 1999 年 8 月 Microsoft Systems Journal Security Briefs 专栏文章。
域控制器和 ASP.NET 进程帐户
一般情况下，不建议在域控制器上运行 Web 服务器，因为对服务器的攻击就是对域的攻击。正如 Microsoft 知识库文章 Q315158“BUG:ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller”中所概述的，如果需要在域控制器上运行 ASP.NET，则需要授予 ASP.NET 进程帐户相应的权限。
使用默认的 ASPNET 帐户上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>
[C语言系列]NET 中C#的switch语句的语法 [系统软件]托拽Explore中的文件到VB.net的窗口
[系统软件]Boost库在XP+Visual C++.net中的安装 [常用软件]新配色面板：Paint.Net3.0RC1官方下载
[常用软件]用内建的“Net Meeting”聊天 [VB.NET程序]Henry的VB.NET之旅（三）—共享成员
[VB.NET程序]Henry的VB.NET之旅（二）—构造与析构 [VB.NET程序]Henry的VB.NET之旅（一）—失踪的窗体
[VB.NET程序]在托盘上显示Balloon Tooltip（VB.NET） [VB.NET程序]Henry手记－VB.NET中动态加载Treeview节点（二）
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
