SharePoint中的Form Based Authentication VS Windows Authentication
本文比较了二者的区别.
爬网
===========
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