SharePoint 2013 的身份验证的新增功能
马上注册，结交更多好友，享用更多功能，让你轻松玩转社区
才可以下载或查看，没有帐号？
摘要：SharePoint 2013 包含对声明基础结构和身份验证功能的改进，可支持新的服务器间身份验证和应用程序身份验证方案。
SharePoint 2013 中的身份验证增强功能可更轻松地利用基于声明的身份验证，并支持针对 Exchange Server 2013、Lync Server 2013 以及 SharePoint 商店或应用程序目录中的应用程序的新方案和功能。SharePoint 2013 通过利用和扩展 Open Authorization 2.0 (OAuth 2.0) Web 授权协议来引入对服务器间的身份验证和应用程序身份验证的支持。OAuth 是一个提供基于重定向的临时身份验证的行业标准协议。用户或代表用户的 Web 应用程序可以请求授权以便临时访问资源所有者的指定网络资源。
利用 SharePoint 2013 中的对 OAuth 的支持，用户可以向 SharePoint 商店和应用程序目录中的应用程序授予对指定的受保护的用户资源和数据（包括联系人列表、文档、照片和视频）的访问权，而不要求应用程序获取、存储或提交用户凭据。OAuth 允许应用程序和服务代表用户进行操作以便对 SharePoint 资源进行受限访问。例如，用户可以批准应用程序授予对文档库的特定文件夹的访问权的权限。这将使应用程序（如第三方照片打印程序）根据用户请求访问和复制特定文件夹中的文件，而无需使用或验证用户的帐户凭据。
1.SharePoint 2013 中的用户身份验证和授权
SharePoint 2013 中的用户身份验证是验证请求访问 SharePoint Web 应用程序的用户的身份的过程。身份验证提供程序会向经过身份验证的用户颁发一个安全令牌，该令牌将封装一组有关用户的基于声明的断言，并用于验证分配给用户的一组权限。SharePoint 2013 中的用户授权是一个确定可对 SharePoint Web 应用程序中指定源执行定义的操作的用户的过程。SharePoint 2013 支持基于以下方法的用户身份验证：
•Windows 声明
•基于安全声明标记语言 (SAML) 的声明
•基于表单的身份验证声明
这些基于声明的身份验证方法现在是为 SharePoint 2013 建议的身份验证方法。
SharePoint 2013 的应用程序身份验证和服务器间身份验证功能需要基于声明的身份验证。为此，基于声明的身份验证是 SharePoint 2013 中针对新 Web 应用程序的默认身份验证。当您在管理中心中创建 Web 应用程序时，您只能为基于声明的身份验证指定身份验证方法。虽然 Windows 经典模式身份验证仍在 SharePoint 2013 中可用且可通过 Windows PowerShell 进行配置，但建议您使用基于声明的身份验证。Windows 经典模式身份验证在 SharePoint 2013 中已被弃用。
2.声明基础结构中的改进
SharePoint 2013 还包括声明身份验证基础结构中的以下改进：
•使用新的 Convert-SPWebApplication Windows PowerShell cmdlet 更轻松地从经典模式迁移到基于 Windows 的声明模式
可以对每个内容数据库和每个 Web 应用程序运行迁移。这与 SharePoint 2010 产品形成了鲜明的对比，后者中将对每个 Web 应用程序运行迁移。有关详细信息，请参阅在 SharePoint 2013 中从经典模式身份验证迁移到基于声明的身份验证。
•登录令牌现在将在新的分布式缓存服务中进行缓存
SharePoint 2013 使用新的分布式缓存服务来缓存登录令牌。在 SharePoint 2010 产品中，登录令牌存储在每个 Web 前端服务器的内存中。每当用户访问特定的 Web 前端服务器时，都需要进行身份验证。如果您在 Web 前端的前面使用网络负载平衡器，则用户需要对在负载平衡器后面访问的每个 Web 前端服务器进行身份验证，这可能会导致多次重新身份验证。若要避免重新身份验证以及验证延迟，建议您启用并配置负载平衡器关联（也称为粘滞会话）。通过在 SharePoint 2013 的分布式缓存服务中存储登录令牌，不再需要在负载平衡器解决方案中配置关联。由于专用缓存服务，还可以获得向外扩展的好处并且 Web 前端中的内存使用率会更低。
•日志记录越多，解决身份验证问题就越轻松
SharePoint 2013 具有更多的日志记录可帮助您解决身份验证问题。以下是增强的日志记录支持的示例：
◦分离每个身份验证模式的与已分类的声明相关的日志
◦有关在分布式缓存服务中添加和删除 FedAuth cookie 的信息
◦有关无法使用 FedAuth cookie 的原因的信息，如 cookie 到期或解密失败
◦有关重定向身份验证请求的位置的信息
◦有关特定网站集中的用户迁移失败的信息
3.服务器间身份验证
SharePoint 2013 扩展 OAuth 以实现服务器间身份验证协议，诸如 SharePoint 2013 这样的服务可使用此协议来验证其他服务（如 Exchange Server 2013 或 Lync Server 2013）或与服务器间身份验证协议兼容的服务。
SharePoint 2013 具有专用的本地服务器间安全令牌服务 (STS)，此服务提供了包含用户标识声明的服务器间安全令牌以支持跨服务器的经过身份验证的访问。这些用户标识声明由其他服务用来查找针对其自己的标识提供程序的用户。在本地 STS（SharePoint 2013 服务器间 STS）和其他服务器间兼容服务（Exchange Server 2013 或 Lync Server 2013 服务器间 STS）之间建立的信任是使实现服务器间身份验证的关键功能。对于本地部署，您将其他服务器间兼容服务的 JavaScript 对象表示法 (JSON) 元数据终结点配置为建立此信任关系。对于联机服务，Windows Azure Access Control Service (ACS) 的实例将充当信任中介器以支持三种类型的服务器之间的跨服务器通信。
SharePoint 2013 中的新服务器间 STS 颁发了用于进行服务器间身份验证的访问令牌。在 SharePoint 2013 以及 SharePoint 2010 产品中，支持与 WS 联合身份验证协议兼容的受信任的标识提供程序。但是，SharePoint 2013 中的新服务器间 STS 仅执行允许临时访问令牌访问其他服务（如 Exchange Server 2013 和 Lync Server 2013）的功能。服务器间 STS 未用于用户身份验证且未在用户登录页上、管理中心中的身份验证提供程序 UI 或 SharePoint 2013 产品中的人员选取器中列出。
4.应用程序身份验证
SharePoint 2013 使用 OAuth 2.0 授予 SharePoint 商店和应用程序目录中的应用程序代表用户访问 SharePoint 资源的权限。在安装 SharePoint 商店和应用程序目录中的应用程序时，用户会授予这些应用程序代表其访问 SharePoint 资源的权限。例如，用户安装 SharePoint 商店中的应用程序。SharePoint 网站包含应用程序呈现的嵌入的 HTML 内联框架 (IFRAME)，该框架要求应用程序访问用户列表。当 Web 浏览器显示网站时，应用程序会回调运行 SharePoint 2013 的服务器以代表用户访问该列表。在应用程序获取列表中的数据后，它会显示 IFRAME 的内容。
SharePoint 2013 中的应用程序身份验证过程使用 OAuth 验证应用程序所做的声明，并断言可代表经过身份验证的用户执行操作的应用程序。在 SharePoint 2013 中，Windows Azure ACS 的实例将充当应用程序标识提供程序。您还可以使用应用程序身份验证而无需 ACS。授权过程会验证经过身份验证的应用程序是否有权执行定义的操作或访问指定的资源
上一篇：下一篇：
帖子永久地址：&<button type="submit" class="pn" onclick="setCopy('SharePoint 2013 的身份验证的新增功能\n/thread-.html', '帖子地址已经复制到剪贴板您可以用快捷键 Ctrl + V 粘贴到 QQ、MSN 里。')">推荐给好友BI168大数据社区 - 论坛版权1、本主题所有言论和图片纯属会员个人意见，与本论坛立场无关
2、本站所有主题由该帖子作者发表，该帖子作者与享有帖子相关版权
3、其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和的同意，并添加原文出处声明
4、帖子作者须承担一切因本文发表而直接或间接导致的民事或刑事法律责任
5、本帖部分内容转载自其它媒体，但并不代表本站赞同其观点和对其真实性负责
6、本站遵循行业规范，任何转载的稿件都会明确标注作者和来源，若标注有误或遗漏而侵犯到任何版权问题，请立即告知本站，本站将及时删除并致以最深的歉意
7、管理员和版主有权不事先通知发贴者而删除本文
168大数据()是国内首家学习型大数据社群媒体、大数据深度交流社区！
width:100%">
Hadoop交流群：
大数据课堂群：
大数据求职群：
Powered bySharePoint 2010 配置基于MemberShip的身份验证 - 风清扬 No.1 - 推酷
SharePoint 2010 配置基于MemberShip的身份验证 - 风清扬 No.1
场景:通常需要为sharepoint打通其他的系统整合到sharepoint认证,ad通常是为内部域用户,外网访问的可以使用membership来登录,那么这个既可以内部用户访问,外部用户也可以访问 ,另外也可以把其他的用户加到membership里面.
用aspnet_sqlreg创建memebership数据库
用网站管理工具添加用户和角色
为以下添加连接字符串：
你的应用程序(application)
管理中心(central administration)
令牌服务程序(secure token service application)
为以下添加memebership和providers
你的应用程序(application)
管理中心(central administration)
令牌服务程序(secure token service application)
创建一个新的应用程序
管理web应用程序&
点击后弹出一个界面,点击ribbon工具栏新建一个application
在弹出的窗口中选择基于身份的验证(
Claims Based Authentication
)，完成后IIS将创建一个新的IIS站点,如果需要你可以修改这个站点名字,如Sharepoint --FBA Test ,这里需要选一个可用的端口.
向下滑动一点,配置基于forms的认证,选择开启基于forms认证，并且配置membership提供者命名为
FBAMembership，接着配置角色提供者
最后一步配置应用程序池为
滑倒底部点击OK，这个需要10-15秒创建一个新的application. 创建完成后出现如下画面;
除了使用基于windows认证之外还是用了基于forms认证,点击ok创建一个site collection并且把windows 帐号设置为主要的管理员(primary)
创建membership存储并且添加用户
创建数据库
打开visual studio 2010窗口命令工具,输入aspnet_sqlreg，回车后弹出一个向导配置数据库.按照默认将数据库命名为membershipdb,结构如下:
接下来的事情将是要添加一些用户和角色到数据库中,别且使用vs修改web配置文件中的连接字符串.在
“&connectionStrings/&” 节点里面
&connectionStrings&
&add name=&AspNetSqlProvider&
connectionString=&data source= Integrated Security=SSPI;Initial Catalog=&
providerName=&System.Data.SqlClient& /&
&/connectionStrings&
&/system.web& 标记结束的地方,添加下面的节点,这里用
AspNetSqlMembershipProvider和
AspNetSqlRoleProvider来命名比较好记,等之后配置的时候使用
FBAMembership和
FBARoles,这个命名是次要的,主要是数据库指向的字符串名字和应用程序的名字要正确.
&membership defaultProvider=&AspNetSqlMembershipProvider&&
&providers&
&add name=&AspNetSqlMembershipProvider&
connectionStringName=&AspNetSqlProvider&
applicationName=&/&
type=&System.Web.Security.SqlMembershipProvider, System.Web,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a& /&
&/providers&
&/membership&
&roleManager defaultProvider=&AspNetSqlRoleProvider&&
&providers&
&add name=&AspNetSqlRoleProvider&
connectionStringName=&AspNetSqlProvider&
applicationName=&/&
description=&Stores and retrieves roles data from the local Microsoft SQL Server database&
type=&System.Web.Security.SqlRoleProvider, System.Web,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a& /&
&/providers&
&/roleManager&
使用web site管理工具添加用户
默认情况下程序配置为windows认证，需要改成forms认证,切换到安全选项卡,点击来自网络并且保存.
保存后web.config会默认已经被修改成forms认证.在安全选项卡启用角色,点击管理或创建角色,选择
FBAAdministrators,
FBAOwners和
点击创建用户链接创建一个adminfba,并且分配角色为
FBAAdministrators
你还可以创建其他的用户并且分配到不同的角色里面,如ownerfbs分配到
FBAOwners角色中，userfbs分配到
FBAUsers角色中
另外创建用户的时候密码有一些要求.
给SQL Server加权限
当我们创建了sharepoint的application,我们需要在IIS的应用程序池里面设置为网络服务帐号.这个可以连通sql认证.或许你需要在真实的环境中使用其他的帐号.
需要为应用程式池添加一个登陆账号.
下一步为他们添加适当的权限,把帐号添加到
aspnet_Membership_BasicAccess 和 aspnet_Roles_BasicAccess 角色中
千万要记住必须做这些设置,不然回报安全错误.
给sharepoint加基于form的认证
添加的方法同asp.net站点一样,不过我们可以使用IIS 管理工具来添加.
添加连接字符串
打开站点名字为
SharePoint – FBA Test
双击连接字符串选项,并且添加一个名为
AspNetSqlProvider 然后点击确定.
然后到sharepoint的web.config检查如下：
connectionStrings
=&AspNetSqlProvider&
3: connectionString
=&data source= Integrated Security=SSPI;Initial Catalog=&
4: providerName
=&System.Data.SqlClient&
connectionStrings
然后到管理中心作如上操作.
再到web service里面找到节点
SecurityTokenServiceApplication添加连接字符串同上.
添加memebership和role的角色
打开IIS管理工具,展开
SharePoint – FBA Demo，点击provider,创建一个
FBARoles角色并且类型为
SqlRoleProvider,应用程序输入“/” &连接字符串选择
AspNetSqlProvider
再添加一个
FBAMembership角色,类型是
SqlMembershipProvider,连接字符串为
AspNetSqlProvider,application是“/”
所有添加完了之后打开配置文件就是这样：
membership
defaultProvider
=&Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c&
=&FBAMembership&
=&System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&
applicationName
connectionStringName
=&AspNetSqlProvider&
enablePasswordReset
enablePasswordRetrieval
passwordFormat
requiresQuestionAndAnswer
requiresUniqueEmail
membership
roleManager
defaultProvider
cacheRolesInCookie
=&Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c&
=&FBARoles&
=&System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&
applicationName
connectionStringName
=&AspNetSqlProvider&
roleManager
SharePoint Central Administration v4” 做如上操作,添加
FBAMembership 和
FBARoles 像之前描述得那样.展开
SharePoint Web Services做法雷同.
为管理中心修改web.config
&为令牌服务(secure token service)修改web.config
验证是否已经修改成功
然后到管理中心去打开添加用户,如果在弹出的对话框中可以看到在membership中配置的用户和角色,那么说明已经正常了,
用户的字符串像这个样子：
“i:0#.f|fbamembership|adminfba”.
然后把用户设为full control
在新站点上可能看到如下错误,
选择forms认证并且登录为adminfbs即可.
登录进去你将拥有管理员的权限.
现在这个用户有完全控制,可以把之前在memebership中的角色配置到sharepoint组里面.
然后用其他的各种角色的帐号测试一下. 权限低的角色将限制了一部分权限.
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致1683人阅读
SharePoint（5）
SharePoint 2010在用户认证模式上，较之以前的版本有了非常大的改变。在SharePoint 2010中，当你创建一个Web应用程序的时候，有两种认证方式可供选择：
1、 Classic Mode Authentication
就是传统的Windows认证模式，用户认证和用户身份都是标准的Windows认证机制；
2、Claims Based Authentication
基于声明的认证模式，这是一种全新的认证和用户身份标识机制；之所以成为基于声明的认证，用户的身份是以一个一个的Claim（声明）来标识的（你 可以把一个Claim理解成一个属性，比如Name=Ipark就可以是一个Claim）。
SharePoint 2010中基于Claims的身份认证分成两部分：一个是用户认证，一个是用户身份。
& 用户认证可以支持多种方式：NTLM、表单认证等；
& 用户的身份信息则是统一为一组Claim，在浏览器中Claim会存储在Cookie里面;
关于SharePoint 2010的身份认证模式有下面几点信息供大家参考：
1）默认情况下，创建Web应用程序的时候，会默认选择Classic Mode Authentication；但是，推荐默认选择使用Claims Based Authentication（默 认下还是会为基于声明的方式选择NTLM的认证方法）。因为，选择基于声明的认证模式，对于用户来说没有任何区别，也不需要有额外的配置工作。这样的做法 是为了将来扩展认证方式提供基础，而且不会有从Classic模式往Claims模式转换过程中用户迁移造成的一些问题，比如Alert不工作，搜索的问
2）从Classic模式转换成Claims的模式，在管理中心中没有管理界面进行配置，需要使用脚本进行，可以参考下面的文章：
3）从Classic模式转换成Claims模式是不可逆的过程， 进行转换前需要对Web应用程序进行备份是一个最佳实践！
4）在Claims模式下，可以在同一个Zone（区域）下支持多种认证方法，在之前的版本中每个Zone仅支持一种认证方法；这意味着我们可以为单一的URL支持多种用户认证方法；但在同一个Zone下，仅支 持包含唯一的FBA和唯一的Windows认证方法
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：192482次
积分：2315
积分：2315
排名：第12184名
原创：37篇
转载：69篇
评论：21条
(1)(3)(7)(1)(6)(5)(2)(4)(1)(1)(6)(6)(5)(7)(1)(2)(20)(3)(3)(13)(6)(3)
关于职业规划、就业面试、人际关系、心理咨询等方面的信息sharepoint2010 身份验证~~~~~~~~~~~~~~~~~~~~~~~webservice&貌似只有表单验证的方法。sharepoint2010要AD的啊，AD和sharepoint本来就是可以分开的，将sharepoint服务器加入AD域就可以了楼主的问题很诡异sharepoint2010要AD的啊，AD和sharepoint服务器本来就是可以分开的，将sharepoint服务器加入AD域就可以了我的意思是sharepoint&server2010&使用的认证方式是windows认证，如果调用MOSS&提供的webservice进行认证？WebService不只支持表单认证&&Credential可以指定为域用户有三种验证方式1.&AuthHeader&验证2.&windows集成验证&&&1）&webService.Credentials&=&new&.Net.Credential("username",&"password","domainname");&&2)&webservice.Credentials&=&System.Net.CredentialCache.DefaultC3.&session验证在右键&添加服务引用的&画面上&有一个&高级&选项&点开以后&有一个&添加web引用的&按钮&你在&输入http://Server_Name/Subsite_Name/_vti_/Lists.asmx这样的地址&就可以找到了&特色：&|&&|&&& 热点：&|&&|&
当前位置：&&&&&&&&&&&&理解SharePoint 2010中基于声明的身份验证——扩展可信的身份验证提供程序的范围
理解SharePoint 2010中基于声明的身份验证——扩展可信的身份验证提供程序的范围
&&&&&&&&&&&& 期数：&&&&&&&&&&&& 作者：null编辑
声明当一个声明呈现给一个web应用程序时，这个声明包含关于用户身份的断言，它还可以包含关于用户的组成员身份的信息。基于声明的身份验证中的每一个可用的身份验证方法都可以把添加在声明中的用户的组成员身份的列表提供给STS。但是一个声明除了可以提供用户及其所属组别之外还可以提供其它信息，而这也使声明变得更有价值。让我们假设你想从一个网站发送一个电子邮件消息给用户，你怎么确定用户的电子邮件地址？你可以构建和维护一个本地的用户电子邮件地址数据库，但是在一个AD DS域，那些信息存储在AD中，所以你需要将AD中的更新同步到本地。或者你也可以添加代码，每次当你需要电子邮件地址的时候都用它来查询AD。这两种方法都需要应用程序开发人员做出额外的工作。一个声明可以包含用户的电子邮件地址或用户的其它属性，如用户的经理、经理的电子邮件地址、部门、职称、年龄或性别。只要STS和web应用程序进行了适当的配置，STS就会收集这些属性并将其打包到声明中。因为声明是由用户提供给web应用程序的，所以web应用程序就不需要自己维护一份这些属性的本地副本，也不需要在一个外部的数据源中查找这些属性。因此，基于声明的身份验证减轻了应用程序维护和查找用户信息的负担。声明中的属性可以用于多种目的，用户的电子邮件地址声明可以用于给用户发送警报。用户的年龄声明可以用于提供对年龄受限的内容的访问，用户的经理声明可以用于一个工作流中的休假请求审批。你还可以基于声明分配内容权限。例如，你可以指定只有副总以上职务的人才可以访问某些内容，你还可以使用声明来查找用户。例如，如果你想给某位用户安排一项工作，但你只记得该用户的经理，选择器控件可以显示属于该经理管理下的所有用户。开发人员都为SharePoint2010支持声明所呈现出的可能性而激动不已。联合让我们假设web应用程序中的特定内容只允许你的公司Contoso或合作伙伴公司Litware的员工访问，怎么实现这个功能呢？一种方法是将Litware的用户账户全部拷贝到你的AD DS域或一个单独的数据库并且保持同步更新，但显然这是个负担。更简单的做法是依赖于Litware的管理员来维护他们的用户账户，你只需要信任Litware所做的身份验证即可。利用Windows域，你可以配置一个Contoso域信任Litware域的信任关系。但是，防火墙可能阻止信任的正确建立和维护，而且许多组织还有禁止Windows信任外部组织的策略。基于声明的身份验证支持联合（类似于由Microsoft 的ADFS或Ping Indentity的PingFederate提供的解决方案），它将信任和声明的概念扩展到第三方。例如，你可以将ADFS2.0配置成针对两个域来验证用户，而不需要建立信任关系。然后你也可以将SharePoint的STS配置成信任ADFS2.0暴露出的STS。从术语的角度看，SharePoint的STS变成了信赖方STS（RP STS），而ADFS2.0的STS变成了身份验证方STS（IP STS）。当一个用户尝试访问一个网站，该网站将用户重定向到IP STS进行身份验证。由IP STS（这个例子中是ADFS2.0）签发的SMAL令牌接着呈现给RP STS（这个例子中是SharePoint的STS），它可以在将令牌返回给客户端之前在令牌中添加额外的声明，然后这个令牌会被客户端提交给web应用程序。另外一个联合身份验证的例子是Windows Live ID身份验证，你可以将SharePoint的STS配置成信任Windows Live ID签发的令牌。SAML令牌SAML令牌可以包含一个用户的任意多个声明，如用户名和所属组别以及其它描述属性。依赖方应用程序接收到SAML令牌并使用其中的声明来决定是否允许这个客户端访问所请求的资源。所以，令牌中的某个声明必须唯一地标识这个用户，这就是所谓的身份声明。当用户登录到IP-STS时IP-STS不必利用提交的用户名创建一个身份声明。例如，AD FS不必使用一个用户的域用户名创建身份声明。相反，IP-STS可以使用其它的唯一标识符来创建身份声明。许多声明的实现都使用电子邮件地址属性作为身份声明。对于IPSTS创建的令牌，RP-STS必须知道令牌中的哪一个声明是保证唯一的。基于这个原因，配置一个使用基于SAML令牌的声明环境需要RP-STS和IP-STS管理员之间的协作，以下这些要素必须协调一致：在SharePoint 2010产品中，每一个配置成使用SAML提供程序的web应用程序都被作为一个单独的RPSTS项添加到IP-STS服务器中。IP-STS所有者负责完成这项任务。每个web应用都被认为是一个领域，简单来说就是与信赖方web应用程序关联的URL命名空间（如）只有IP-STS的所有者才知道令牌中的哪一个值对每个用户总是唯一的，因此这个值可以可靠地被认为是身份声明。这些信息必须事先被告知IP-STS的所有者。令牌使用IP-STS产生的加密证书签名，这个加密证书必须从IP-STS传送给RP-STS。使用SharePoint 2010实现一个基于SAML令牌的身份验证包括以下步骤：1. 从IP-STS中导出令牌签名证书。这个证书就称作ImportTrustCertifi cate。2. 将该证书拷贝到SharePoint Server 2010 场中的服务器。余下的步骤都在这台服务器上进行：3. 定义一个将被用作用户唯一标识符的声明。确定该用户的唯一标识符是声明映射流程的一部分。你可以使用PowerShell来执行声明映射。4. 定义其他的声明映射（例如定义将被RP-STS使用的令牌中的其它值）。例如，许多令牌包含了一个指定用户角色的值，该值可以在SharePoint Server2010 场中用于资源访问许可控制。传入的令牌中所有没有映射的声明都将被丢弃。5. 使用PowerShell创建一个新的身份验证提供程序。这个过程会创建SPTrustedIdentityTokenIssuer。在这个过程中，你提交ImportTrustCeertificate、身份声明映射以及其他的声明映射。你也必须创建和指定一个领域，这个领域指的就是你正在为其配置基于SAML令牌身份验证的第一个SharePoint web应用程序所关联的URL命名空间。6. 在SPTrustedIdentityTokenIssuer创建好之后，你可以为其它的SharePoint web应用程序创建和添加更多的领域。这就是你将多个web应用程序配置成使用同一个SPTrustedIdentityTokenIssuer的方式。对每个你加入到SPTrustedIdentityTokenIssuer中的领域，你必须为其在IP-STS中创建一个RP-STS项。7. 创建一个新的SharePoint web应用程序并且将其配置成使用这个新创建的身份验证提供程序。当你为这个web应用程序选择声明模式时，这个身份验证提供程序就会作为一个可选项在Central Administratin中出现。你可以配置多个基于SAML令牌的身份验证提供程序。但是，在一个场中你只能使用一次令牌签名证书。所有配置的身份验证提供程序都会作为可选项在CentralAdministration中出现。来自不同的受信任STS环境的声明之间不会产生冲突。如果你正和一个合作伙伴公司实现一个基于SAML令牌的身份验证，并且你拥有含有IP-STS的环境，我建议你同内部声明环境管理员一起，建立一个从你们内部IP-STS到合作伙伴STS之间的信任关系，结果形成一类信任和身份验证的链，在这里面，你的SharePoint应用程序信任你的IP-STS，你的IP-STS信任合作伙伴的IP-STS，因此这样就保证了身份验证（如用户身份的维护）是被各个组织独立管理的。这个方法不需要为你的SharePoint Server 2010添加另一个身份验证提供程序。它还允许你的声明环境管理员管理整个声明环境。注意，如果你在一个SharePoint Server 2010 场中使用基于SAML令牌的身份验证，而且这个场包含多台处于负载均衡配置中的web服务器，那么客户端的网页查看的性能和功能可能会受到影响。当AD FS将验证令牌提供给客户端的情况下，客户端每次访问许可受限的页面元素时都会将该令牌提交给SharePoint Server 2010。如果负载平衡的解决方案没有用到关联，每个受保护的元素需要被一个以上SharePoint Server 2010服务器验证，这可能导致令牌被拒绝。当令牌被拒绝后，SharePoint Server 2010将客户端重定向回AD FS服务器重新进行身份验证。当这种情况发生后，AD FS服务器可能会拒绝短时间段内的多次验证请求，这种行为是故意为之的，其目的是为了保护系统免受拒绝服务（DoS）攻击。如果性能受到不利（原文来源于：）
相关标签：
阅读：34次
前一篇：null
后一篇：&&&&&&& 　null
相关文章：
&&&&&& null
&&&&&& null
&&&&&& null
&&&&&& null
&&&&&& null
期 蜘蛛价：? (? )
刊物类别：
本期热门文章
8:00-23:00（全年无休）}