MS.Tech - IT人

.NET & 微软企业服务器 & 前沿技术和产品
随笔 - 107, 评论 - 1269, 引用 - 87

导航

关于

所有内容和观点仅代表个人观点,如有问题和建议请发Email给我。

标签

每月存档

最新留言

广告

 

对于普通ASP.NET站点来说,要对该站点的URL进行访问授权控制,可以通过创建一个HttpModule来监控每个Request,如果Request Url为受控URL(即要访问该URL地址需要经过一种特定验证授权)时,则跳转到验证授权页面进行身份验证授权,完成后再返回即可正常访问Request Url。我想,这个实现并不难,网络上也可以找到诸多用HttpHandler和HttpModule来做这块处理的示例。

那么,SharePoint Portal Server 2003中,访问受控URL和普通ASP.NET站点有何不同吗?带着这个疑问,我们可以一开始也用HttpModule来做尝试。假设此时我们访问一个SharePoint 文档库的某个内容,其URL地址应该是 http://localhost/DocLib1/Test.doc,而在我们的受控URL数据库记录中发现 http://localhost/DocLib1 为受控URL,那么要访问 http://localhost/DocLib1/Test.doc,就不能让未经过验证授权的用户直接访问,而应该跳转到我们验证授权页面进行身份验证授权后方能访问。结果很让人遗憾,我们的访问畅通无阻。于是做了调试跟踪,发现在 HttpModule 中 Request.Url 不是我们想要的 http://localhost/DocLib1/Test.doc,而是一个对我们未知的 http://localhost/_vti_bin/owssvr.dll,正因为这个地址不是受控URL,所以HttpModule不做处理直接让用户继续访问了。

姑且不论owssvr.dll到底为何物,现在要解决的关键问题有两个:

  1. 为什么我们点的是 http://localhost/DocLib1/Test.doc 这个请求,而到HttpModule时,却变成了http://localhost/_vti_bin/owssvr.dll,谁干的好事?
  2. 我们能否在这家伙做这件事之前把执行权抢过来做我们自己的处理?

对于第一个问题:谁动了我的URL?在了解这个问题答案之前可以先参考以下文章:

看完上面两篇文章,或许你已经清晰知道是谁动了我们的URL。是stsfltr.dll(可以在IIS管理器-->Web站点属性窗口-->ISAPI 筛选器找到)这个ISAPI Filter在HttpModule之前抢先做了处理

第一个问题找到了,第二个问题:怎么解决这个问题,把执行权抢过来?只能自己再写个 ISAPI Filter,并把该 ISAPI Filter排在stsfltr.dll之前了。于是,我们创建了一个C++ Win32 项目,定义了下面这个一个ISAPI Filter class:

class CRedirectorFilter : public CHttpFilter

{

public:

     CRedirectorFilter();

     ~CRedirectorFilter();

 

     BOOL IsSecureDocument(LPCTSTR docUrl, LPCTSTR agent, LPCTSTR cookie);

     BOOL GetCookie(CHttpFilterContext* pCtxt,CString strName, CString & strValue);

     BOOL GetAgent(CHttpFilterContext* pCtxt,CString strName, CString & strValue);

 

// Overrides

     // ClassWizard generated virtual function overrides

         // NOTE - the ClassWizard will add and remove member functions here.

         //    DO NOT EDIT what you see in these blocks of generated code !

     //{{AFX_VIRTUAL(CRedirectorFilter)

     public:

     virtual BOOL GetFilterVersion(PHTTP_FILTER_VERSION pVer);

     virtual DWORD OnPreprocHeaders(CHttpFilterContext* pCtxt, PHTTP_FILTER_PREPROC_HEADERS pHeaderInfo);

     virtual DWORD OnEndOfNetSession(CHttpFilterContext* pCtxt);

     //}}AFX_VIRTUAL

 

     //{{AFX_MSG(CRedirectorFilter)

     //}}AFX_MSG

};

通过OnPreprocHeaders来处理判断我们的受控 URL 逻辑,如果是受控URL且尚未经过验证,则绕过stsfltr.dll直接跳转到验证授权页面进行身份验证授权;如果不是受控URL或已经经过验证,则直接交给IIS继续处理。

对于MOSS 2007,没有了stsfiltr.dll的困扰,实现类似方案就相对方便许多了,有兴趣者可以利用HttpHandler或HttpModule进行类似实现。

BTW:对于对受控URL的判断逻辑,如果感觉C++实现比较吃力费时,可以考虑用.NET Assembly来写这块逻辑,然后利用C++调用托管DLL来实现这块逻辑。具体可以参考KB:

打印 | 张贴于 2007-03-28 00:00:00 | Tag:微软企业服务器

留言反馈

#回复: 对SPS 2003 URL进行访问授权控制 编辑
明白了。多谢!
----------------------
虽然moss2007比sps2003有相当的进步,我做了二个案子下来,还是问题不少,有的还劳驾ms专门作hotfix给我们。大概moss2007sp1会是一个稳定的版本。
---------------------
原本只想说谢谢,不过出来一个"系统怀疑您的评论内容为广告,或者评论文字太短,请检查后重试!". 就多写二句。
2007-04-02 16:58:00 | [匿名:by1455]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
明白了。多谢!
2007-04-02 16:48:00 | [匿名:by1455]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
客户的需求总有太多,因此有这类方案也确实不足为奇了:)
我们方案只是为客户内部文档库集成指纹认证等相关授权访问的方案,数据量暂时没统计。

嗯,我觉得微软的诸多服务器产品确实或多或少在功能上都有重叠。而且微软Sales本身在推销产品的时候有时也没能很好定位产品,这可能和产品功能的重叠性有关。

我个人偏向认为:CMS 2003应该是定位在Web Content Management上,SPS2003定位在Portal整合呈现上,Commerce Server偏重商务领域,Wss 应该定位在小型工作组团队的站点上。这些Server都在应用端上(可能WSS理解上会里端一点),所以有时还会在具体应用中扮演不同角色。这些,当然,每个人或许都有自己不同看法。

Document Management我觉得应该是在WSS这个级别上去推的,因为SPS也是基于WSS的,所以MS Sales搞了个“越权”推广,也算情理之中。SPS 的Portal角色,WebPart扮演重要地位。

对于搜索,sps2003我不敢恭维。但对于MOSS 2007我赞赏有加,虽然我本身也还在熟悉中,但已经被深深打动。

对于为何不推荐在moss中直接嵌入 ASPNETPage,主要也是考虑性能问题,其次是考虑这种方式的应用有点不伦不类,感觉就像披着羊皮的狼一般,不知道什么时候出来咬你一口,让你不知所措。 hehe..用来应急,Work Around都还不错。
2007-04-01 22:46:00 | [匿名:liuhuimiao]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
方案是真正实施的,只不过方案具体实施增加了更多考虑,包括防止IP地址欺骗等各类因素。最终是以性能换取功能。

1、性能本身就是sps2003的一大瓶颈,Sps的列表数据库设计本身就是牺牲性能换取功能,来达到列表自定义的通用性。所以对于sps2003来说,大部分的应用都侧重在Portal概念上,也就是做呈现整合,有点名副其实的 Portal Server。相对来说,Document Management等倒有点属于一级副产品了,哈哈。只能说,产品本身问题我们无法避免,只能实施中尽量扬长避短了。
2、ISAPI Filter只负责取Cookie并校验Cookie,而负责写Cookie的操作应该是由验证页面(比如嵌入指纹验证ActiveX控件的指纹验证页面等)来写入客户端。
3、Office Client不会禁止,但Office Client的授权访问就属于另外一种方案了。这个方案中Office Client都通过User Agent判别直接过滤了。
4、Sps2003+IRM方案也有限制,比如我说的指纹验证方案,这块用现有IRM无法扩展实施,IRM只支持到类似SmartCard应用,其他各类验证应用都需要原厂商专门支持,难度比较大。
5、LB这块,倒真没考虑,主要还没那么大访问量和应用范围。
6、采用URL+metadata方式进行访问授权控制,确实还要提防各类不安分的用户。防止出现URL欺骗。

其实还好了。至少到目前为止,我们还没有发现访问授权问题,当然这个和我们的方案的应用场景有关,并非放之四海皆准。所以安啦,大条的代志应该没有。
2007-04-01 12:14:00 | [匿名:liuhuimiao]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
猜测楼主应该没有真正实施这个方案,我是到了快要部署时才发现大事不妙,下面的learning point和

大家分享
1:单独的URL进行访问授权控制是没有真正的应用价值,必须加上metadata的访问授权控制。例如,绝对不能发生让用户看到诸如“发配by1455扫地”的标题,URL访问授权控制才不让用户打开文件的情况。在这里metadata访问授权控制和文件的URL访问授权控制一样重要。那么项目的新增或修改时的性能下降(<1s到2-3s)用户基本上还可以接受。但是列表的性能下降是一个几何下降。另外搜索也是一个大问题(是列表的超集)

2:ISAPI filter基本上windows应用,而不能算web应用,虽然有可能取得客户端Cookie(如果抄不到现成的源码,很悲惨哦),但意义不大,原因是
a:取得客户端Cookie是可能,在isapi filter如何送Cookie到客户端?
b:安全上漏洞,二次处理之间,有个鬼修改了访问授权,事情就大条了,cookie就变了鸡肋,吃也不是,扔也不是。
c:缓存和实时在这里是一对怨偶,实时好像经常占上风。

3:OM和webservice是可以绕过这个控制,本组人还好,二次开发时,其他人会让你撞墙。

4:如果禁止sps2003与office client的无缝连接(这可是MS的大卖点),似乎有因小失大之嫌,而且需要修改office client安装包,从office2000到xp,2003个个有所不同

5:偷懒的方案:简单用view来限制用户的list.假装用户都是真君子
6:严肃的方案:SpS2003+IRM,安全无忧,但仅限office文件,PDF不行

楼主开的这个话题非常有意思,认真研究一下,至少以下几个方面会有所斩获
a:AD
b:SQL
c:SPS2003
d:Office client (word,ppt,excel,fp)
e:security.
f:web application (IIS,webdev,RPC)
g:load balancing (这是另外一个很有趣的话题)
2007-04-01 11:01:00 | [匿名:by1455]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
嗯。多谢 by1455,这个方案确实有欠考虑,但实在也是在sps2003中的无奈之举。我列出该方案,也希望给大家一点启发,作为真正实施的方案,毕竟还要考虑用户实际需求和特定环境等因素的。

1、我还是觉得性能上尽管有损失,但没你说的这么严重,而且可以通过其他方式(比如验证客户端Cookie等)来缓解这个问题,保证虽然每次都会检查访问授权,但会以尽量快的速度结束这个流程。
2、和SPS OM冲突?不知道具体指的是哪方面,是和使用Url来初始化OM相关实例会有问题吗?
3、事实上,这个方案的应用范围确实受限,比如最好只控制Url到文档库,或者某特定Url。
4、对于office client、WebDAV等当时也考虑了,事实上这个方案当时考虑的时候也不包括Office client等使用情况的。在ISAPI Filter中就通过Agent过滤了,只允许IE访问的授权控制。

很高兴认识你,希望有机会多多交流SharePoint相关知识 :-)
2007-04-01 00:02:00 | [匿名:liuhuimiao]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
最近发现这里(博客堂),也学到很多咚咚,一时兴起,便和楼主讨论一番
其实楼主讲的和event handler我都做过prototype.其中还请MS一起探讨。这里愿意和大家分享
1:SPS2003基本上无法在Internet实际应用,MS也没有sps2003的internet许可证(这是CMS2002的地盘)
2:在这个方案中,性能下降与网络的传输的延迟不成正比。其中的关键不是项目的新增或修改,而是列表!!!,每个item都要检查访问授权,item一多很快到了你的忍耐上限。
3:因为这个方案中,有和OM冲突的地方,这个一加,要玩OM就麻烦了。
4:在自定义列表上加这个意义不大,原因是自定义列表没有folder,很难让用户入完item再弄访问授权,管理员无法为用户做预定义,也缺少批量修改的机制。
5:漏洞-〉webdev,RPC和Frontpage都有可能突破这个访问授权控制。这是一个“防君子不防小人"的方案。(^o^)

题外话:非常高兴和楼主讨论,sharepoint我勉强也算是个早期用户,v1,v2都有真正的企业级的应用,Moss2007也是RDP用户
顺便告诉大家一下,MOSS2007的匿名访问存在一个bug(发现有内容的随机遗漏),有一个hotfix,但是好像没有公开,敬请留意。
2007-03-31 23:15:00 | [匿名:by1455]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
性能:诚然,性能确实是一大问题,毕竟无端的每次都走了一次ISAPI Filter,但在局域网内,牺牲性能换取一定功能的做法,还是可以考虑的。如果在 Internet上应用,此时性能关注更强烈,因此这类做法必定要深思熟虑。

ISAPI问题:确实是一个问题,开发上费时费力。

至于授权控制,就还是交给stsfltr.dll处理就是了,自定义的filter尽量不要去影响现有的东西,只需在外面再包一层即可。

EventHandler也只能文档库,解决不了自定义列表等其他的访问。
2007-03-31 18:43:00 | [匿名:liuhuimiao]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
这个方法只存在于纸面上,受太多的因素影响。也就是为何sps2003存世近四年,市场上有关sps2003的folder级访问授权控制的解决方案寥寥无几的原因。
1:性能
加一个外部isapi filter,所有的sps2003访问有事没事都要兜一圈,性能大损。
我一直认为sps2003是一个半成品,MS为了干掉wss(web storage system ) 大量移植team service v1.0的代码。以致于大幅度牺牲sps2001的功能和性能,在SPS2003b1,有看到folder访问授权控制的痕迹,可惜到了sps2003release,被杀的干干净净,最大的可能就是性能无法达到要求,或是赶工时间不足。和wss相比SQL2000,一个本地,一个远程,性能相差甚大。
2:资料不足
sps2003SDK没有任何有关的资料,只有像楼主自己摸索。
3:ISAPI的问题
写个 ISAPI Filter,排在stsfltr.dll之前了,听上不错,真的试试,在isapi中进行条件判断十分困难,二次调用之间的变量保存,等等。加上isapi filter的debug困难,动不动iis就死翘翘。
4:同步更新访问授权控制不易
例如sps2003可以使用cross-site 和AD的group做访问授权控制,开始设定一个group可以访问,因为无法直接拷贝group的成员表,isapi filter必须做实时检查,所以最坏的情况下,要检查AD,cross-site group, SQL2000的访问授权控制表,docLib的访问授权表。还有好玩的是,除了sql2000的访问授权控制表,到了sps2003自己的isapi filter里,还要再过一遍。

另外一个方案,使用event handler来做,替换掉原有的Doc Lib的template.
那是题外话了。
2007-03-31 18:32:00 | [匿名:by1455]
#回复: 对SPS 2003 URL进行访问授权控制 编辑
新写一个isapi filter感觉挺费力的
2007-03-28 10:22:00 | [匿名:helixapp]
对不起,目前本随笔不允许发表新评论.

Powered by: Joycode.MVC引擎 0.5.2.0