该方法假设用户能够提供用户名和口令。如果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协同工作。