|
提示: 作者被禁止或删除, 无法发言
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?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 编辑 ] |
|