本文比较了二者的区别.
爬网
===========
MOSS 和WSS3.0中的内容就是被设计为使用Windows认证的. MOSS刚刚发布的时候, 还没有办法使用FBA(form based authentication)认证方式来爬网. 在SP1里, 包含了设置特别的爬网规则的能力, 允许基于cookie的认证, 这样站点就能够被爬网了.
然而, 它只能进行简单的对内容的爬网, 它并不会捕捉到安全信息还有任何使用native SharePoint Protocol Handler能够抓取出来的丰富的元数据.
基于这样的原因, 不论你是否已经安装了SP1， 我们都推荐你使用SharePoint native protocol handler来索引使用FBA保护的站点.
注意: 关于如何配置的更多信息请看原文.
与2007 Office System的集成
===========
MOSS 和WSS3.0跟Office客户端软件有高水平的集成. 很多集成的Feature是依赖于Windows认证的. 没有Windows认证, 很多集成点就不能工作了, 剩下的也有一些程度上的不同. 为了帮助客户尽可能的减少困惑, SharePoint提供了一个模式, 在这个模式下, 需要Windows认证的菜单项都会被移除. 设置这个模式的地方就是管理中心, Authentication Provider页面的Enable Client Integration 复选框.
下面是必须依靠Windows认证才能工作的一些项目:
-
- New Document
- Open in Outlook
- Open In Windows Explorer
- Export to Spreadsheet
- Open with Database Program
-
- Upload Multiple
- Edit Picture
- Download
- Send To
-
- Edit in Excel
- Edit in PowerPoint
- Discuss
- Connect To Outlook
-
- Publish Slide
- Send to PowerPoint
SharePoint数据与Outlook的同步也不再有效了.
在这种模式下, 用户还可以使用SharePoint文档库, 但是他们必须右键点击它们并选择保存副本到磁盘上. 他们可以编辑然后上传.
有些公司或许希望使用Form authentication, 但还要求跟windows认证相同水平的集成. 下面是一些这种场景下可能的workaround, 它们对于帮助我们理解为什么这些限制会存在很有帮助.
当 一个用户通过form认证访问一个站点中的页面时, 服务器会寻找合法的认证cookie. 如果cookie没有找到, 或者cookie不合法, 服务器会通过使用HTTP 302状态码, 重定向浏览器到登陆页面. 在这个页面, 用户允许使用它的credentials信息来通过认证. credential在验证过了之后, 服务器创建一个合法的authentication cookie, 并把它连同原来请求的页面一起发回给浏览器. 浏览器会把这个cookie保存在内存中, 并在接下来的向这个web服务器的请求中都会带上这个cookie. 在每一个request中, server都会检查cookie的合法性来确保这是一个好的(没过期, 没被篡改过), 然后处理那个请求.
因为使用内存中的authentication cookie, 所以有下面的一些限制:
- Cookie只能在浏览器开启的状态下被保存着, 一旦浏览器关闭了, cookie也就跟随所有那个浏览器使用的东西一起被破坏掉了.
- Cookie属于浏览器的应用程序进程(.exe), 并不能被其他的进程所共享. Office系统的应用程序是运行在自己的进程中的, 比如说msword.exe是Word的进程名. 因为如此, 一个用户登录站点是生成的cookie不能被word共享.
这 篇文章阐明了为什么Enable Client Integration选项会被创造出来: 为了帮助终端用户体验到一致的, 可以预测的环境; 然而, 用户体验相对于习惯了使用windows 认证的用户来讲还是有点不一样的. 即使有这么多限制, 还是有一些选项可以允许使用form认证的, 也的确提供部分或全部的使用windows认证的与Office应用程序深度集成的技术点的.
为Office 2007准备的Form Based Authentication的更新
==============
当 MOSS和Office2007刚发布的时候, Office客户端应用程序是不能直接打开使用form认证的站点上的文档的. 这是因为, 在刚才解释过的, 302http响应码会在程序试图打开文档的时候发回给应用程序. Office客户端应用程序不能响应302代码, 结果就是展现登录的表单, 而不是请求的文档.
Office 2007的更新允许用户处理302 Http响应码了. 这个更新影响的程序有: Word2007, Excel2007, PowerPoint2007, 和SahrePoint Designer2007. 因为这个更新, Office应用程序可以在一个弹出的对话框中展现登录页面的表单. 为了做到这一点, 应用程序发送一个请求给SharePoint站点, 服务器发送一个响应, 说明认证方式是表单认证, 包括了认证页面的位置. Office应用程序然后会渲染这个HTML表单, 允许用户在这个表单中输入他们的credential. credential信息通过post方法发送到服务器, 如果服务器返回一个原来请求文档的重定向响应, Office应用程序会假设身份已经确立. 它之后会使用服务器发回给它的authorization cookie来取回文档, 添加相关的元数据, 然后打开文档.
通过使用这种方式, 你可以使用任意一种站点使用的表单认证页面, 不管这个页面是不是有SharePoint服务器提供的.
在登录时勾选"Sign me in automatically"
==============
表单登录页面包含一个声明为Sign me in automatically 的 复选框, 默认是没有选中的. 如果你在登录时选中了它, 那么一个加密了的authentication cookie就会被序列化到用户登录站点的计算机的本地硬盘中. 用户的credential 信息并没有保存在cookie中, 取而代之, cookie中存储的是能够标识用户的某些加了密的数据.
Office系统的应用程序会在收到认证请求后寻找这样的 authentication cookie. 如果有一个存在, 那这个cookie就会被放在响应authentication请求的回复中. 如果cookie还是合法的, 使用cookie的认证会成功, 文档会在Office客户端中打开, 并不会要求用户输入什么.
有 些特性即使是有这样的authenticationcookie也不能工作. 比如Outlook使用stssync协议来在SharePoint和outlook中同步数据. 当authentication cookie还是合法的时候, 这应该工作的, 然而认证默认情况下会在30分钟后过期; 之后outlook会让用户重新进行认证.
User Profile Import
==============
MOSS 2007 Profile Import Tool 可 以帮助我们使用Asp.net 2.0中包含的menbership provider.你提供的membeship provider提供了GetAllNames方法, 你就可以使用Profile Import Tool来注册你的 provider了. 如果你的provider是想了GetAllProperties, 那么Profile Import Tool就可以取回每个用户的属性了.
参考资料:
Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Authentication vs. Windows Authentication
http://msdn.microsoft.com/en-us/library/bb977430.aspx
Office: Authentication prompts when opening Microsoft Office documents
http://support.microsoft.com/default.aspx?scid=kb;en-US;2019105#appliesto