注意：特此声明：本文首发在掘金：https://juejin.cn/post/7330680498686214180，未经允许，请勿进行侵权私自转载。
SAML协议简介
SAML（Security Assertion Markup Language）是由OASIS制定的基于XML的开放标准。它用于在身份提供者（IdP）和服务提供者（SP）之间交换身份验证和授权数据，从而支持跨域单点登录，提高身份认证和授权管理的安全性和效率。
SAML作用和效果
SAML在Web-based单点登录（SSO）中发挥着至关重要的作用。借助SAML，用户只需进行一次身份验证，即可访问多个不同的应用程序或服务，而无需重复输入凭证。这种集中化的身份验证和授权机制不仅提高了用户体验，还增强了安全性。现在，让我们进一步探讨SAML的工作原理。
为什么要使用SAML
首先，使用SAML可以显著提升用户体验。通过实现单点登录（SSO），用户只需进行一次身份验证，即可访问多个不同的系统服务。这意味着用户无需分别记忆多个系统的用户名和密码，只需记住一个即可。
其次，使用SAML还有助于提高系统的安全性。在SAML框架下，我们只需向身份提供者（IdP）提供用户名和密码进行身份验证，而无需将这些信息存储在每个资源服务器上。这样，认证信息的安全性得到了保障，因为它们仅在IdP中存储了一份。
最后，通过集中存储和管理用户的认证信息，SAML还有助于降低系统的复杂性。
SAML角色组成
在SAML协议中，有三个核心角色：主体（principal）、身份提供者（Identity Provider，简称IdP）和服务提供者（Service Provider，简称SP）。
- 主体（principal）通常代表人类用户/浏览器终端
- IdP主要负责进行身份认证，并将用户的认证信息和授权信息传递给SP。
- SP的主要职责是验证用户的认证信息，并授权用户访问指定的资源信息。
通过这样的角色划分和分工，SAML协议能够有效地支持跨域单点登录，提高身份认证和授权管理的安全性和效率。
SAML是怎么工作
通过一个详细的流程图来深入了解SAML如何实现SSO认证。请注意，根据请求方式的不同（重定向和POST），SAML的认证流程略有差异。
首先，我们来看看通过重定向方式进行的SAML SSO认证流程：
- 用户尝试访问受保护的资源（例如某个应用或服务）。
- 服务提供者（SP）识别出用户未经过身份验证，并重定向用户到身份提供者（IdP）进行身份验证。
- 用户在IdP的网站上输入用户名和密码进行身份验证。
- IdP验证用户信息，并将包含身份验证和授权信息的SAML响应发送回SP。
- SP验证SAML响应，并授予用户访问受保护资源的权限。
接下来，我们来看看通过POST方式进行的SAML SSO认证流程：
- 用户尝试访问受保护的资源。
- SP识别出用户未经过身份验证，并生成包含重定向URL的SAML请求的HTML表单。
- SP将HTML表单发送给用户，要求用户填写用户名和密码。
- 用户在表单中输入用户名和密码，并提交给IdP进行身份验证。
- IdP验证用户信息，并将包含身份验证和授权信息的SAML响应发送回SP。
- SP验证SAML响应，并授予用户访问受保护资源的权限。
通过以上两种方式，我们可以看到SAML通过在IdP和SP之间交换身份验证和授权信息，实现了SSO认证，从而简化了用户的登录过程，提高了系统的安全性。
核心协议详解
上面中用户可以理解为web浏览器，我们看一下如果用户想请求SP服务提供者的资源的时候，SAML协议是怎么处理的。
用户通过用户请求SP服务提供者，比如：
https://www.xx.xx.com，在SP接收到请求后，它会进行必要的安全检查。如果发现已经存在一个有效的安全上下文，SP直接进入最后一步，继续处理请求。在上一步中，如果SP没有找到有效的安全上下文，它会生成对应的SAML请求，并通过重定向用户代理（User Agent）将用户转至IdP，以确保用户能够通过身份验证并获得访问受保护资源的权限。
通过与IdP的交互，用户可以完成身份验证，并获得必要的授权信息，以便于之后访问受保护的资源。
302 Redirect Location: https://idp.xxxx.com/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=tokenRelayState标志
在SAML协议中，RelayState是一个重要的组成部分，主要用于防范CSRF攻击。RelayState是SP（服务提供者）维护的一个状态信息。简单来说，它就像是一个“凭证约定”，帮助SP追踪用户的请求，并确保请求是从合法的来源发送的。
跨站请求伪造（Cross-Site Request Forgery，简称CSRF） 是一种常见的网络攻击手段。攻击者诱导受害者在不知情的情况下执行恶意请求，通常是为了在受害者的身份下进行非法操作。
RelayState在防范CSRF攻击中的具体操作
- 请求的追踪：当用户从一个应用或服务（例如，SP）发送请求到另一个应用或服务（例如，IdP）进行身份验证时，SP会将一个特定的RelayState参数附加到请求中。这个RelayState参数包含了一个唯一的标识符或令牌，用于标识这个特定的请求。
- 验证返回的请求：当IdP完成身份验证后，它会将用户重定向回SP，并附带原始的RelayState参数。SP接收到请求后，会检查返回的RelayState参数是否与原始请求中的匹配。
- 如果匹配，说明请求是合法的；
- 如果不匹配，则很可能是CSRF攻击。
SAMLRequest请求体
在SAML协议中，元素是用于身份验证请求的XML元素，它包含了发起身份验证请求所需的必要信息，SAMLRequest是经过Base64编码的<samlp:AuthnRequest>，以下是一个samlp:AuthnRequest的示例：
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="id1234567890"
Version="2.0"
IssueInstant="2024-02-02T18:17:54Z"
Destination="https://sp.example.com/SAML2/SSO/POST"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
<saml:Issuer>https://idp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
AllowCreate="true"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
元素解释
<saml:Issuer>：标识发出请求的身份提供商（IdP）的实体ID。在这里，它是https://idp.example.com/SAML2。<samlp:NameIDPolicy>：定义了NameID策略，用于指定如何创建和管理NameID（用于标识用户的唯一名称）。在这里，Format属性指定了NameID的格式为“transient”，表示该NameID是临时的且仅在当前会话中有效。AllowCreate属性设置为“true”，表示允许创建新的NameID。<samlp:RequestedAuthnContext>：指定了所请求的身份验证上下文，用于定义所需的身份验证方法或条件。在这里，Comparison属性设置为“exact”，表示请求的身份验证上下文必须与提供的身份验证上下文完全匹配。<saml:AuthnContextClassRef>：元素指定了身份验证类别的引用，这里是“PasswordProtectedTransport”，表示使用受密码保护的传输来进行身份验证。
为了安全起见，SAMLRequest还可以使用SP提供的签名key来进行签名
用户重定向IDP数据信息
在接收到前一步的请求后，SP将RelayState和SAMLRequest进行整合，并通过HTTP 302重定向将用户（浏览器）引导至IdP的SSO服务器，请求的消息体如下：
GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.xxxx.com
IdP在接收到AuthnRequest请求后，会进行严格的安全验证。如果验证通过，IdP会展示其登录界面，允许用户进行身份验证。用户可以输入用户名密码进行登录。
登录成功之后
在完成安全验证后，IdP将返回一个XHTML表单，该表单内嵌了经过Base64编码的SAMLResponse信息。SAMLResponse中包含了用户的相关数据，且同样以samlp:Response的形式进行编码。
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2023-01-05T09:22:05Z"
Destination="https://sp.xxxx.com/SAML2/SSO/POST">
<saml:Issuer>https://idp.xxxx.com/SAML2</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2023-01-05T09:22:05Z">
<saml:Issuer>https://idp.flydean.com/SAML2</saml:Issuer>
<!-- a POSTed assertion MUST be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
InResponseTo="identifier_1"
Recipient="https://sp.xxxx.com/SAML2/SSO/POST"
NotOnOrAfter="2023-09-05T09:27:05Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2023-09-05T09:17:05Z"
NotOnOrAfter="2023-09-05T09:27:05Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.xxx.com/SAML2</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2023-09-05T09:22:00Z"
SessionIndex="identifier_3">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
我们观察到samlp:Response中包含saml:Assertion信息，并且针对于相关的交互流程进行梳理
- 当用户代理收到XHTML表单后，它会将该表单提交给SP。
- 在SP中，断言消费者服务会处理该请求，创建相应的安全上下文，并重新定向用户代理至目标资源页面。
- 随后，用户代理再次请求SP资源，由于安全上下文已经建立，SP可以直接返回所需资源，而无需再次与IdP进行认证。
注意，上述信息交换完全由前端浏览器完成，SP与IdP之间不存在直接通信。
如果为了提高安全性，也可以使用引用消息。也就是说IdP返回的不是直接的SAML assertion，而是一个SAML assertion的引用。SP收到这个引用之后，可以从后台再去查询真实的SAML assertion，从而提高了安全性。
