原文：SAML: It’s not just for web service
作者：Frank Teti
出处：http://www.theserverside.com/tt/articles/article.tss?l=SAML-NotJustforWebServices/
指定SAML断言
JEE应用，其中包括门户，通常被设计和开发成可提供RBAC功能，这就要求应用连同应用服务器的配置一起进行组到角色的映射。在SAML断言模型内部，SP需要表明在受保护的应用中其是否会处理组的行为（见图3），以及用户是否需要成为IdP的本地（LDAP）储存库中的组成员。处理断言最终生成的“Groups”属性（见清单1）由SP的身份验证器映射到JAAS主体对象上。
清单1：与传入用户相关的SAML断言元素
| <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">auser</NameIdentifier> <SubjectConfirmation> <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod> </SubjectConfirmation> </Subject> <Attribute AttributeName="Groups" AttributeNamespace="urn:bea:security:saml:groups"> <AttributeValue>atlantis</AttributeValue> </Attribute> |
图3中有一个标志用于指示SAML身份断言器（SAML Identity Asserter）在处理传入的断言时是否应该查找一个包含了组名称的SAML AttributeStatement，这就要求应用分别使用清单2和3中的Web.xml和相关的WebLogic.xml来启用RBAC。
清单2：SP的Web.xml
| security-constraint> <web-resource-collection> <web-resource-name>TheSecurePages</web-resource-name> <description>Pages accessible by authorized users.</description> <url-pattern>/working/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <description>Roles who have access.</description> <role-name> atlantis </role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>myrealm</realm-name> </login-config> <security-role> <description>These are the roles who have access.</description> <role-name> atlantis </role-name> </security-role> </web-app> |
清单3：SP的WebLogic.xml
| ... <security-role-assignment> <role-name> atlantis </role-name> <principal-name> atlantis </principal-name> </security-role-assignment> <context-root>TargetApplication</context-root> </weblogic-web-app> |
有效的IdP和SP错误解析
就中间件的错误检测和解析来说，在Oracle WebLogic或者任何应用服务器的内部，能够启用IdP和SP两者的SAML安全调试和/或直接“跟踪（tailing）”日志是一种标准的测试过程。在使用SAML作为Web应用浏览器的验证时，另一个可以用的工具是tcpmon，tcpmon是一个检测TCP连接上的数据流的开源实用程序，通过在客户端和服务器之间配置它来达到使用的目的。
如果使用Firefox进行单元测试的话，那么Live HTTP Headers就测试身份验证所需的SAML站点重定向这一目的来说，是一个很好的插件。在调试SP和IdP如何在身份认证期间重定向浏览器以及在HTTP协议层处理断言方面，Live HTTP Headers很有帮助。
建立合作伙伴的信任关系
密钥配置要求不仅仅只是如参考文章中表明的那样只配置私有密钥，这种处理方式只好用于开发模式，我们强烈建议，从一个有效的证书颁发机构那里获取适当的信任证书。
对于可信任合作伙伴的SAML整合来说，至少需要两个密钥：
SP站点上的断言消费者服务（Assertion Consumer Service）使用的私有密钥，以为IdP提供SSL客户端身份标识功能（见图1）。
公共密钥或者在来自于断言方的断言上有验证签名的可信任的证书，该证书必须是已在SAML身份断言器的证书注册表中登记了的，并且必须已是配置了Browser/POST方面的资料了的。
生产环境与独立环境的比较
要求SSO或者跨域整合的中间件应用通常需要一定程度的可伸展性或者是对中间件环境的容错复制，就中间件的SAML安全模型而言，这将要求除了模型要保持相对的完整以外，源和目标站点的URL还需要反应出负载均衡的虚拟地址。
影响：SAML 2.0功能
对于许多组织来说，迁移到SAML2.0的决定最有可能是基于新的功能是否有足够的吸引力以迫使软件组织：
升级访问管理应用；
重新设计SP配置，以及；
重建应用的逻辑。
SAML 2.0包括了一个单点注销协议（Single Logout Protocol），该协议支持Web SSO参与者会话的近乎同时的注销。对于SAML 1.1来说，这种“全体注销”功能必须要与IdP内在的Cookie管理行为结合在一起设计。例如，在验证并实现单点登录到多个服务提供商的服务之后，在身份提供者的要求下，用户能够自动退出所有这些服务提供商的服务。<AuthenticationStatement>元素已经被更名为<AuthnStatement>，<AuthnStatement>元素现在支持会话概念，以便能够支持单点注销和其他的会话管理需求。
SAML schema的扩展性机制已被更新，XSD元素的替代已被关闭以有利于类型的扩展，<xs:anyAttribute>通配符已被有选择性地添加到了被视为有价值添加任意属性的结构中，因而不必再创建一个schema的扩展，例如，主题的确认数据和SAML属性等方面的内容。
这是一个很有用的改进，因为现实世界中的实现有时会要求那些需要包含在断言中的瞬态的、在过程中产生的信息，例如，进来的用户的登录上下文等。举个例子来说，一个已验证身份的用户是有可能从多个位置中的一个验证并进入到应用中的，而应用则有可能会有兴趣知道这些信息。
本文基于Bowser/POST配置描述，SAML1.1中原来两个的web浏览器配置描述（Browser/Artifact和Browser/POST）已被合并成单个的web浏览器SSO配置描述（Web Browser SSO Profile），不过，一个增强的客户端和代理SSO配置描述被添加了进来，所以最终又是两个不同的配置描述。
建议使用SAML2.0代替SAML1.1不仅仅是保持与技术同步的问题，还在于SAML 2提供了一种完全分布式SSO经验；反之，SAML 1.1则存在着一些严重的缺点。最后要对顽固的技术使用者说的是，改变既不会是无危险的也不会是凶险异常的，它只是改变而已。
Frank Teti是Ironworks的一名架构师，曾任职Oracle/BEA Systems，参与SOA/BPM工作，他的联系方式：fteti@ironworks.com。
参考资料
SAML, JAAS, & Role-Based Access Control: Part 1 and 2， http://www.ddj.com/java/209100671。
4869
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
