|
|
提示: 作者被禁止或删除, 无法发言
|
马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有帐号？FreeOZ用户注册
x
如何在ASP.NET应用中集成Windows域帐户来进行权限控制
企业应用程序采用域用户来代替独立的用户管理模块的好处很多。
* 程序本身不需要单独编写用户帐号管理模块
* 与域用户集成，用户不需要单独记忆用户名口令，可以实现无缝登录
* 采用域用户方案安全性提升，认证时口令不在网上传输，域用户安全级别
* 其他好处多多
首先需要配置IIS：
为你的应用单独建立一个web虚拟目录，右键选择属性里的目录安全，权限与访问控制，把“打开匿名访问”不选，仅仅选择“集成Windows权限认证”，别的都不要选，确定。
集成域用户来控制用户访问的途经有两种，一种是利用NTFS权限控制表，缺点是每次转移应用之后，需要逐个设置目录访问权限。另外一种是通过配置 web.config文件，通过URL来控制，好处是直接修改配置文件就可以了，不需要每次发布应用时变换一次目录就修改一次。下面我就主要介绍一个后者。
划应用目录树：
根目录的权限设置覆盖子目录的设置，把管理页面单独放在一个路径下，比如在根目录下设置一个admin子目录管理页面都放在这下面；再设置一个sales的子目录，只有销售的同志可以访问，user则是任何人都可以访问。举例如下：
\root\
\root\admin
\root\sales
\root\user
修改配置文件：
在需要进行权限配置的目录下面，分别建立web.config文件。root下面肯定需要一个配置文件了，在本例中由于admin路径下放置了管理页面，因此我在admin下面也建立了一个web.config配置文件。
root下的web.config配置文件的和权限相关的内容如下：
<?xml version="1.0"?>
<configuration>
<connectionStrings>
<add name="APPConnectionString" connectionString="Data Source=MachineName;Initial Catalog=DatabaseName;Integrated Security=SSPI"
</connectionStrings>
<system.web>
<authentication mode="Windows" />
<!--<identity impersonate="true" userName="UserName" password="PassWord" />-->
<identity impersonate="true"/>
<authorization>
<allow roles="UserName,domainname\username1,domainname\username2,domainname\usergroup1" />
<deny users="*"/>
</authorization>
</system.web>
</configuration>
admin目录下也增加一个web.config文件 （sales目录下配置文件类似，就是允许sales的账户访问该目录即可）
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<allow roles="domainname\username1，domainname\usergroup1" />
<deny users="*"/>
</authorization>
</system.web>
</configuration>
首先，先解释一下admin下面的这个配置文件，我允许domainname\username1访问这个管理目录，而禁止任何其他的用户来访问这些功能页面。
下面，再接是一下root下面的这个配置文件，我增加了一个链接数据库的字符串，采用的是MS推荐的安全连接，没有使用sa之类的SQL管理的账户。
authentication mode="Windows" 的意思是集成域用户，这句话是打开应用支持域用户的关键。
allow roles=",,," 列表里面我规定了可以访问root的用户，每个用户之间用逗号分隔，这里可以指定服务器本机用户，也可以指定域用户，或者域用户组
deny users=",,," 列表里我规定了禁止所有用户访问（允许列表里的用户除外）
以上这两个类表可以使用的通配符有 ? 匿名用户， * 所有用户
到目前为止，其实就已经算是完成了，就这么简单。
用户代理
Impersonate，除非有特殊要求，比如在同一个服务器上运行同一个应用，需要区别不同公司的操作，可以分别建立应用程序池，采用不同代理帐号，来区分访问，否则，这个代理账户是不需要的（而且会引起性能下降），这个代理用户现象缺省是关闭的。
如果不采用用户代理，每次用户登录应用的时候，系统自动匹配当前用户登录所使用的客户端的域用户名
如果采用用户代理，就是指定一个代理用户，代理所有表现曾用户的一切操作请求。
可以用下面的配置指定固定的代理用户
<identity impersonate="true" userName="UserName" password="PassWord" />
或者采用下面的设置，指定应用程序池的用户作为代理
<identity impersonate="true" />
缺省情况下，这个用户代理是关闭的，缺点也不少，MS不推荐使用，所以，你就跳过这部分吧。
下面说一下如何采用信任账户去链接SQL数据库
这一部分，实际上用的很广泛，MSDN有专门的一篇来讲解这个，你可以参考，
http://msdn.microsoft.com/en-us/library/ms998292.aspx
如果使用了sa或者其他SQL管理的用户帐号，那实际上我就把口令写到了配置文件里面，这样安全性不好。当然微软也提供了补救办法，就是可以使用一个命令行加密工具把配置文件加密成密文，总之是不好了，那怎么使用信任连接连接数据库呢？配置文件照着下面写，
<connectionStrings>
<add name="ConnectionStringName" connectionString="Data Source=ServerName;Initial Catalog=DatabaseName;Integrated Security=SSPI" providerName="System.Data.SqlClient" />
</connectionStrings>
下一步是怎么配置这个信任的用户的权限，这个账户必须同时具有运行IIS应用的权限，和访问SQL的权限。一般可以指定一个特定的新建用户，当然，为了简化配置，如果web服务器和SQL服务器都在一台机器上，也可以使用预置好的服务帐户NT AUTHORITY\NETWORK SERVICE，否则你就需要建立一个域用户了，格式可以是domainname\webmachinename。然后就是分配给这个用户访问SQL的权限。
给应用指定运行用户
建立一个新的应用程序池，右键选择属性，identity用户表示里面，把匿名用户去掉，在下面选择用户，可以选择你上面新建的用户，也可以使用NT AUTHORITY"NETWORK SERVICE。
在代码中调用域用户权限
在代码使用如下代码来查看访问者域用户身份。
Page.User.Identity.Name
Page.User.Identity.IsAuthenticated
增加引用using System.Security.Principal;
使用如下代码查看采用信任链接 方式同一访问SQL的用户身份，也就是你在应用程序池里指定的那个用户名。
WindowsIdentity.GetCurrent().Name
如有错误，欢迎批评指正。
下面图标说明了应用层采用Windows用户进行安全认证，应用层和数据服务器之间则采用信任链接统一访问的原理。
http://i.msdn.microsoft.com/ms998292.f01paght00000801%28en-us,MSDN.10%29.gif
--------------------------------------------------------------------------------------------------------------
构建安全的企业内部WEB程序
为了保护企业内部的敏感信息、方便用户管理、确保用户只访问他们应该访问的地方。我一直在寻找最便捷的方法……查询了一些资料，下述是我个人的一些理解。我们集合IIS和ASP.NET，通过验证（authentication）和授权（authorization）来实现企业WEB程序的安全。客户端对page.aspx的请求是这样发出的：
这里涉及到两个重要的概念，它们定义如下：
验证（Authentication）：标识请求页面的用户。（ The process of identifying the user who is requesting the page）.
授权（Authorization）：系统判定用户访问资源的权限。(System determines which resources he or she has access to.)
第一步，我们需要确定身份验证的类型。（条件1）在企业内部网中，我们已经有了包含所有用户帐号的数据库－活动目录，同时每一个登陆内部网的客户端都使用不同的用户帐号。现存的身份验证有：Windows身份验证、Forms身份验证、Microsoft Passport 身份验证。（条件2）其中Windows身份验证是基于现存的Windows 安全架构，它通过角色（Roles）控制来实现web程序的安全性。（结论）根据上述条件，我们采用基于Windows（Windows-based）的身份验证，我们需在Web.config文件中这样描述：
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<customErrors mode="Off"/>
<authentication mode="Windows" />
<authorization>
<allow roles="domain\user1,domain\user2,domain\usergroup1,domain\usergroup2" />
<deny users="*" />
</authorization>
</system.web>
</configuration>
（注意：XML文件是区分大小写的）
为了实现Windows身份验证，IIS提供了三种类型：基本验证（Basic）、域服务器简要验证(Digest)、集成Windows验证（Integrated Windows Security）。
（条件1）用户能够登陆到内部网，他就通过了活动目录对他的验证，并拥有一张证书（credential）。当用户请求安全页面时，浏览器就会把证书传送给IIS。（条件2）集成Windows验证就是把IIS要求的身份验证预先交由活动目录来完成。（结论）这就是说：采用集成Windows验证方式，用户一登陆内部网就预先通过了IIS对他的验证。所以，我们采用集成Windows验证。
第二步，对要访问的资源授权。对资源进行授权的方式有两种：文件授权（file authorization）和URL授权（URL authorization）。
文件授权基于Windows 2000的ACL(Access Control List)，它的优点在于通过ACL控制文件和文件夹是非常容易的；它的缺点在于，需要花费时间来管理不同文件/文件夹的ACLs，而且程序迁移时，ACL并不随着文件夹copy and past而迁移。
URL授权是在web.config中对不同的URL或文件夹进行授权。它的优点在于程序迁移方便；缺点是需要在web.config中书写代码。
微软推荐我们采用文件授权的方式，但基于可迁移性考虑，我还是采用了URL授权方式。假设marketing.aspx是只有管理员和营销部(成员都属于marketing用户组)才能访问的页面，fold文件夹下面包含了只有管理员和人事部(假设成员都属于human用户组)才能访问的页面。我们在web.config中这样设置：
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<authorization>
<allow roles="global\user1" />
<deny users="*" />
</authorization>
</system.web>
</configuration>
* 所有
? 匿名用户
这里的web.config文件继承了父目录下的web.config文件的设置，并按自己的要求改写了设置。
通过验证和授权这些简单的设置，我们在企业内部网中实现了初步的安全。
[ 本帖最后由 xblues 于 1-8-2008 14:26 编辑 ] |
|
发表于 30-7-2008 19:02:59
收藏
赞
踩
楼主
