[译文]SAML：不仅仅适用于web service

最新推荐文章于 2020-06-27 12:42:22 发布

mondayw

最新推荐文章于 2020-06-27 12:42:22 发布

阅读量1.3k

点赞数

分类专栏： SSO SAML 文章标签： service web weblogic manager access sso

SAML 同时被 2 个专栏收录

1 篇文章 0 订阅

订阅专栏

SSO

0 篇文章 0 订阅

订阅专栏

原文：SAML: It’s not just for web service

作者：Frank Teti

出处：http://www.theserverside.com/tt/articles/article.tss?l=SAML-NotJustforWebServices/

引言

SAML（Security Assertion Markup Language，安全断言标记语言）是一个基于XML的标准，用于在安全领域之间交换认证和授权数据。SAML是OASIS安全服务技术委员会（OASIS Security Services Technical Committee）的一个产品。创建SAML以便解决的唯一一个最重要的问题是Web浏览器的单点登录（Single Sign-On）问题，不过，就这一目的来说，SAML存在着一些局限性，事实上，通过把SAML作为WS-Security令牌（token）来使用，其更有效地解决了SOAP Web service的身份验证和授权这一问题。在一些有用的技术上会发现其有价值的方面并会找到一些满足广阔技术前景的事先未料到的方法，例如，Kerberos原来是命运多舛的DCE（Distributed Computing Environment，分布式计算环境）的组成部分，不过显然DCE已被废弃有很长一段时间，Kerberos则已经成为了Microsoft的核心安全组件。

SAML 2确实是包括了一些功能，这些功能解决了一些在使用Web浏览器时出现的多站点验证问题。目前，许多组织就是否照旧使用1.1版本还是迁移到2.0版本而正处在SAML的“犹豫不决地带”中。

最近在为一个涉及使用SAML作为SSO以保障门户应用和相关Web应用安全的项目做准备时，在与客户接洽之前，我做了通常会做的事情——向我个人的专家名单中的专家发送电子邮件并进行了基于SAML的搜索，之后有一件事情立刻变得显而易见，即关于这一主题缺乏实质性的文档。

调查结果、结论和建议

有多人曾推荐Vikrant Sawant在http://www.oracle.com/technology/pub/articles/dev2arch/2006/12/sso-with-saml.html上的这篇文章“在WebLogic Server 9.2中使用SAML配置单点登录（Configuring Single Sign-On using SAML in WebLogic Server 9.2）”，尽管这篇文章是有些过时，但其就这一有些晦涩难懂的技术领域来说仍然是开创性的贡献，我第一次读到它是在一年半之前，当时我正在实施一个在SOA环境内部使用SAML实现SSO的项目。

虽然可把本文当作是SAML的“hello world”实例介绍，不过基于以下原因，它并没有提供用于现实世界实现的指导：

Oracle WebLogic实例被当作IdP（Identity Provider，身份提供者）使用，而不是作为更加企业级的访问管理应用。

本地的LDAP实例既可用于IdP，也适用于相对于“虚拟用户”的服务提供者（Service Provider，SP）。

由此产生的SAML断言并不包括“Groups”属性，其需要提供RBAC（Role-based Access Control，基于角色的访问控制）；

问题检测不仅仅只包括源和目标服务器的日志分析，以及启用应用服务器调试和SQML信息过滤。

可信合作伙伴的密钥和证书配置不仅只是需要配置一个私钥。

在独立的环境而不是在有集群意识的、生产类的环境中配置安全模型。

本文的目的是提供一个视角以便深入了解，如何架构和实现作为企业范围内的平台的SAML安全。

一个企业级的IdP

使用Oracle WebLogic作为IdP显然是可行的，但是它不具备诸如Sun Access Manager、Tivoli Access Manager、Oracle Access Manager等一类的真实的访问管理环境所需的功能。使用Oracle WebLogic Server作为IdP并不提供会话管理功能，该功能类似于比如Sun Access Manager所提供的。由众多厂商支持的SAML则提供了一个超越了内联网SSO的解决方案。图1描述了一个供参考的系统结构，使用了

Sun Access Manager 7.1作为IdP，以及；

WebLogic Server 10.3作为SP。

图1：概念性的SAML架构——其中包括LDAP储存库

虽然许多IdP厂商既支持格式也支持协议，然而由于各厂商的实现不同，并且在实现中包括了他们自己的内部构造，因此配置SAML某些程度上变成了一种映射练习。因为Oracle收购了Sun，所以Sun Access Manager是否退役以有利于Oracle Access Manager，这还有待观察，Oracle Access Manager本身也是Oracle收购得来的，其之前被称为Oblix。虽然一些SAML感知的技术保证说，在Sun Access Manager内部用SAML实现IdP就类似于在WebLogic内部用SAML实现IdP，但可以这么说，配置并不像我所预期的那样对称。

图2：用于SAML的可信合作伙伴配置的Sun Access Manager 7.1控制台视图

Sun Access Manager Source ID属于不透明的数据类型SHA1，使用Base64编码的字符串“protocol://hostname:port（协议://主机名:端口）”来表示，这是SP站点的地址，尽管SP并不需要知晓这一ID。更具体一点来说，可信合作伙伴配置窗口捕捉了以下信息：

屏幕文字/参数	值
源ID（Source ID）	编码，唯一的可信合作伙伴的ID
目标（Target）	SP所在的主机名和端口
投递URL（Post URL）	断言消费者Servlet（Assertion Consumer Servlet），用作SP的WebLogic ITS（Inter-site Transfer Service，站点间传输服务）的组成部分，其还可以通过SSL来访问。
站点属性映射器（Site Attribute Mapper）	在IdP内部使用，格式化SP SAML断言命名空间的XML元素
名称标识映射器（Name Identity Mapper）	在IdP内部使用，格式化SP SAML断言名称标识符的XML元素
版本（Version）	SAML 1.1

IdP和SP用户储存库

在SAML身份验证模型中，IdP需要一个本地的储存库作为已验证身份的用户的“记录系统”，通常情况下，用户会被放置在本地的LDAP储存库中，相应地，在调用SP中的受保护资源时，SP可以使用同一个本地LDAP储存库来验证用户。然而，虽然这种模式可能适合于内联网应用，但对于跨网站、互联网应用和事实上并没有采用SAML SSO断言模型等情况来说这种做法都是不可行的。

另一种选择是，SP可以被配置成使用“虚拟用户”。图3展示了在WebLogic控制台中创建断言方（asserting party）以支持虚拟用户的窗口，这一可选的SP配置选项允许SAML身份断言器（SAML Identity Asserter）基于传入的断言实例化用户和组主体（Principal）。该配置还要求为安全领域配置一个SAML身份验证提供程序，这一配置使得用户能够登录为虚拟用户——该用户不对应于任何本地已知的用户。

图3：用于创建断言方的WebLogic Server 10.3控制台视图

具体来说，创建断言方窗口捕捉了以下信息：

屏幕文字/参数	值
发出者URI（Issuer URI）	SAML断言发出者的URI
签名要求（Signature Require）	如果证书已签名，这一可选属性可设置为true
处理组信息（Process Groups）	解析并存储SAML断言的组属性到SP的JAAS对象中
允许虚拟用户（Allow Virtual Users）	信任传入的所有认证和授权（组）信息断言的身份

指定SAML断言

JEE应用，其中包括门户，通常被设计和开发成可提供RBAC功能，这就要求应用连同应用服务器的配置一起进行组到角色的映射。在SAML断言模型内部，SP需要表明在受保护的应用中其是否会处理组的行为（见图3），以及用户是否需要成为IdP的本地（LDAP）储存库中的组成员。处理断言最终生成的“Groups”属性（见清单1）由SP的身份验证器映射到JAAS主体对象上。

清单1：与传入用户相关的SAML断言元素

<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">auser</NameIdentifier>

<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod>

</SubjectConfirmation>

</Subject>

<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配置描述被添加了进来，所以最终又是两个不同的配置描述。