2003年初，OASIS小组批准了安全性断言标记语言（Security Assertion Markup Language，SAML）规范。由于来自25家公司的55名专家参与了该规范的制定，因此人们会认为SAML能做任何事情，并且能被很好地理解。但事实并非如此，软件开发社区存在着很多对SAML的误解。在本文中，Frank Cohen详细说明并澄清了有关SAML的很多不实说法和误解。

　　作为一个新生事物，新的安全性断言标记语言（SAML）规范正在被人们拿来与现有的单点登录技术、认证服务和目录服务进行比较。SAML是第一个可能成为多个认证协议的规范以利用Web基础结构（在这种Web基础结构中，XML数据在TCP/IP网络上通过HTTP协议传送）。

　　OASIS小组开发SAML的目的是作为一种基于XML的框架，用于交换安全性信息。SAML与其它安全性方法的最大区别在于它以有关多个主体的断言的形式来表述安全性。其它方法使用中央认证中心来发放证书，这些证书保证了网络中从一点到另一点的安全通信。利用SAML，网络中的任何点都可以断言它知道用户或数据块的身份。然后由接收应用程序作出决定，如果它信任该断言，则接受该用户或数据块。任何符合SAML的软件然后都可以断言对用户或数据的认证。对于即将出现的业务工作流Web服务标准（在该标准中，安全的数据需要流经几个系统才能完成对事务的处理）而言，这很重要。

　　尽管SAML刚刚被批准没多久，但是却有许多有关SAML的不实说法和误解要澄清。我认为，如果您真正了解了当今的某个新兴标准，那么它肯定已经过时了。

　　本文讨论了有关SAML的一些比较常见的不实说法和误解。

　　误解：SAML是一个完整的身份管理解决方案。

　　SAML作为身份管理解决方案中服务器之间的通信协议发挥了重要作用；但是，SAML并不是完整的解决方案。在信息系统安全性领域，近来出现的 身份管理是一个新术语，它涵盖了下面这些计算领域：

　　·准备（provisioning）—将新用户添加到企业内部信息系统和外部合作伙伴信息系统的网络操作系统目录和应用程序服务器目录中。
　　·密码管理—使用户能够用一组凭证登录到公司的信息系统。此外，使用户能够自己管理其密码、用户帐户数据和特权。
　　·访问控制—使系统能够识别用户组的安全性策略。例如，某项安全性策略防止某个人更改他或她的职位，但能将职位更改请求发送给具有相应权限的人。

　　SAML是两台服务器需要共享认证信息时使用的协议规范。SAML规范中没有任何内容提供了实际的认证服务，认证服务是由商业目录服务器提供的。

　　不实说法：企业之间的Web单点登录很好理解并且易于实现。

　　SAML是旨在减少构建和操作信息系统（这些系统在许多服务提供者之间相互操作）所花费成本的众多尝试之一。在当今竞争激烈且迅速发展的环境中，出现了通过浏览器和支持Web的应用程序为用户提供互操作性的企业联合。例如，旅游网站允许用户不必进行多次登录即可预订机票和租车。今天，一大群软件开发人员、QA技术人员和IT经理都需要处理复杂的和不可靠的后端系统，这些系统提供了企业之间的联合安全性。

　　在典型的支持Web的基础结构中，运行业界领先的企业系统的软件需要处理权限服务器之间的浏览器重定向、服务器域之间的HTTP post命令、公钥基础结构（public key infrastructure，PKI）加密和数字证书，以及声明任何给定用户或组的信任级别的相互同意（mutually agreed-upon）机制。SAML向软件开发人员展示了如何表示用户、标识所需传送的数据，并且定义了发送和接收权限数据的过程。

　　不实说法：SAML是一个复杂的设计。

　　SAML为那些需要在Web基础结构（XML/HTTP/TCP）上设计和构建可伸缩联合系统的系统架构设计师提供了一个蓝图。即使您决定不使用SAML，但SAML规范还是回答了许多设计问题，这些问题是任何系统架构设计师在构建可互操作的且支持Web的系统时必须回答的。

　　作为一个示例，请考虑用来将权限请求编码成XML请求的SAML断言机制。SAML定义了六类语句：

　　认证（Authentication）：主体已登录。例如，用于认证的SAML断言看起来可能象下面这样：

　　fcohen@pushtotest.com logged in at 2003-02-06T19:22:09Z
 
　　属性（Attribute）：标识主体的特性。例如，fcohen@pushtotest.com拥有Admin角色。

　　权限决定（Authorization decision）：声明允许某个主体对某个资源执行操作。例如，fcohen@pushtotest.com被授权GET http://www.pushtotest.com/ptt/kits/index.html。

　　断言属性（Assertion attribute）：一个可选机制，使行业团体能够定义特定于其行业的属性。

　　此外，SAML定义了由某个断言中的语句共享的断言的属性，包括：

　　版本属性（Version attribute）：标识了断言所遵循的SAML规范的主版本和次版本。

　　SAML还定义了可选的条件元素以限制权限请求的有效性。例如，如果SAML标记NotBefore或NotOnOrAfter指定的以UTC编码的日期，那么它可能是有效的。

　　最后，SAML定义了一个XML签名（XML Signature）元素以标识认证中心。该元素可以包含一个带有公钥、到期日和使用策略的X509证书。XML签名还包含签名值本身，签名值是由认证中心为元素内容生成的。可以使用X509证书中权威机构的公钥信息来验证签名。通常，SAML的复杂性在于部署基于SAML的软件，以及设置公钥基础结构（PKI）环境和数字证书。

　　误解：SAML为大多数行业预定义了所有属性含义。

　　SAML并未为任何行业定义属性含义。而是定义了一个名称空间机制，行业团体可以使用该名称空间机制来为其特定行业定义属性。例如，在航空行业中，SAML属性role:mechanic定义了飞机的机械师。系统两端的各方需要分别就SAML使用的名称空间达成一致。

　　SAML规范标识自己的名称空间来限定SAML属性和元素。例如，名称空间”urn:oasis:names:tc:SAML:1.0:action:ghpp”定义了SAML操作中使用的get/head/put/post http操作。如果该SAML名称空间的格式看起来有点古怪，那么这可能是因为SAML名称空间未遵循SOAP和XML-RPC中的传统XML名称空间格式：XML名称空间是URI；SAML使用URI的URN变体，而其它名称空间则使用URL变体。

　　不实说法：SAML是一个认证权威机构。

　　SAML是一个在服务器之间使用的认证协议。您仍然需要能帮助您实际登录的某些东西。SAML所能说的只是“您已经登录了（you have logged in）”。例如，当LDAP服务器对一个用户进行认证时，认证权威机构是LDAP服务器 — 即使LDAP服务器可能正在使用SAML来传送认证。

　　在完整的认证系统中，您仍需要编写策略决策点，以确定用户是否可以访问Web页面。此外，您还需要编写策略强制实施点（enforcement point）。这是一个接收权限、检查角色和权限，然后做出断言的servlet或应用程序。有几家公司提供了商业策略决策点和策略强制实施点解决方案，这些公司包括Oblix、Netegrity、IBM和许多其它公司。

　　误解：在认证需要传输大量数据的Web环境中，SAML不能很好地工作。

　　当权限请求对于HTTP重定向而言太长时，SAML定义了一种助诊文件（artifact）机制。SAML助诊文件的长度为42字节，它包含一个类型-代码 — 长度为20个字节的源标识，以及长度为20个字节的随机数，服务器用它来查找断言。源服务临时存储断言。目标站点接收断言，然后从源站点上的助诊文件直接抽出所需的数据。这允许两台不同的安全性服务器使用助诊文件。

　　不实说法：使用重播技术可以轻易地攻破SAML。

　　重播攻击是这样一类攻击：它可以拦截有效的消息，然后再将该消息重播回服务。重播攻击可用于造成数据完整性问题以及拒绝服务攻击。

　　SAML提供了避免重播攻击的保护。SAML要求在传输断言和消息时使用SSL加密，以专门防止断言被拦截。此外，SAML提供了数字签名机制，该机制使断言具有有效时间范围，以防止断言以后被重播。

　　最后，助诊文件概要具有其它两个重播对策：

　　·SAML源站点只将断言返回给接收助诊文件的请求者。
　　·SAML源站点在第一次使用助诊文件后会擦除其助诊文件到断言的映射，从而使得重播的助诊文件无效。

　　误解：SAML定义了发现过程以查找认证权威机构。

　　SAML未定义任何机制来查找接受SAML断言的目标站点。

　　SAML定义了一种用于认证的推（push）机制：用户登录到源站点，然后该站点向目标站点发送一个断言。该过程需要源站点和目标站点之间进行数字签名。在Web环境中，浏览器将表单公布（post）到目标站点，并且在一个隐藏的表单变量中包含一个用Base64编码的签名和断言。

　　将来的SAML规范有可能包含发现机制。

　　不实说法：SAML不能处理匿名或访客（guest）访问。

　　SAML没有用于提供匿名认证的功能。请考虑这样一种方案，其中某个网站允许您使用合作伙伴网站的功能，但是不允许合作伙伴站点知道您是谁。SAML未提供这样的功能。让SAML处理匿名或访客访问是可能的，但是这要求参与的企业就其自己的匿名访问或访客授权访问的约定达成一致。

　　不实说法：SAML要求在客户机端和服务器端都有SSL证书。

　　SAML构建在需要公钥基础结构（PKI）的基础之上，以提供数字签名和SAML断言的加密。所以，PKI具有的不便SAML全都有。

　　SAML是最先需要那种程度的细粒度安全性的协议中的一个；例如，XML密钥管理规范（XML Key Management Specification，XKMS）提供的安全性将用于认证SAML断言。同时，通过要求使用HTTP Basic的HTTP客户机端认证或SSL客户机端证书认证，SAML为SAML助诊文件提供了安全性。然后只将助诊文件发送给期望的请求者，在检索到助诊文件后则删除它。

　　误解：SAML是雾件（vaporware，指已宣布但还未实现）；还没有人要实现它。

　　许多商业和开放源码产品中已经提供了SAML，包括：

　　·IBM Tivoli Access Manager
　　·Oblix NetPoint
　　·SunONE Identity Server
　　·Baltimore, SelectAccess
　　·Entegrity Solutions AssureAccess
　　·Internet2 OpenSAML
　　·Netegrity SiteMinder
　　·Sigaba Secure Messaging Solutions
　　·RSA Security ClearTrust
　　·VeriSign Trust Integration Toolkit
　　·Entrust GetAccess 7

　　误解：Microsoft不支持SAML。

　　目前还不清楚Microsoft将如何支持SAML，但是Microsoft和OASIS小组正在进行大量工作，以使得SAML与Microsoft的倡议相协调。Microsoft的平台和服务（包括Microsoft .NET Passport）将如何与那些实现Liberty Alliance和OASIS WS-Security项目协议的服务相互操作，还需拭目以待。例如，与Passport的专有系统不同，Liberty Alliance认证规范使用SAML标记来交换认证标记。但是，这两种认证系统在将标记从一个站点传递到下一个站点的方式上有所不同。

　　Microsoft已公开承诺使WS-Security路线图工作和SAML项目合理化。他们似乎更侧重于以WS-Security作为更通用的Web服务安全性模型，该模型可以使用现有的IT投资以及新兴标准（如SAML和XrML）。Microsoft正在与OASIS WS-Security小组通力合作，以使用SAML断言作为WS-Security凭证。最近，OASIS WS-Security小组接受了SAML的WS-Security绑定。

　　尽管Microsoft对OASIS WS-Security小组无控制力，但Chris Kaler是该工作组的主席之一，同时也是Microsoft员工。我认为，如果Microsoft对于将SAML用于Passport和Liberty Alliance只想得到形式上的认可，那么Microsoft还不如向ECMA标准团体提供建议。

　　误解：XML签名中的规范化是不需要的。

　　这完全错了。

　　XML签名是一种规范，旨在满足将XML文档（包括SAML）与数字签名一起使用的特殊需求。W3C的XML签名工作组正在开发一种XML语法，以便于可以对几乎任何内容进行签名 —XML文档、SOAP消息头和XML元素，并且提供用于创建和验证数字签名的协议和过程。

　　XML签名中的规范化是允许在多个服务之间进行认证所必需的。例如，请考虑当您通过浏览器界面从制造商那里购买个人计算机时，服务器端所发生的情形。多个服务处理订单的不同部分：一个服务提供搜索功能以找到您希望订购的产品；下一个是开帐单服务，它获取您的支付信息；最后一个服务获取装运信息。这三个系统使用SAML断言共享您的记录。规范化确保了您记录中的字节顺序保持相同，即使三个不同系统正在操作该记录也是如此。如果没有规范化，那么该记录就可能会发生变化并使XML签名无效，因为XML签名的任务是确保其签名的内容是完好无损的，并且字节顺序是相同的。

　　结束语

　　由于许多致力于安全性的公司已经提供了上市的产品，因而SAML有一个良好的起点。SAML规范为在一组联合服务中设计支持Web的、单点登录的服务提供了良好的框架。SAML规范工作组的工作还在继续，以使得SAML和其它新兴标准（包括WS-Security）之间的互操作性需求合理化。

　　作者感谢Charles Knouse（Oblix的首席软件工程师）和软件开发论坛（Software Development Forum，www.sdforum.org）的Web服务特别兴趣组（Web Services Special Interest Group），感谢他们为研究本文所提供的帮助。

　　关于作者

　　Frank Cohen是一位“上门服务”人士，当企业需要测试和解决复杂的互操作信息系统（特别是Web服务）中的问题时，他可以上门服务。Frank是PushToTest（一家测试自动化解决方案公司）的创始人和几本有关测试信息系统的书籍的作者。Frank最近出版的新书Automating Web Tests with TestMaker现在可在http://www.pushtotest.com/ptt找到。可以通过fcohen@pushtotest.com与他联系。