Windows Live ID Federation
(翻译自：http://msdn2.microsoft.com/en-us/library/cc287610.aspx)
The Windows Live™ ID 服务 ，一个微软在线资源的身份认证系统，比如msn，以及windows live服务，可以作为一个与第三方验证服务一起工作的联合身份系统，这种能力使得被第三方托管的用户得以无缝得访问windows live 服务。通过与Windows Live ID协作的联合身份，合作伙伴可以让他的用户访问到自己的资源，还有windows live服务，而不必要2次登陆。
联合服务概述
联合认证关系用于将一个组织的用户申明安全地传递给另外一个被认证的组织。用户因此可以在他们的身份认证提供商（保存用户帐户的地方）那登录并被验证，然后把验证信息传递给联盟的另外一个提供商，比如msn，并且通过联盟里另外提供商的认证，进而可以授予用户访问他们联盟资源的权利。这个联盟里提供资源的一方，叫做资源提供方。
什么是Windows Live ID?
许多的windows live 服务，比如博客，社会网络关系，等都需要用户先通过验证，Windows Live ID在整个windows live 生态系统里，管理者他们的认证。
Windows Live ID 接收用户的信任状（比如邮件地址和密码），验证他们是否合法，并且生成一个Windows Live的验证令牌，这个令牌可以发送给windows live 的各个服务（hotmail邮件，msn，博客等）来验证用户的身份的。
什么是联盟（Federation）
联盟是2个组织之间基于某种目的，需要建立一个相互信任的协议，双方的认证断言都可以被彼此认证接受的。
联盟的双方：
身份验证提供方验证用户的身份账户，使得用户可以访问第三方的资源而不必拥有第三方的账户。
资源提供方认可身份验证提供方给用户提供的身份验证凭据，并且准许用户访问其受保护的资源。
这种信任关系可以是双向或者单向的。
通过建立这种身份验证联盟，一个组织不但可以提供他的用户访问自己资源的权利，而且可以访问联盟里面其他成员的资源的权利。因此组织不但可以管理自己的用户账户，并且使得自己的用户访问大量的并不是由自己建立的资源。
Windows live 联盟建立在WS-* 的一系列规范下，例如WS-Trust WS-Security。这些规范协同提供一个可定制的安全策略，共同提供一个设计简单的互操作性，改善的安全性，以及间的的测试的环境。通过使用这些工业级的标准协议，2个组织间可以建立一个联盟身份关系，而不需要彼此都使用一种身份硬件平台或者软件架构，也就是说这种规范的平台无关性和语言无关性。
这幅图表示了一个典型的联盟关系的信任边界
Policy（策略）是管理者验证和授权的细节。比如windows live 服务可能有一个策略就是通讯需要SSL，或者只允许一个特定的时间访问认证服务。
联盟的好处
用户将体验到单点登录（SSO）带来的巨大好处，他们只需要登录一次就可以访问联盟内提供的许多资源。
组织将不必自己建立繁杂的服务提供给自己的客户，他们只需要加入到联盟中来。
联盟的一个主要的好处在于它提供了一种简单的，易于维护的身份认证管理方式。
联盟的windows live ID身份依靠身份提供商发给windows live ID 服务的工业级的令牌是被自动的创建和更新，身份提供商没有必要为自己的用户自己去建立维护或者删除windows live ID 身份。当用户第一次访问受保护的windows live服务的时候Windows live ID自动的在联盟提供商和新的windows live ID 身份提供商之间创建一个映射关系。
身份提供商的已经被废弃的用户不可以再次登陆到身份提供商，他也不可以以联盟身份提供商用户的角色访问windows live 服务，因为已经没有验证令牌从身份从身份提供商方面传递给windows live ID。
联盟系统架构
在一个身份认证联盟组织内的两个组织间，一方，作为身份提供商，控制自己的用户账户，而另一方，作为资源提供方信任身份提供方提供的验证信息，并授予其用户访问自己资源的权利。在这个环境下，用户的身份是被定义为一系列的申明（claims），一个申明就是一个服务器端为一个客户端用户作出的陈述，比如用户姓名，身份，组，许可证，权限范围等。所以身份联盟的一个目的就是分享身份申明。
在Windows live ID联盟里，验证数据从身份提供商方（用户帐户管理方）转变成一系列的标准格式的数据，被转为使用ＷＳ-*规范描述的ＳＡＭＬ（安全断言标记语言），然后发送给windows live ＩＤ服务。Windows live ID服务又将其转换成一个本地级的windows live 服务令牌。SAML 开放式的标准XML格式，用于跨越安全领域交换验证信息。
下图显示了一般的申明信息在联盟2个提供商（身份提供商和资源提供商）之间是如何传递的。
Windows live ID身份联盟
Windows live ID身份联盟是一个基于微软windows live ID服务和可信任的第三方合作伙伴间的标准组织关系。
建立这种协作组织关系的目的就是要在互联网间分享用户的数字身份。这种分享用户验证信息的方式可以在瘦客户端和胖客户端提供给用户一个很好的单点登陆体验。
下图表示一个身份提供商的用户去请求windows live 服务的一系列动作。
1. 用户发送验证信息给他所属的身份提供商。一个用户提供他的用户名和密码给他的身份提供商，然后身份提供商的安全令牌服务（STS）生成一个身份令牌返回给用户。IP/STS的目的就是发布一个安全令牌给用户。
2. IP令牌传递给windows live ID服务 windows live ID STS（安全令牌服务）将来自身份提供商的令牌转换成window live 服务的令牌。发送给windows live ID的令牌包含一个唯一的不可变的用户标识符（用于在windows live ID服务商映射标识用户数据信息的）。例如 UniqueImmutableID@contoso.com。令牌同时也包含一个友好的标识符，邮件地址的格式，windows live 服务为用户使用例如someone@contoso.com这样的标识符。windows live ID在令牌里使用唯一的标识符来决定这个用户是以前登录过的还是第一次登录访问windows live 服务。
Note:
另外映射联盟用户信息到windows live 中，并且将信息发给Windows live ID服务 的时候令牌里面同时也包含了一些关于身份的额外嘻嘻你，比如改变用户名，账户对话，和个人设置更新等。这个部分内容会在第二部分提及。
3. 被windows live ID服务转换的令牌发送给Windows live 服务。当Windows live ID 转换了来自联盟身份提供商的令牌为windows live服务所期盼的Windows live 令牌后，令牌将被发送给用户最原始的请求目的地：Windows live 服务。
如上图所示的联合登录，联盟的合作伙伴发布一个表示已验证身份的用户信息的令牌给Windows live ID服务，在非联盟的环境下登录Windows live ID，用户直接提供他的Windows live ID 用户名和密码就可以直接登录到Windows live ID服务。而另外一种形式登录到Windows live ID服务，也就是以联盟用户的身份登录的话也是获得同样的Windows live 格式的令牌。
数据流程
胖客户端和瘦客户端的登录方式略有不同，他们的数据流转方式将稍后讨论。另外的动作，比如改变用户名，转换账户，更新个人信息，和登出将会在第二部分讨论。
浏览器登录数据传递流程
Web 登录时一个联合身份场景中的一个重点，下图表示了基于web登录的数据流转。
1. 浏览器视图去访问一个受保护的Windows live 服务，比如 hotmail。
2. Windows live 服务将浏览器重定向到它自己的身份提供商，即Windows live ID。
3. 决定用户属于哪个合作伙伴，也就是用户使联盟用户还是windows live ID用户。这个决定的过程成为领域发现。
4. 如果用户是一个联盟用户，那么Windows live ID就将用户重定向到她的身份提供商网站。
5. 用户身份提供商的网站上将显示一个登录界面要求用户输入用户名密码。
6. 用户登录
7. 身份提供商返回一个验证令牌（基于SAML格式）通过重定向浏览器发送给Windows live ID服务。
8. Windows live ID通过重定向将一个windows live的验证令牌给Windows live 服务。
9. Windows live服务通过了用户的验证，并且返回给了用户最初在第一步的时候请求的数据。在这个例子中，用户请求hotmail.最终用户经过以上几步后看到了自己的收件箱。
如果用户已经通过了验证的话，不是所有的步骤都需要走完。在这种已经通过验证的情景下，用户再去访问windows live 服务的话那服务就直接跳到第9个步骤，并不需要中间的步骤来信任这个用户了。
智能客户端登录流程
客户端程序在本地的PC或者移动设备上运行，所以他们发送用户的验证信息与web上的不同，在这个例子中我们借用 Windows live messenger ，但是只能客户端也可以是其他的Windows 程序或者移动设备上的应用程序。
注：此为一个示例，具体支持联盟认证的msn仍然在开发中。
用户体验
接下来我们讨论用户通过浏览器或者智能客户端访问Windows live 服务的过程。
整个过程因为用户是否已经通过验证而不同。比如如果一个身份提供商使用的是使用的Active Directory® Federation Services (AD FS)作为他的身份验证服务，那么他的用户认证信息将在一个可配置的时间段内过期，并且需要重新登录。
浏览器登录
当用户用浏览器访问一个被保护的资源，用户会被跳转到如下的屏幕：
用户可以自由选择使用windows live ID的用户名和密码，也可以选择联合登录，使用PaertnerID，如下图所示：
用户如果选择使用PartnerID，那么需要使用联盟身份提供商里的邮件地址名。Windows live ID 然后将用户跳转到联盟伙伴的登录页面来让用户输入用户名和密码。
智能客户端登录
当用户从智能客户端来访问Windows live 服务的时候，他们不需要基于浏览器的跳转体验。在下面的途中，将给出用户使用智能客户端登录的流程。
实施步骤
这个部分将包含如何与Windows live 服务建立和实现联合身份认证的信任关系。他包含以下内容：
建立信任——建立和管理联盟身份信任关系
验证用户——交换验证申明来登录和登出用户。
用户身份和个人信息管理——基于令牌消息的用户数据交换。
建立信任
如果一个组织想要跟windows live ID建立联盟合作伙伴关系需要：
签署一份商业合同。
采取一定的工业级标准的安全措施
提供给Windows live ID的信息
这些信息需要想加入联盟的组织需要准备的信息：
· 域名—公司的主域名
· Web登录地址—比如http；//www.sina.com/login.aspx
· 客户端登录地址—比如http；//www.sina.com/login.aspx
· 登出地址—用户登出的url地址，（可选项）
· Partner URI—发布SAML令牌的地址
· X.509 的登录证书—用于验证信息的签名。
· Partner 友好名称—用于标识这个合作商的一个友好的名称，比如sina，vnet等。
Windows Live ID提供给Partner的信息
Windows live ID要提供一些必要的URL给合作伙伴。微软将提供指定的url给合作伙伴。
验证用户
Windows live ID对web登录使用WS-Federation，对智能客户端使用WS-Trust 规范。也使用了WS-*规范比如 WS-Security,ws-SecureConversation,WS-Policy等。
接下来要讨论浏览器和智能客户端的消息交换，另外附件是一个包含了一些实际的Http消息交换例子。
浏览器登录
下图显示消息的传递。在这个例子里，联盟用户访问hotmail.
1. .用户试图访问受保护的hotmail资源
2. 资源方将其跳转到他的身份认证提供方，windows live ID服务。
3. 浏览器从windows live ID服务那请求一个登录令牌。
windows live ID决定那个Partner拥有用户的账户，即前面提到的领。域发现
4. 如果用户是个联盟用户，windows live ID将把用户跳转到用户的身份管理认证方，来验证身份。
5. 浏览器跳转到用户身份提供商的STS（安全令牌服务）那，也就是那个提供给微软的web的登录界面。身份管理方显示一个界面让用户输入用户名密码。
6. 身份管理方将返回一个验证令牌给用户并且跳转。
7. 浏览器将令牌传递给windows live ID服务。
8. windows liveID服务返回一个验证的Windows live令牌
9. 浏览器将令牌传递给Windows live 服务。
10.hotmail通过验证最终展现给了客户。
智能客户端登录
1. WLM（Windows live Messenger）发送用户名给Windows live IP/STS来决定由胡的领域。
2. Windows live IDIP/STS返回领域信息。
3. WLM发送登录的用户名和密码给身份管理方的IP/STS。
4. 身份管理方的IP/STS返回联盟的登录令牌。
5. WLM发送联盟登录令牌给windows live ID IP/STS
6. Windows live ID IP/STS返回Windowslive messenger 的登录令牌。
7. The Windows Live Messenger client sends the Windows Live Messenger sign-in token to the Windows Live Messenger service.WLM发送WLM的登录令牌给WLM 服务。
8. The Windows Live Messenger service grants access to the service and returns user content as requested.WLM服务准许用户访问服务并返回内容给WLM。
浏览器登出
删除浏览器内含有验证信息的cookie。
下面的示例就是用户在hotmail页面点击登出按钮，用户就可以登出Partner的网站。
1. 用户在hotmail页面点击退出
2. hotmail重定向到其IP/STS，即windows live ID
3. Windows live ID执行某些清理工作。
4. windows live ID重定向到登出的IP/STS。
5. 身份管理方删除自己网站的cookie。
6. 身份管理方继而重定向用户到Windows live ID服务的登出页面。
7. Windows Live ID 完成了登出操作，删除所有cookie
8. Windows Live ID 发送一个 “clean-up complete” 消息给浏览器。
智能客户端登出
一个智能客户端可以以某种缓存的形式存储验证信息，类似于浏览器使用cookie来存储信息。当用户退出时智能客户端可以清除这种缓存的验证信息。因此没有必要让智能客户端与身份管理方STS，Windows live ID STS交互，或者是实际的服务本身来登出用户。
用户标识符和个人信息管理
除了登入和登出，还有其他的几个普通场景发生于联合身份中。以下的一些场景可以通过传递Windows live ID的验证令牌来实现。
- 身份创建
- 用户名改变
- 个人信息更新
- 账户转换
身份创建：
一个联合身份包括用户身份，身份提供方，和windows live ID标识符之间的联合关系。
当用户访问Windows live 服务的时候在这两个系统之间的标识符映射关系是被自动创建的。一个新的联盟用户的验证令牌将导致Windows Live ID来创建一个影子身份，这个影子身份是用来绑定用户的email和不可变的唯一标识符的。
影子身份可以使用户的私人信息持久化存储在windows live ID里面，并返回给Windows live 服务做某些参照。
改变用户名
一些windows live 服务在界面上显示友好的用户名。这样可以使得用户在与其他用户交互的时候使用的名字，比如当加入一个好友到你的WLM的好友列表的时候。
联盟身份提供商可以改变用户的名字，比如从bob@fabrikam.com改为robert@fabrikam.com。用户名的改变将自动地被windows live ID服务更新并且继续映射联盟用户的私人信息。（只有用户名可以被改变，唯一标识符是不可以改变的）
当用户名改变了，一个新的用户名在验证令牌中被检查到，并传递给windows live 服务，这样服务就能自动显示正确的用户名了。
个人信息更新
在windows live 网络内，个人信息有时候是需要的。比如有些服务必须要限制只有年满18岁的承认才可以使用。联盟伙伴必须要有能力来共享用户的某些信息给Windows live ，这样Windowslive就不必自己独自地来收集这些信息。
标准的Windows live ID账户使用一个邮件地址作为用户名的。但是用户可能创建一个与微软无关的邮件地址作为用户名，如果这个组织已经拥有这个域名，并且加入了联盟，那么这个组织必须要选择一个Windows live ID账户。
· 清除已有的Windows live ID账户这种情况下，新联盟用户访问Windows live 服务会以一个新的联盟身份来开始。Windosw live ID用户被驱逐出去，并且在下次登录的时候强制用户输入一个不同的域名。
· 将已经存在的Windows live ID账户转换成联盟账户份管理方然后控制和管理转换后的联盟账户。转换后，用户只有在获得了联盟身份提供商的验证后就可以访问他们已经存在的Windows live 内容，（这些用户就不可以直接使用Windows live ID来直接登录访问Windows live ID资源了。）
集成Windows live ID联盟
以下的部分包含详细的信息来指导如何集成Windows live 联盟。
使用令牌维护联合身份
身份管理方提供给Windows live ID服务的登录令牌默认机制是在Windows live ID服务内建立和维护用户身份的。
当一个联盟用户访问Windows live 服务，他的身份提供商验证用户并且在令牌里传递信息给Windows live ID。令牌包含一系列关于此用户的申明（断言），包括：
- User ID—唯一标识这个用户的唯一标识符。
- User name—用户的邮件地址。在Windows live 网络里，这个就是用户的电子邮件地址。
- Profile data—用户所在国家和生日等的信息。
Note:
用户的密码并不会被在令牌中传送。
我indoslive ID使用这些令牌里的信息来在某些场景下使用。
下面的部分提供一些场景实现的细节。
身份创建
当Windows live ID服务受到一个验证令牌的时候，他就检查这个用户的ID。
- New user ID.如果Windows live ID判断是新的俄用户ID的话，并且第一次访问资源，那么就会创建一个影子身份给这个联盟用户。影子身份包含一个唯一的用户ID，这样使得Windows live ID来存储这个用户的私人数据。比如这个用户的MSN好友列表
- Shadow identity already exists. If Windows Live ID already has a shadow identity for the user ID, it sends that user ID as the user’s unique Windows Live ID identification to the Windows Live service that the user requested.如果Windows live ID已经存在了这个用户ID的影子身份，他将会发送用户ID给Windows live 服务。
已经存在身份的数据能够被更新。
下面是一个来自创建新影子身份令牌里的异常。一个有效的令牌包含一个新的用户ID，他将导致Windows live ID 创建一个新的身份。这个令牌必须包含一个有效的电子邮件地址。
<saml:Subject>
<saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/UPN">12345@contoso.com</saml:NameIdentifier>
</saml:Subject>
…
<saml:Attribute AttributeName="EmailAddress" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>user@contoso.com</saml:AttributeValue>
</saml:Attribute>
改变用户名
当windows live ID服务受到一个唯一用户ID的登录令牌，它会检查看这个用户的唯一标识符的用户名是不是跟以前联系的不同，如果不同，那么他就会自动去更新这个用户名。
<saml:Subject>
<saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/UPN">12345@contoso.com</saml:NameIdentifier>
</saml:Subject>
…
<saml:Attribute AttributeName="EmailAddress" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>newUserEmail@contoso.com</saml:AttributeValue>
</saml:Attribute>
设置更新
来自身份提供商的验证令牌包含用户的私人数据，例如生日，国家。Windows live ID比较设置信息，如果不一致，则Windows live ID自动将新令牌中的数据覆盖到原有用户信息中。
Windows Live ID can receive the following profile data in a token:
Windows live ID能够在令牌中存储以下的设置数据
· 版本号信息
· 国家州市一级邮政代码
· 出生日期
· 名字
下面是摘录自一个提供版本号的令牌：
<saml:Attribute AttributeName="Authorization_CS.WinLiveTOUVersion" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>4</saml:AttributeValue>
</saml:Attribute>
下面是摘自一个提供国家等地理位置信息的令牌：
<saml:Attribute AttributeName="Addresses_CS.Home.Country" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>US</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="Addresses_CS.Home.Region" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>35841</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="Addresses_CS.Home.PostalCode" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>98052</saml:AttributeValue>
</saml:Attribute>
下面是摘自含有用户生日的令牌：
<saml:Attribute AttributeName="Personal_CS.Birthdate" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>2:2:1969</saml:AttributeValue>
</saml:Attribute>
下面是摘自含有用户名字的令牌：
<saml:Attribute AttributeName="Personal2_CS.Name.First" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>Nancy</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="Personal2_CS.Name.Last" AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>Anderson</saml:AttributeValue>
</saml:Attribute>
![clip_image005[1]](https://images.cnblogs.com/cnblogs_com/perfectdesign/WindowsLiveWriter/WindowsLiveIDFederation_DF82/clip_image005%5B1%5D.gif){kind=small}
Note:
Windows live ID只接收新的个人信息数据，不是更新已有的个人信息数据。这是因为用户可以在Windows live网络里 更新他们的个人数据可能导致并发问题发生。
账户转换
如果电子邮件地址和一个已经存在的Windows live ID账户相吻合，Windows live 就需要显示一个界面让用户来解决账户转换的问题。
Figure 14 shows the account-conversion UI. Users are given a choice between merging their existing Windows Live ID account with their federated account (so they can access their existing Windows Live data from the federated account) or keeping the accounts separate.
下图显示了账户转换的界面。用户可以有2个选择来合并他们的已有Windows live 账户和联盟账户或者保持现有的账户独立。
附件
登录令牌（SAML）：
<wst:RequestedSecurityToken>
<saml:Assertion MajorVersion="1" MinorVersion="1"
AssertionID="saml-eb29eb6f-a66f-4919-b811-c8095bc5631b" Issuer="urn:federation:ppmt"
IssueInstant="2007-01-29T23:47:59.859Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2007-01-29T23:47:59.859Z"
NotOnOrAfter="2007-01-30T23:47:59.859Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>uri:WindowsLiveID</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:Advice></saml:Advice>
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2007-
01-29T23:47:59.859Z">
<saml:Subject>
<saml:NameIdentifier
Format="http://schemas.xmlsoap.org/claims/UPN">
12345@contoso.com</saml:NameIdentifier>
</saml:Subject>
</saml:AuthenticationStatement>
<saml:AttributeStatement>
<saml:Subject>
<saml:NameIdentifier
Format="http://schemas.xmlsoap.org/claims/UPN">
12345@contoso.com</saml:NameIdentifier>
</saml:Subject>
<saml:Attribute AttributeName="EmailAddress"
AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>user@contoso.com</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>
<Reference URI="#saml-eb29eb6f-a66f-4919-
b811-c8095bc5631b">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform>
<Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>QwFNFgDXiixYU4dPx/OiW/ljZ0k=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
smV9pEH0vxnqsCjLIYSKAmMK09qTXH9eL4sxIbTxGeO7WilUWL8HuMjidYzy84Hwq4a
HX/F4GKD9IIfJVyckRJD4cgNxyIwsI/hg8AMu3XTlAw7ser77TZl0XN4mUl4nmYYMNiM7eKAxiMdRtrIzPBy
KtPEDQt2aXLJZxYbrvI4=
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
MIIEbTCCA1WgAwIBAgIGEREREREKMA0GCSqGSIb3DQEBBQUAMIGAMQswCQYDVQQGEwJVUzELMA
kGA1UECBMCV0ExEjAQBgNVBAoTCU1pY3Jvc29mdDERMA8GA1UECxMIUGFzc3BvcnQxEDAOBgNVBA
cTB1JlZG1vbmQxKzApBgNVBAMTIk1pY3Jvc29mdCBQYXNzcG9ydCBJbnRlcm1lZGlhdUgQ0EwHhcNMD
UwMTIwMDI1NzMxWhcNMDkwMTE5MDI1NzMxWjBrMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0
ExEjAQBgNVBAoTCU1pY3Jvc29mdDERMA8GA1UECxMIUGFzc3BvcnQxEDAOBgNVBAcTB1JlZG1vbmQ
xFjAUBgNVBAMTDVBQTVRDbGllbnRTU0wwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO3vjTL
M1wrShUPltlIMI+agdv4M9wDYnJb41qDs3hgVHgkI16+Whjlqv51cIXsVSdyMmU53l9HtspWm2kB99T4Qu
fIqH9J+sVpgAEpDxd3wtadR5yJ6EdaDHjo1oiT/Po7/Bw9SuTa3+Y6w0qKLZ8S21NRCKrQjgRvkNAgMBA
AGjggGDMIIBfzAdBgNVHQ4EFgQUqQ6p0Axb3qWVLvkQ1aCrlCLEjZ8wHwYDVR0jBBgwFoAUgsKi783r5
SZNGJ8d+wZj+ij7lFowDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBaAwLgYDV0RBCcwJYEjcGFzc3Bvc
nRQUE1UY2xpZW50U1NMQG1pY3Jvc29mdC5jb20wgYMGA1UdIAR8MHoweAYKKwYBBAGCNxQzAjBqM
EMGCCsGAQUFBwIBFjdodHRwOi8vdWlhY2N0c3J2LWQubmV0LnBkbXNuLnRlc3QubWljcm9zb2Z0LmNv
bS9jcHMuaHRtMCMGCCsGAQUFBwICMBcaFU5vIExpYWJpbGl0eSBBY2NlcHRlZDBXBggrBgEFBQcBAQR
LMEkwRwYIKwYBBQUHMAKGO2h0dHA6Ly91aWFjY3RzcnYtZC5uZXQucGRtc24udGVzdC5taWNyb3NvZ
nQuY29tL21zcHBwY2EuY2VyMBMGA1UdJQQMMAoGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBA
QAGwnCoo2apTte0WkCeInPK3O22Pshu0FiFBmaO5NSByEweQKNRAkj9nP4m7hYZYw2e2DFJ++UgHIsU5
O95u9ozv7uiwikMNXyT3kalIvOgjphxTKW30fr0OHN011hx4Nr4JDdFVnK47stYq+feTZ6F9ryT82O3hx7c0v7
LQt2ucwlyHfwP7aVc71MGqf8oKKYSlM5jEmwkLyHg6Ec/ykI+evsT+kHShzyTj5nwkWouRiD9eiNNX0gqfZ
Ghoyh5wibhdioD/t0sAxh7TfuVgONJhzsvM88uyEpRxeI3sNB19LweHVTWtxc26rpuYGW7EFSrJURAXI
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</saml:Assertion>
</wst:RequestedSecurityToken>
注意
Issuer的值必须要和PartnerURI的值相匹配。
验证方式可以基于密码的验证方式和windows集成的验证方式。
urn:oasis:names:tc:SAML:1.0:am:password
urn:federation:authentication:windows
windows live ID只接受以下的名称标识符：
Format="http://schemas.xmlsoap.org/claims/UPN"
所有的验证令牌必须包含Email地址。
浏览器登录流程
请求IP/STS令牌（HTTP）（客户端向身份管理方的请求）
GET /adfs/ls/auth/integrated/clientlogon.aspx?wa=wsignin1.0&wtrealm=uri:WindowsLiveIDDevE&wctx=id=2000 HTTP/1.1
Windows live ID响应（HTTP）（windows Live ID响应给浏览器）
POST /login.srf HTTP/1.1
wa=wsignin1.0&wresult=<<the actual token data is here>>&wctx=id%3D2000
智能客户端登录
消息一：
IP/STS令牌请求
· <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wssc="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
· <s:Header>
· <wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
· <wsa:To s:mustUnderstand="1">HTTPS://wlid-adfs.wlid.extest.microsoft.com:443//wcfsts/service.svc</wsa:To>
· <wsa:MessageID>1170114540</wsa:MessageID>
· <ps:AuthInfo xmlns:ps="http://schemas.microsoft.com/Passport/SoapServices/PPCRL" Id="PPAuthInfo">
· <ps:HostingApp>{DF60E2DF-88AD-4526-AE21-83D130EF0F68}</ps:HostingApp>
· <ps:BinaryVersion>5</ps:BinaryVersion>
· <ps:UIVersion>1</ps:UIVersion>
· <ps:Cookies></ps:Cookies>
· <ps:RequestParams>AQAAAAIAAABsYwQAAAAxMDMz</ps:RequestParams>
· </ps:AuthInfo>
· <wsse:Security>
· <wsse:UsernameToken wsu:Id="IDCRLUNT1">
· <wsse:Username>user@contoso.com</wsse:Username>
· <wsse:Password>*********</wsse:Password>
· </wsse:UsernameToken>
· <wsu:Timestamp Id="Timestamp">
· <wsu:Created>2007-01-29T23:48:59Z</wsu:Created>
· <wsu:Expires>2007-01-29T23:53:59Z</wsu:Expires>
· </wsu:Timestamp>
· </wsse:Security>
· </s:Header>
· <s:Body>
· <wst:RequestSecurityToken Id="RST0">
· <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
· <wsp:AppliesTo>
· <wsa:EndpointReference>
· <wsa:Address>wlid-adfs.wlid.extest.microsoft.com:443//wcfsts/service.svc</wsa:Address>
· </wsa:EndpointReference>
· </wsp:AppliesTo>
· </wst:RequestSecurityToken>
· </s:Body>
· </s:Envelope>
联盟IP/STS 的响应（用户名密码验证成功）
· <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
· <s:Header>
· <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue</a:Action>
· <a:RelatesTo>1170114540</a:RelatesTo>
· <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
· <u:Timestamp u:Id="_0">
· <u:Created>2007-01-29T23:47:59.875Z</u:Created>
· <u:Expires>2007-01-29T23:52:59.875Z</u:Expires>
· </u:Timestamp>
· </o:Security>
· </s:Header>
· <s:Body>
· <wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
· <wst:TokenType>urn:oasis:names:tc:SAML:1.0</wst:TokenType>
·
· <wst:RequestedSecurityToken>
· <!-- SECURITY TOKEN IS HERE -->
· </wst:RequestedSecurityToken>
·
· <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
· <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
· <Address>wlid-adfs.wlid.extest.microsoft.com:443//wcfsts/service.svc</Address>
· </EndpointReference>
· </wsp:AppliesTo>
· <wst:RequestedAttachedReference>
· <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
· <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">saml-eb29eb6f-a66f-4919-b811-c8095bc5631b</o:KeyIdentifier>
· </o:SecurityTokenReference>
· </wst:RequestedAttachedReference>
· <wst:RequestedUnattachedReference>
· <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
· <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">saml-eb29eb6f-a66f-4919-b811-c8095bc5631b</o:KeyIdentifier>
· </o:SecurityTokenReference>
· </wst:RequestedUnattachedReference>
· <wst:RequestedProofToken>
· <t:BinarySecret u:Id="uuid-7fb11a70-266a-4491-9588-b3f105c5ae0c-5" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">cbGot0x8gP8Rp/r2c02O8ntkSDn7qxWR0JM0W7e78tQ=</t:BinarySecret>
· </wst:RequestedProofToken>
· <wst:Lifetime>
· <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-01-29T23:47:59.859Z</wsu:Created>
· <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-01-30T23:47:59.859Z</wsu:Expires>
· </wst:Lifetime>
· </wst:RequestSecurityTokenResponse>
· </s:Body>
· </s:Envelope>
联盟IP/STS 的响应（用户名密码验证失败）
· <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
· <s:Header>
· <a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>
· <a:RelatesTo>1170115199</a:RelatesTo>
· </s:Header>
· <s:Body>
· <s:Fault>
· <s:Code>
· <s:Value>s:Sender</s:Value>
· <s:Subcode>
· <s:Value xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:InvalidSecurityToken</s:Value>
· </s:Subcode>
· </s:Code>
· <s:Reason>
· <s:Text xml:lang="en-US">An error occurred when processing the security tokens in the message.</s:Text>
· </s:Reason>
· </s:Fault>
· </s:Body>
· </s:Envelope>
23万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
