SAML认证

SAML（Security Assertion Markup Language）是一种基于XML的开放标准，用于实现身份提供者和服务提供者之间身份验证和授权数据的安全交换。
它实现了单点登录功能，用户只需一次认证即可访问多个应用程序，无需重复登录。

• 使用标准化的XML断言来安全地共享身份和访问信息。
• 它实现了通过身份提供者（IdP）进行集中式认证的功能。
• 通过支持跨应用程序的单点登录功能，可以消除多次登录的麻烦。

例如，当您登录到Google Workspace时，并访问像Salesforce这样的第三方应用程序时，SAML技术使得Google（IdP）与Salesforce（SP）之间的单点登录功能得以实现。SAML是一种能够确保这种无缝体验的框架，它让您的单次登录行为能够在不同的应用程序之间顺畅地发挥作用。

SAML中的核心组件

SAML的工作原理是，为参与认证过程的各方定义明确的角色。

1. 用户/主体：试图访问该服务的用户。
2. 身份提供者（IdP）：这是一种用于管理和验证用户身份的系统。它相当于用户的“真实身份来源”。例如：Google、Okta、Microsoft Azure AD、Auth0等。
3. 服务提供商：用户想要访问的应用程序或服务。SP信任IdP来处理身份验证工作。例如：Salesforce、Slack、Gmail等。

SAML认证流程

最常见的SAML工作流程是由服务提供方发起的。以下是具体的操作步骤：

SAML认证

1. 用户访问服务的情况：用户导航至服务提供商处（例如：gmail.com).
2. SP Crafts的SAML请求：SP发现用户并未登录。于是，它生成了一个基于XML的SAML认证请求。
3. 浏览器重定向到身份提供者：SP会将用户的浏览器重定向到身份提供者处（例如：accounts.google.com此外，还会将SAML请求与重定向信息一起发送出去。
4. IdP对用户进行身份验证：IdP会接收该请求，并提示用户使用其凭据（如用户名、密码、多因素认证等）进行登录。如果用户已经与IdP建立了有效的会话，则可以跳过这一步骤。
5. IdP生成SAML响应：在认证成功之后，IdP会创建一个……SAML响应这是一份包含数字签名的XML文档。断言/声明它作为用户身份以及相关属性的证明，比如用户的电子邮件地址或角色等信息。
6. 浏览器向SP发送响应。IdP将编码后的SAML响应发送回用户的浏览器。之后，浏览器会自动将该响应转发给服务提供商。断言消费者服务（Assertion Consumer Service，简称ACS）URL。
7. SP进行验证并登录：SP接收到了SAML响应。它使用IdP预先配置好的公钥来验证断言中的数字签名。如果签名是有效的，那么SP就会信任该信息，并为用户创建本地会话，从而允许用户访问相关资源。

SAML请求的关键要素

SAML请求中包含一些重要的数据，例如：

• ID：这是用于匹配SAML认证请求的唯一标识符，其作用是将请求与相应的响应进行关联。
• 发行方：发起请求的服务提供商的名称。
• 名称ID：用户的标识符，通常是他们的电子邮件地址或电话号码。
• AssertionConsumerServiceURL：这是服务提供商上的终结点URL，IdP会将认证响应发送到这里。

这些元素共同作用，以确保正确的用户能够被认证，并有权访问相应的资源。

SAML响应结构

SAML响应主要分为两部分：

• 断言/声明：这是一份XML文档，其中包含了用户的详细信息，例如登录事件的时间戳，以及所使用的认证方式（例如：双因素认证或Kerberos）。
• 签名：“Signature”实际上是一个Base64编码的字符串，它能够确保相关信息的完整性。如果攻击者试图修改SAML响应内容，比如将用户名更改为与受害者相同的名称，那么该签名机制就能防止这种修改被成功实施而不会被发现。

SAML认证中的密钥生成

在签署和验证SAML响应过程中，需要生成密钥。

• 私钥：身份提供者（IdP）会生成一把私钥，该私钥用于签署SAML声明。
• 公钥：服务提供商接收 IdP 的公钥，该公钥用于在授予访问权限之前验证 SAML 响应的真实性。

这样就能确保只有经过验证且已签署的有效响应才会被接受，从而进一步增强了系统的安全性。

确保SAML的安全性：漏洞与最佳实践

虽然 SAML 是一种成熟且安全的协议，但配置错误仍可能导致漏洞的出现。

签名验证不正确：

• 脆弱性：SP可能根本不会检查数字签名，或者只有在数字签名存在的情况下才会进行验证。这样一来，攻击者就可以修改该数字签名了。姓名/身份在捕获到的SAML响应中，移除那些已经无效的签名，然后以另一个用户的身份进行身份验证。
• 最佳实践：始终要求并验证签名的有效性。SP必须配置为拒绝任何未签名或签名与IdP的公钥不匹配的SAML断言。

SAML重放攻击：

• 脆弱性：攻击者可以截获有效的SAML响应，然后重新发送该响应，从而获得未经授权的访问权限。
• 最佳实践：SP必须严格执行相关规定。条件/状况关于这一断言，尤其是……不在或之后时间戳，以确保那些已经过期的断言会被拒绝。

XML注释注入：

• 脆弱性：一些实现不佳的XML解析器可能会被注释所欺骗。例如，攻击者可以尝试用某种方式来伪装自己，从而成功登录系统。姓名/身份 of user@victim.com绕过控制系统，并以已登录的身份进行操作。user@victim.com.
• 最佳实践：使用最新、安全的XML解析库，这些库能够正确处理注释以及其他复杂的XML结构。

SAML与OAuth/OIDC的比较

SAML常常与其他现代协议如OAuth和OpenID Connect（OIDC）混淆。它们各自有着不同的主要用途。

SAMLSAML是一种认证协议，用于验证用户的身份，从而实现多个Web应用程序之间的单点登录功能。

• 主要用途：身份验证（用户是谁？）
• 数据格式：基于XML的断言格式。
• 典型的应用场景：适用于企业内部或SaaS应用程序的企业级单点登录方案。
• 流式模式：基于浏览器的重定向方式。
• 常见的应用场景：企业级IT系统、传统企业系统。

例如：
员工只需一次登录，就可以访问公司的身份提供者（IdP），从而无需再次登录即可使用Salesforce、Jira和Workday等应用程序。

OAuth 2.0：OAuth 2.0是一种授权框架，而非认证协议。它允许应用程序在无需知道用户密码的情况下访问用户的资源。

• 主要用途：授权功能（该应用程序可以访问哪些信息？）
• 数据格式：JSON格式的令牌（访问令牌）。
• 典型的应用场景：API访问委托。
• 流式风格：基于令牌的流式处理方式。
• 常见的应用场景包括：API接口、移动应用程序，以及第三方集成。

OAuth流程：

• 用户试图访问应用程序中需要权限才能使用的功能。
• 该应用程序会将用户重定向到授权服务器，请求获取特定的权限（即“scope”）。
• 用户登录后，会批准所请求的权限。
• 授权服务器会使用临时授权码将用户重新引导回应用程序中。
• 该应用程序会将此代码与授权服务器进行交换，以获取访问令牌。
• 该应用程序使用访问令牌来安全地从资源服务器中获取用户的数据。