简介
安全是所有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验证的用户禁用口令字段是非常重要的。
安全的SAML
由于SAML在两个拥有共享用户的站点间建立了信任关系，所以安全性是需考虑的一个非常重要的因素。SAML中的安全弱点可能危及用户在目标站点的个人信息。SAML依靠一批制定完善的安全标准，包括SSL和X.509，来保护SAML源站点和目标站点之间通信的安全。源站点和目标站点之间的所有通信都经过了加密。为确保参与SAML交互的双方站点都能验证对方的身份，还使用了证书。
BEA WebLogic Server中的SAML
BEA WebLogic Server 9.0是第一个包含了对SAML支持的WebLogic Server版本。WebLogic Server 9.1中进一步加强了对SAML的支持。WebLogic Server把SAML作为WebLogic Security Service的一部分使用。SAML用来为WebLogic Web services和跨WebLogic域共享验证信息提供SSO支持。除SAML外，WebLogic Server也为Windows桌面SSO支持Simple and Protected Negotiate (SPNEGO)协议。SAML可用来提供访问Web应用程序和Web service的权限。
对于一些应用程序，您仅需付出很少甚至无需付出额外的程序设计努力，就能使用WebLogic Server中的SAML支持。如果用户应用程序使用配置为WebLogic 安全域一部分的安全设置，那么集成SAML是一个首要的系统管理任务。WebLogic server可配置作为SAML源站点或SAML目标站点。要使服务器成为SAML源站点，需配置一个SAML Credential Mapper。要使服务器成为SAML目标站点，需配置一个SAML Identity Asserter.
如果用户应用程序安全模式为与WebLogic Security Service进行交互，包含了自己的特定于WebLogic的代码，可以使用WebLogic的SAML API把该定制扩展到SAML。该API提供对WebLogic SAML服务主要组件的编程式访问。用户可以使用应用程序自身的业务逻辑来扩展诸如SAMLCredentialNameMapper和SAMLIdentityAssertionNameMapper这样的类。一旦用户有了自己的定制类，WebLogic管理控制台就允许用户配置其SAML Credential Mapper（源站点）或SAML Identity Asserter（目标站点），以便使用那些类。惟一的要求是用户的定制类需要在系统类路径中，非常类似于WebLogic启动类，这可能对用户部署策略产生影响。
最后，如果应用程序安全模式完全独立于WebLogic Security Service，用户将不能从WebLogic的SAML工具中获益。用户要使其应用程序支持SAML就需要做更多工作，要么实现WebLogic所提供的某些服务的简化版本，要么集成那些服务的第三方版本。但是，用户仍将受益于可在任何J2EE应用服务器或在如Tomcat这样的Java Web服务器应用程序上使用SAML。有商业和开源的SAML支持可供选择。开源的选择中有OpenSAML和相关的Shibboleth项目。OpenSAML是一个SAML工具包，可用来建立用户自己的SAML源站点和目标站点。Shibboleth更进一步，它提供了一个构建在OpenSAML之上的“基于SAML 1.1的跨域Web单点登录平台”。SourceID为Java 和.NET中的SAML 1.1提供了一套开源工具包。在Apache项目下没有完整的SAML工具包，但WSS4J项目包含了对OpenSAML的一些支持。
结束语
SAML对企业应用程序开发越来越重要。随着大公司内部系统的不断扩展，合并身份信息对系统的成功管理来说非常关键。SAML也为依赖外部宿主应用程序的企业提供了巨大好处。对最终用户来说，单点登录能同时提供安全性和便利性。WebLogic Server 9.x的SAML支持是对WebLogic Security Service最重要的新补充之一。无论它是否为用户应用程序安全模式的一部分，用户都有许多选择以使其应用程序与SAML协同工作。