在SharePoint 2010中创建Web App时，虽然我们可以选择用Classic mode还是Claim mode认证，但在Classic mode下只能使用Windows Authentication，如果要使用其它的认证方式，比如FBA，就必须选择Claim mode （虽然在Beta 2中，仍能在Classic mode下配置FBA，RTM中将不允许这样做）。
在Claim mode下，无论是用Windows Authentication，FBA，还是基于其它trusted identity providers的认证方式，identity最终都会被转换成Claim Identity来进行认证。这就使得我们不需要使用多个Authentication Provider来让一个Web App使用不同的认证方式，一个Authentication Provider就够了。
由于Claim mode的引入，在SharePoint 2010中配置FBA的步骤与MOSS 2007的有一些不同，简单总结在下面：
- 第一步当然是启用Claim mode。如果是新建Web App，在UI上直接选就可以。对已有的Web App，应该是没有UI可以修改（或者是我没找到），但下面的PowerShell脚本可以实现Classic和Claim的转换：$w = Get-SPWebApplication “http://<Url>/”$w.UseClaimsAuthentication = True;
$w.Update()
$w.ProvisionGlobally()
- 在Authentication Provider的设置中选择同时启用Windows Authentication和Forms Authentication，并指定相应的Membership和Role provider的名字。
- 修改该Web App的web.config，加入要使用的Membership和Role provider。注意不要修改defaultProvider设置，Claim的provider是默认的Provider。
- 修改好之后，通过Windows Authentication登录网站，添加一个FBA用户，看看用户名是否能被解析，如果不能，多半是provider的设置有问题。
- 这时虽然FBA用户名能够被解析，但如果使用Forms Authentication登录的话，并不会成功。这时因为SharePoint使用SecurityTokenService来将各种认证的identity转换为Claim identity。我们必须让这个Service知道如何验证FBA用户。因此，下一步很重要。
- SecurityTokenService有一个Service Application与SharePoint交互，修改这个Service App的Web.config，在其中加入我们的Membership和Role provider。Provider所使用的名字和设置应该与我们的Web App中的相同。SecurityTokenServiceApplication的文件目录可以通过IIS找到。
- 完成上面的步骤之后，应该就可以用Forms Authentication登录了。如果需要在Central Admin中解析FBA用户，则需要在Central Admin的Web.config中添加相应的Providers。
参考：http://technet.microsoft.com/en-us/library/ee806882(office.14).aspx