SAML，全称为Security Assertion Markup Language，是一种用于安全性断言的标记预压，目前的最新版本是2.0。原文地址
本系列相关文章：
OAuth2.0 协议入门指南
OpenID Connect 协议入门指南
OpenSAML示例
SAML在单点登录中大有用处：在SAML协议中，一旦用户身份被主网站（身份鉴别服务器，Identity Provider，IDP）认证过后，该用户再去访问其他在主站注册过的应用（服务提供者，Service Providers，SP）时，都可以直接登录，而不用再输入身份和口令。
SAML本身是一个很复杂的协议，这里只选取最重要的部分为大家讲解，更多细节请见官方文档，后续的文章也会进一步解析。
SAML协议的核心是: IDP和SP通过用户的浏览器的重定向访问来实现交换数据。
SP向IDP发出SAML身份认证请求消息，来请求IDP鉴别用户身份；IDP向用户索要用户名和口令，并验证其是否正确，如果验证无误，则向SP返回SAML身份认证应答，表示该用户已经登录成功了，此外应答中里还包括一些额外的信息，来却确保应答被篡改和伪造。
下面我们以用户登录SP，SP向IDP发起请求来确认用户身份为例子，看看SAML的工作流程。比如SP是Google的Apps，IDP是一所大学的身份服务器，Alice是该大学的一名学生。
现在Alice要通过浏览器查阅她的邮件，Alice一般会通过浏览器访问一个网页，比如https://mail.google.com/a/my-university.nl (step1)。因为这是个联合身份域，所以Google不会向用户索要用户名和密码，而是将其从定向到IDP来认证其身份（step3）。用户被重定向的URL类似于这种：
https://idp.uni.nl/sso?
SAMLRequest=fVLLTuswEN0j8Q…c%3D
嵌入到HTTP请求中的SAMLRequest就是SAML认证请求消息。因为SAML是基于XML的（通常比较长），完整认证请求消息要经过压缩（为Url节省空间）和编码（防止特殊字符）才能传输。在压缩和编码之前，SAML消息有如下格式：
<AuthnRequest ID="kfcn...lfki"
Version="2.0"
IssueInstant="2013-02-05T08:28:50Z"
ProtocolBinding="urn:oasis:names:tc:SAML: 2.0:bindings:HTTP-POST"
ProviderName="google.com"
AssertionConsumerServiceURL="https://www.google.com/a/uni.nl/acs">
<Issuer>google.com</Issuer>
<NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>;
</AuthnRequest>;
上面的内容用最直白的方式解释出来就是：这个来自Google的请求，请验证当前用户的身份，并将结果返回。
当IDP收到消息并确认要接受认证请求之后，就会要求Alice输入用户名和口令来验证其身份(如果Alice已经登录过了，就会跳过该步骤)；当验证通过之后，Alice的浏览器将会跳转回Google的特定页面（AssertionConsumerService，简称ACS，step6）。同样，SAML身份认证响应的内容也是在压缩并编码后以参数的形式传输。在压缩和编码之前，其结构类如下：
<Response Version="2.0"
IssueInstant="2013-02-05T08:29:00Z"
Destination="https://www.google.com/a/my.uni.nl/acs" InResponseTo="kfcn...lfki">
<Issuer>https://idp.uni.nl/</Issuer>
<Status>
<StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</Status>
<Assertion Version="2.0"
IssueInstant="2013-02-05T08:29:00Z">
<Issuer>https://idp.uni.nl/</Issuer>
<Subject>
<NameID>alice</NameID>
<SubjectConfirmation ...>
<SubjectConfirmationData
NotOnOrAfter="2013-02-05T08:34:00Z"
Recipient="https://www.google.com/a/my.uni.nl/acs" InResponseTo="kfcn...lfki"/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2013-02-05T08:28:30Z" NotOnOrAfter="2013-02-05T08:34:00Z">
</Conditions>
<AuthnStatement
AuthnInstant="2013-02-05T08:29:00Z"
SessionNotOnOrAfter="2013-02-05T16:29:00Z>
</AuthnStatement>
</Assertion>
</Response>
虽然内容很多，但是其主要表达的是：该消息来自idp.uni.nl，名为Alice用户的身份已经被我验证，该消息的有效期为2分钟。此外，重定向的URL中还要有该消息的签名以保证其不备篡改，验证签名的公钥和算法，都是IDP和SP提前协商好的。
当Google接受到SAML认证响应之后，会首先验证消息的签名是否正确（step7）以及是否因超时而失效。然后再从认证消息中提取出Google能识别用户身份（NameID，即Alice），如果以上的步骤都是顺利的，用户将会成功登陆Google（Step8）。
为了便于解释，以上例子中的信息都保持了可读性，如果想要去看看真实的SAML信息，建议推荐使用火狐浏览器的插件工具 SAML tracer。该插件将会在浏览器中添加一个窗口来显示SAML消息，以下是截图：
希望以上的内容能帮助你理解SAML协议。SAML协议的内容十分复杂，但是涉及到单点登录的内容都是以上述内容为基础的。
更多关于SAML协议的是实现的内容，请参见本人编写的一系列教程文章来介绍如何使用OpenSAML，欢迎阅读指正：
