总结：单点登录SSO

一、SSO原理

单点登录（Single Sign-On，简称 SSO）是一种用户鉴权过程，允许用户在多个应用系统中使用单一的登录凭证（通常是用户名和密码）进行访问。它的基本原理是创建一种中央鉴权机制，用户登录一次后，无需在其他系统中再次进行身份验证即可访问这些系统的资源。以下是单点登录的核心原理和步骤：

1. 鉴权中心：SSO 解决方案通常设有一个中央鉴权服务器（也称为身份提供者，Identity Provider，IdP），它负责管理用户身份和凭证。

2. 服务提供者：连接到 SSO 的应用系统被称为服务提供者（Service Providers，SP）。用户希望通过 SSO 访问的每个应用程序都是服务提供者。

3. 首次登录和鉴权：当用户第一次尝试访问某个服务提供者应用程序时，如果没有经过身份验证，应用程序会将用户重定向到鉴权中心。

4. 认证和凭证：在鉴权中心，用户需要提供登录凭证（如用户名和密码）。如凭证正确，鉴权中心会创建一个登录会话，并生成一个令牌（Token）或票据（Ticket），这通常包含一个断言，表明用户已经被验证。

5. SSO Cookie 或会话：鉴权中心创建后的 SSO 会话可以通过设置浏览器的 Cookie 或其他会话管理机制来保持。当用户再次访问任何服务提供者时，这个 Cookie 或会话就可以用来证明用户的身份无需再次登录。

6. 断言和访问令牌：鉴权中心向用户浏览器提供一个包含用户身份断言的安全令牌，用户浏览器随后将该断言令牌提交给服务提供者。

7. 信任关系和令牌验证：服务提供者依靠事先建立的信任关系，验证来自鉴权中心的断言和令牌。验证成功后，根据断言提供的信息，SP 会给用户授予权限和访问资源的能力。

8. 后续访问：用户后续在访问其他 SP 应用时，由于已经有鉴权中心的会话，用户可以自动登录，连续流畅地访问其他系统，无需重复输入登录凭证。

单点登录的关键优势在于提升了用户的体验，因为用户只需要记住并使用一套登录凭证。此外，SSO 还可以提升安全性，因为用户凭证由一个中心系统统一管理，且用户交互次数减少了凭证被盗取的风险。然而，单点登录也增加了安全性的挑战，因为一旦鉴权中心被攻破，所有连接的系统都可能受到影响。因此，部署 SSO 解决方案时必须考虑到适当的安全措施。

二、SSO方案有哪些

方案一：OAuth 2.0 / OpenID Connect:

如果使用 OAuth 2.0 或 OpenID Connect（通常由身份供应商如 Auth0、Okta、Keycloak 等提供支持）：

1. 添加相应的依赖到你的 pom.xml 或 build.gradle 文件。
2. 配置安全性（安全上下文、认证管理器、用户详细信息服务等）。
3. 使用 @EnableOAuth2Sso 或 @EnableOAuth2Client 注解启用 OAuth2 SSO 支持。
4. 配置 application.properties 或 application.yml 文件，设置 SSO 服务器的详情、客户端ID、密钥等。

   spring:
     security:
       oauth2:
         client:
           registration:
             my-client:
               clientId: client-id
               clientSecret: client-secret
               clientName: Client Name
               clientAuthenticationMethod: basic
               authorizationGrantType: authorization_code
               redirectUri: "{baseUrl}/login/oauth2/code/{registrationId}"
               scope:
                 - openid
                 - profile
                 - email
               provider: oidc-provider
         provider:
           oidc-provider:
             authorizationUri: https://oidc-provider.com/auth
             tokenUri: https://oidc-provider.com/token
             userInfoUri: https://oidc-provider.com/userinfo
             userNameAttribute: sub

5. 实现一个自定义的 OAuth2UserService 或 UserDetailsService 来加载用户详情。

方案二：SAML 2.0:

对于使用 SAML 2.0 的 SSO：

1. 添加 Spring Security SAML 或类似的库（可能需要额外配置）。
2. 创建 SAML Security 配置类并配置 SAML 2.0 的提供者、服务提供者的实体ID等。
3. 配置传入和传出的请求的处理方式。
4. 设置用来加载用户信息的服务。

方案三：CAS (Central Authentication Service):

如果使用 CAS 作为 SSO 服务器：

1. 添加 Spring Security CAS 的依赖和其他必要的 CAS 客户端库。
2. 配置安全性，包括 ServiceAuthenticationDetailsSource 和 CasAuthenticationProvider。
3. 设置你的 Spring Security 配置，加入 CAS 针对的 Filter 和 EntryPoint。
4. 配置 application.properties 或 application.yml 以连接到 CAS 服务器。

对接 SSO 的具体步骤和细节根据具体的 SSO 解决方案和服务提供商而有所不同。通常，它需要基于 SSO 服务器的配置生成和交换认证令牌、设置安全配置和认证过滤器，并可能需要为应用程序用户创建本地账户、同步用户账户信息、管理用户会话等。此外，SSO 集成常常涉及到对组织内部的安全策略和用户管理流程有深入的理解。

在进行 SSO 集成时，你需要仔细阅读和遵循所选 SSO 解决方案的官方文档，确保所有步骤都能正确完成。

三、服务对接了SSO，是不是每次用户请求服务，服务都会先将请求转发到SSO？

不是。

服务对接了单点登录（SSO）机制后，用户的请求处理流程通常会有所改变，但并不是所有的请求都会直接转发到SSO服务器。具体的行为取决于服务的配置和SSO的实现方式。以下是几种可能的情况：

1. 初始认证：当用户首次请求访问受保护的服务时，如果用户还没有通过SSO认证，服务将需要将请求重定向到SSO服务器进行认证。

2. 认证票据：一旦用户在SSO服务器上成功认证，SSO服务器会生成一个票据（例如SAML断言或JWT令牌），并将其发送回用户。随后，用户带着这个票据再次请求服务。

3. 票据验证：服务接收到票据后，通常需要对接收到的票据进行验证，以确认票据的有效性和安全性。验证成功后，服务就知道用户已经通过SSO认证。

4. 会话管理：一旦用户通过初始认证，服务可能会创建一个本地会话或使用SSO提供的会话信息，以便跟踪用户的登录状态。

5. 后续请求：在用户通过认证后，对于后续的请求，服务通常不需要再次将请求转发到SSO服务器。相反，服务会检查本地会话或SSO提供的票据来验证用户的认证状态。

6. 票据刷新：如果票据有有效期限制，服务可能需要在票据过期前刷新票据，这通常涉及到与SSO服务器的额外通信，但不需要对每个请求都进行。

7. 被动SSO：某些实现可能采用被动SSO机制，其中用户的浏览器会在后台自动处理与SSO服务器的通信，用户甚至可能不会意识到他们的请求被转发到了SSO服务器。

8. 后端调用：即使用户已经通过SSO认证，服务在处理某些请求时可能仍需要与SSO服务器通信，比如当需要刷新票据、查询用户的额外属性或执行注销操作时。

总的来说，服务对接SSO后，并不是每次用户请求服务都会转发到SSO，而是在用户首次访问受保护资源或需要重新验证时与SSO服务器通信。其他时间，服务会利用本地会话或票据信息来处理请求。