SAML2.0入门指南

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是该大学的一名学生。

image.png

现在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 tracer

希望以上的内容能帮助你理解SAML协议。SAML协议的内容十分复杂,但是涉及到单点登录的内容都是以上述内容为基础的。

更多关于SAML协议的是实现的内容,请参见本人编写的一系列教程文章来介绍如何使用OpenSAML,欢迎阅读指正:

  1. OpenSAML 使用引导 I : 简介
  2. OpenSAML 使用引导 II : Service Provider 的实现之AuthnRequest
  3. OpenSAML 使用引导 III: Service Provider 的实现之Artifact与断言
  4. OpenSAMl 使用引导IV: 安全特性

扩展阅读

  1. OAuth2.0 协议入门指南
  2. OpenID Connect 协议入门指南
上一篇:OpenID Connect 协议入门指南


下一篇:Android DataBinding 实战全解