SAML概要

概述

安全性断言标记语言（Secure Assertion Markup Language，简称SAML）把S2ML和AuthML规范结合在一起，是OASIS发布的一个复杂规范。顾名思义，SAML是一种标记安全断言的XML扩展，它提供了一种封装验证、授权等安全信息的形式，已经被用来解决SSO（单点登陆）和Web服务安全等重要问题。

SAML的版本

最初的SAML是由S2ML和AuthML两种规范结合形成的。2001年1月，OASIS成立了SSTC小组，并且在2002年11月推出了SAML 1.0规范。它的主要目标是解决SSO问题，以及分布式环境下验证/授权信息交换的问题。2003年9月，SSTC推出了SAML的1.1版本。1.1版本针对互动性和明确性方面做了改进，并加强了SAML与XML签名的联系。这个版本在XML签名相关的地方与1.1版本有略微的冲突。2005年3月，推出了SAML 2.0，作了较大的改动，在很多地方与SAML 1.x版本不兼容。本文主要针对SAML 1.1版本。

SAML的优点

n         平台无关性。SAML的设计屏蔽了任何平台架构的特殊性。

n         松耦合性。SAML不需要用户信息的同步更新等复杂的实现。

n         便捷性。终端用户只需登陆一次即可访问所有服务（即SSO）。

n         管理方便性。服务提供商对用户的管理将更加方便。

n         减少风险。服务提供商可以将验证的工作交给身份验证服务提供商。

SAML概念体系

n   Assertions（断言）：一个断言就由一个或多个声明（由SAML认证机构发布的安全信息集）组成。有三种声明。身份验证声明表示“这个主体已被验证通过”，并包括验证有效的时间，以及验证颁发的机构和方法。属性声明提供主体的特定信息（如会员的等级信息等）。授权决策声明指明主体有权利做什么（如用户是否允许购买A商品）。

n   Protocol（协议）：SAML定义了请求/响应协议，作为得到断言的途径。一个SAML请求可以要求得到一个已有的断言，也可以产生身份验证、属性和授权决策查询，以得到相应的断言。

n   Bindings（绑定）：准确说明SAML是怎样映射到传输和消息协议中的。例如，SOAP-Binding说明了SAML请求/响应是怎样在SOAP中表示的。

n   Profiles（配置文件）：Profile定义了SAML在某种具体应用时的技术细节。

下图是一个SOAP绑定的大致结构图。SAML请求或响应被封装在SOAP Body中。

下图为一个SAML Response封装在SOAP Body中的情况。注意：一个SAML Response可能有一个或多个SAML Assertion，一个SAML Assertion中可能有一个或多个声明。

下面来看一些相关的XML代码。

<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap/envelope/”>

<env:Body>

<samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"

xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"

MajorVersion="1"

MinorVersion="1"

RequestID="_192.168.16.51.1024506224022"

IssueInstant="2002-06-19T17:03:44.022Z">

<samlp:AssertionArtifact>

AAGZE1RNQJEFzYNCGAGPjWvtDIRSZ4

lWDqBphqAEYkgG/RBdHoeMsu1f

</samlp:AssertionArtifact>

</samlp:Request>

</env:Body>

</env:Envelope>

这是一个SAML请求。其中<Request>中为请求的内容。这里是一个通过“断言引用”（AssertionArtifact）请求相应断言的例子。

再看一个SOAP中嵌入SAML响应的例子。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

<env:Body>

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"

ResponseID="huGxcDQc4cNdDyocphmi6CxEMnga”

InResponseTo="_192.168.16.51.1024506224022"

MajorVersion="1"

MinorVersion="1"

IssueInstant="2002-06-19T17:05:37.795Z">

<samlp:Status>

<samlp:StatusCode Value="samlp:Success" />

</samlp:Status>

…… SAML ASSERTION AND STATEMENTS

</samlp:Response>

</env:Body>

</env:Envelope>

这里InResponseTo指明对应的是哪个Request，Status说明状态为success。

下面是一个断言的代码。

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"

MajorVersion="1"

MinorVersion="1"

AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"

Issuer="www.acompany.com"

IssueInstant="2002-06-19T17:05:37.795Z">

<saml:Conditions NotBefore="2002-06-19T17:00:37.795Z"

NotOnOrAfter="2002-06-19T17:10:37.795Z"/>

<saml:AuthenticationStatement

AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"

AuthenticationInstant="2002-06-19T17:05:17.706Z">

<saml:Subject>

<saml:NameIdentifier

NameQualifier=http://www.acompany.com

Format="http://www.customformat.com/">

uid=joe

</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>

主体为joe，在2002-06-19T17:05:17.706Z时通过口令方式通过了验证。

SAML：可移植的信任（SSO）

长期以来，人们认识到需要提供一种机制在不同的协作域之间传递关于实体的信息，同时域又不失去对这些信息的所有权，安全性断言标记语言或者 SAML 满足了这种要求。交换的信息可以是关于主体或者验证信息的断言。这种方式也称为单点登录。

这里提供一个很典型的例子：旅游预约。其中包括机票、旅馆和出租车的预定。您可能希望向某家航空公司、某个旅馆以及某个汽车出租商预订，但是不存在一种机制使您能够在三个独立的站点之间无缝移植——可能需要提交证明进行三次验证（假设这三家您都有帐号）。

SAML 可以解决这一问题，它允许只有少数经过选择的团体保留您的信息，并且如果需要，在得到您的明确批准之后这些团体可以与其他有关的团体共享这些信息。这意味着，您的信息安全的掌握在您所信任的团体手中，并且可以访问一些供应商通过组织多种低层次服务所提供的高级服务。

上图表示了两个域之间移植信任的框架。首先，A、B两个域之间是相互信任的。域A中的用户为了访问B中的服务，传递他与域B之间的信任关系，而域B与A中的用户并未有直接的信任关系，怎么办呢？用户在域A中是受信任的，而A、B相互信任，则可以用某种方式实现用户与B之间的信任关系。SAML就可以达到这个目的。

下面简要讲述SAML 1.1规范中提到的两种SSO profile。

Browser/Artfiact Profile：

又称“pull model”。

首先，用户在Asserting Party得到认证，并获得断言引用（一串Base64字符串，唯一标识一个断言）。然后用户发送这个引用给Relying Party，请求访问。之后，Asserting Party发送引用对应的断言给Relying Party，如黄箭头所示。Relying Party得到Browser的用户信息，并判断Browser访问的合法性。

这种Profile又有两种情况：Source-site-first和Destination-site-first。这里，Source site指的是认证机构，Destination site是资源所在地。

下面先看Source-site-first。

说明：第7步是Destination Site在收到引用（Artifact）后，为得到对应的断言，向Source Site发送请求。第8步则返回断言。

下面是Destination-site-first。

Browser/Artfiact Profile：

又称“push model”。

Browser先在Asserting Site得到认证，获得相应的断言。然后，Browser发送访问请求给Relying Site，并同时将之前得到的断言发送给Relying Site，从而对资源进行访问。

下面看以下它的流程：

这是一个Source-site-first的情况。与Browser/Artifact不同的是，第6步Source Site返回给Browser的是断言，而不是断言引用。

当然，也有Destination-site-first的情形，这里就不进行说明了。

以上这些，就是SAML用于SSO的大致内容。

SAML：Web Service Security

首先让我们来看一下WS-Security。很多刚刚接触 Web 服务的人都将 SOAP 看作是通过 HTTP 在两个端点之间交换消息的方法。通过 HTTP 可以验证调用方的身份、对消息签名以及对消息内容加密。这可以在以下几方面确保消息的安全性：调用方是已知的，消息接收方可以验证消息在传输过程中没有被更改，监视网络通信的实体无法识别出所交换的数据。但是如果准备采用 SOAP 消息传递来解决某些复杂问题，则仅仅基于 HTTP 的安全性是不够的。这些复杂问题通常涉及沿着比请求/响应更为复杂的路径发送消息，或者不使用 HTTP 进行传输。调用方以及消息的标识、完整性和安全性需要在多个跃点中保留。沿路由可能需要多个加密密钥。此外还要跨越信任域。HTTP 及其安全机制只面向点到点的安全性。而更复杂的解决方案则需要端到端的安全性。WS-Security 解决的是如何在多点消息路径中维护一个安全的环境。

WS-Security定义了一个解决SOAP安全问题的框架，主要是一个用于基于 XML 的安全性元数据容器的规范。它在SOAP Header中加入Security标签，封装安全认证信息。

SAML提供了一种实现WS-Security框架的有效途径。SAML-WS Profile（oasis-wss-saml-token-profile-1.0）定义了这种实现的相关细节。

参考

《Web服务安全技术与原理》 清华出版

OASIS标准文档，http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security