SAML简介：安全地共享数字身份信息

简介

　　安全是所有Web项目在设计时都要考虑的一个重要因素。无论是选择最短口令，决定何时使用SSL加密HTTP会话，还是通过自动登录cookie来识别用户，都经常要付出重大的设计努力，以保护用户的身份信息和他们可能存放于Web站点的其他资料。糟糕的安全性可能带来公关灾难。当最终用户努力保持对其个人信息的控制时，他们要面临令人迷惑的隐私政策，需要牢记众多站点的不同口令，以及遭遇“钓鱼式攻击”事件。在宏观层次上，数字身份引起了许多复杂的技术和社会问题，业界一些团体如Liberty Alliance和IdentityGang都正试图通过开发新的技术标准来解决它们。 在较小的规模上，可以使用一些工具来为用户提供更好的安全性。请考虑口令管理问题。用户访问他们保存个人资料的Web站点，在可以存取他们的资料之前必须经过验证。通过验证来鉴别用户，确保他们是所声称的用户。进行验证最简单方式是使用口令。然而，若每个站点都需要各自的一套口令，用户将有难以控制的大量口令。1998年微软首先尝试通过其Passport network提供该问题的全球解决方案。Passport使得任意Web站点使用用户提交给Passport的个人资料（如用户名、地址、信用卡号）成为可能。Passport是单点登录（single sign-on，SSO）的第一次电子商务尝试。它没有流行起来，部分原因是由于人们对系统封闭性的担心。然而，SSO的理念非常引人注目，许多开放标准和商业计划都追随Passport其后。通过SSO，某个Web站点可以与其他站点共享用户身份信息。 SSO对于使用应用服务提供商（Application Service Provider，ASP）软件服务的企业特别有用。ASP在自己的服务器上宿主应用程序，出售其访问权作为服务。公司可以在它的标准目录服务器里管理自己的用户和口令，然后通过SSO授予用户访问ASP应用程序的权限。SSO允许公司管理自己用户的信息，不必为每一员工维护多个用户账号。对用户来说，SSO的好处在于他们可以在多个应用程序中使用一个用户名和口令，并且在应用程序之间切换时无需重新验证。SSO不仅仅用于Web应用程序，它可用于任何类型的应用程序，只要有安全地传送身份信息的协议。这种通信方式的开放标准就是安全性断言标记语言（SAML）。

关于SAML

　　SAML为SSO提供了一个安全的协议。SAML（读作“sam-ell”）是允许Web站点安全地共享身份信息的一个规范，它来自ebXML和其他XML标准背后的国际性联盟OASIS。站点使用SAML的XML词汇表和请求/应答模式，通过HTTP交换身份信息。这种信息共享标准化能帮助Web站点与多个合作伙伴集成，避免由于为不同合作伙伴设计和维护各自私有的集成通道而引起的争论。SAML1.0于2002年11月亮相。本文介绍最终于2003年完成的SAML1.1。虽然于2005年完成的SAML 2.0引入了支持身份联邦的一些重要新功能，但BEA WebLogic Server 9.x支持的是SAML1.1，因此本文将重点介绍SAML1.1。

一个基本的SAML示例

　　我们来看一个非常基本的SAML示例。顾名思义，SAML的核心元素是安全性断言。断言即无需证明的语句。安全性断言是关于用户身份的语句，只能通过接收断言发布者的站点信任获得支持。在SAML中，发布断言的站点叫“发布者”、“断言方”、或“源站点”。接收断言并信任它们的站点叫“信任方”或“目标站点”。

　　在本示例场景中，用户使用用户名和口令登录源站点。然后，用户希望无需再次验证即可访问目标站点。图1显示了源站点和目标站点之间能使用户通过单点登录访问双方站点的交互。

　　 图1：一个SAML示例场景

　　上面第4步中的SAML请求将通过HTTP作为从目标站点到源站点的SOAP消息发送。消息体将类似于：

<!-- This request would be wrapped in a SOAP envelope --> <samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion="1"MinorVersion="1"RequestID="_216.27.61.137.103896224111" IssueInstant="2005-03-19T17:04:21.022Z"> <samlp:AssertionArtifact> AAGZE1RNQJEFzYNCGAGPjWvtDIRSZ4 </samlp:AssertionArtifact> </samlp:Request>

　　该请求把自己标识为来自SAML请求-应答协议名称空间的SAML 1.1请求（MajorVersion和MinorVersion）。SAML为请求-应答协议元素定义了一个名称空间，为断言定义了另一个单独的名称空间。Request拥有基于请求者IP地址的惟一ID。请求的准确时间也包括在内。

　　该请求中最有趣的部分是<AssertionArtifact>标记中令人费解的字符串。目标站点从用户HTTP请求的查询字符串中得到该值。由于它用于标识浏览器，所以也叫“浏览器凭证”。注意，该请求没有要求提交特定用户的验证。该请求创建时，目标方并没有用于提交请求的用户名。该信息将在应答中得到。浏览器凭证告诉可能正在同时向目标站点发送很多用户的源站点，应该在此应答中发送哪个用户的断言。下面是一个应答示例：

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0protocol" ResponseID="huGxcDQc4cNdDyocphmi6CxEMngaÓ InResponseTo="_216.27.61.137.103896224111"? MajorVersion="1" MinorVersion="1" IssueInstant="2004-06-19T17:05:37.795Z"><samlp:Status> <samlp:StatusCode Value="samlp:Success" /> </samlp:Status> <saml:Assertionxmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa" Issuer="www.example.com" IssueInstant="2004-06-19T17:05:37.795Z"> <saml:Conditions NotBefore="2004-06-19T17:00:37.795Z" NotOnOrAfter="2004-06-19T17:10:37.795Z"/> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2004-06-19T17:05:17.706Z"> <saml:Subject> <saml:NameIdentifier>JSmith</saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact-01 </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response>

　　应答的关键部分是Assertion元素。断言使用了SAML Assertion名称空间定义的一个词汇表。它由一个验证语句组成，该语句告诉我们用户JSmith已通过口令验证。它还包含了支配目标站点断言使用的一系列条件。在本例中，这些条件指定一个10分钟的时间窗（time window），在时间窗之内断言有效。时间窗用来防止重放攻击。没有它，中途截取断言的恶意用户可以明天再次发送断言来冒充JSmith，并获得访问目标站点的权限。确认方法元素是指上面描述的浏览器凭证。

　　接受断言后，目标站点视为JSmith已直接通过其用户名和口令登录。注意，验证（鉴别用户身份）和授权（授予用户访问资源的权限）之间的分离在此是非常重要的。源站点负责验证JSmith，但不提供关于JSmith在目标站点特权的任何信息。这种安排对双方站点都有益处：源站点无需了解目标站点的资源或特权，目标站点也可忽略源站点管理用户和验证的细节。这种分离提供了非常重要的灵活性。

　　假设源站点是JSmith的老板MegaBank。JSmith使用他在MegaBank的账号访问他工作必需的三个不同外部宿主的应用程序。一天，MegaBank雇佣的安全顾问建议在JSmith所在部门启用指纹验证。如果没有SSO和SAML，MegaBank就必须到三个应用程序提供商那里请求他们支持指纹验证。应用程序提供商不得不权衡提供该支持的成本和不提供该支持可能丢失客户的风险。MegaBank可能必须等待提供商发布他们软件的新版本，所有的改动或许将昂贵又费时。通过SAML，MegaBank只需改变自己的验证过程，在JSmith和其同事登录时检查指纹即可。作为SAML目标站点的宿主应用程序无需清楚在MegaBank所做的更改，因为底层的SAML断言是保持不变的。

　　使用SAML对用户Web站点或Web服务的设计与实现有一些影响，但仅限于在处理Web窗口中的用户名和口令时，或在处理方法签名时。例如，下面的Web services API方法不能与SAML很好地协同工作：

public void makeSomeSystemChange(String username, String password, String[] params);

　　该方法假设用户能够提供用户名和口令。如果Web服务的宿主是SAML目标站点，就没有Web服务实现可以验证的口令。有少数方式可以改进或扩展这些接口，使其与SAML协同工作，这取决于所需的向后兼容性的水平。同样，如果在Web页包含了具有用户名和口令字段的表单，那么为经过SAML验证的用户禁用口令字段是非常重要的。