公司单点登录系统方案
接入系统
- 协同平台
- 营销与客户协同平台
- 云学堂
- oa ？
- 帆软 ？
- hr ？
- wms ？
- erp ？
每个员工都有一个工号 公司现在有很多网站应用（很多不在一个域名）和桌面应用，这些应用都维护着自己的用户系统（都记录着工号），
我现在想有一个单点登录系统，里面可以配置公司所有的应用，然后在这个单点登录系统里面录入公司所有的员工信息， 员工登录这个系统 点击后可ticket跳转到对应应用，对应应用用ticket向单点登录系统验证ticket获取凭证 在用凭证获取工号 建立自己的会话 员工也可以直接登录各个应用 用各个应用自己的账号和密码进行登录 并且在各个应用登录界面也可有一个按钮用单点登录系统登录
核心概念解释
单点登录系统 (SSO IdP - Identity Provider): 这是你方案的核心。它：
- 存储所有员工的主用户信息（包括工号、姓名、邮箱等核心身份信息，当然也包括用户名和密码）。
- 负责统一认证用户（员工）。
- 生成和验证安全令牌（Ticket）。
- 提供用户信息查询接口（验证Ticket后返回凭证/用户信息，包含工号）。
- 提供一个门户页面，展示用户有权访问的所有应用列表。
应用系统 (SP - Service Provider): 指公司的各个网站应用和桌面应用。它们：
- 有自己的用户系统（存储用户名、密码、工号等信息）。
- 需要集成SSO系统。
- 能够接收并验证来自SSO系统的Ticket。
- 能够调用SSO系统的接口获取用户信息（主要是工号）。
- 维护自己的会话。
Ticket: 一个一次性的、加密的、有时效性的令牌。由SSO系统在用户成功登录后生成，用于在SSO系统和应用系统之间安全地传递用户的认证状态。
凭证: 通常指SSO系统在验证Ticket后返回给应用系统的信息。这可以是一个简单的工号，也可以是一个更丰富的身份令牌（如JWT），里面包含了工号和其他必要信息（如用户名、邮箱、部门等）。
方案流程分析
场景一：通过SSO门户登录应用（IdP-initiated Flow）
- 员工登录SSO系统： 员工访问SSO门户，输入SSO系统的用户名和密码进行登录。
- SSO认证成功： SSO系统验证凭证，建立SSO会话。
- 展示应用门户： SSO门户显示该员工有权访问的所有应用图标。
- 点击应用： 员工点击目标应用的图标。
- 生成Ticket & 重定向： SSO系统为该员工和目标应用生成一个唯一的Ticket。然后，SSO系统将用户浏览器重定向到目标应用的特定URL（通常是
/sso/login或类似端点），并将Ticket作为URL参数附加（例如：https://app.company.com/sso/login?ticket=ABCDEFG123456）。 - 应用接收Ticket： 目标应用收到请求，提取URL中的Ticket。
- 应用验证Ticket： 应用系统（作为Service Provider）通过安全的、后端到后端的通道（HTTPS API调用）将收到的Ticket发送给SSO系统的Ticket验证接口。
- SSO验证Ticket： SSO系统验证Ticket的有效性（是否存在、是否过期、是否被使用过、是否针对该应用签发）。
- SSO返回凭证/用户信息： 如果Ticket有效，SSO系统通过上述API调用的响应，返回一个安全的凭证（包含用户的工号，以及可能需要的其他信息）。
- 应用处理凭证：
- 应用系统提取凭证中的工号。
- 应用系统在自己的用户数据库中查找与该工号关联的本地用户账号。
- 建立本地会话： 应用系统为该本地用户账号创建自己的会话（Session）。
- 重定向到应用主页： 应用系统将用户浏览器重定向到其登录后的主页面或用户最初请求的页面。
- 用户使用应用： 用户现在通过应用的本地会话访问该应用。
场景二：直接在应用登录界面使用SSO登录（SP-initiated Flow）
- 访问应用登录页： 员工直接访问某个应用的登录页面。
- 点击“SSO登录”按钮： 在应用登录页面上有一个显眼的按钮（如“使用公司账号登录”）。
- 重定向到SSO登录页： 点击该按钮后，应用系统将用户浏览器重定向到SSO系统的登录URL，并在URL中携带一个参数（通常是
RelayState或target），指明用户最初想访问的是哪个应用（例如：https://sso.company.com/login?service=https://app.company.com/sso/callback）。 - 员工登录SSO系统： 用户在SSO登录页面输入SSO用户名和密码（如果尚未登录SSO）。
- SSO认证成功 & 生成Ticket： SSO验证凭证成功后，为该员工和目标应用生成一个Ticket。
- 重定向回应用（带Ticket）： SSO系统将用户浏览器重定向回应用系统指定的回调URL（上一步中
service参数指定的URL），并将Ticket附加在URL上（例如：https://app.company.com/sso/callback?ticket=ABCDEFG123456）。 - 应用接收并验证Ticket（同场景一 步骤6-10）： 应用系统接收Ticket，通过后端API发送给SSO验证，获取凭证（含工号），查找本地用户，建立本地会话，重定向到应用主页。
场景三：直接使用应用本地账号密码登录
- 访问应用登录页： 员工直接访问应用的登录页面。
- 输入本地凭证： 员工输入该应用本地维护的用户名和密码。
- 应用本地认证： 应用系统使用自己的用户数据库验证用户名和密码。
- 建立本地会话： 验证成功，应用系统为该用户建立自己的本地会话。
- 用户使用应用： 用户正常使用该应用。这个过程完全不经过SSO系统。
关键点与优势分析
- 工号是核心连接点： 你方案的精妙之处在于利用工号作为SSO系统与应用系统之间的唯一关联标识。SSO提供工号，应用系统根据工号找到自己的本地用户记录。这解耦了认证（SSO负责）和授权/本地用户管理（应用负责）。
- 混合认证模式： 同时支持SSO登录和本地登录，提供了灵活性。员工可以选择最方便的方式，老旧或特殊应用可以继续使用本地登录。
- SSO门户集中访问： 提供一个统一的入口点，方便用户发现和访问所有授权应用。
- 标准化流程： 该方案遵循了标准的基于Ticket/Cookie的Web SSO流程（类似于CAS协议的核心思想）。
- 安全性：
- Ticket是一次性、有时效性的，降低了被截获重放的风险。
- Ticket验证是后端API调用，不暴露在浏览器历史记录中。
- 应用与SSO之间的通信应使用HTTPS。
- 凭证传递也应加密或有签名验证（如使用JWT）。
- 用户便利性： 只需记住一套主凭据（SSO账号密码），即可访问大部分集成的应用。
需要考虑的挑战与细节
- 应用集成改造： 这是最大的工作量。每个需要支持SSO的应用都必须进行开发：
- 添加“SSO登录”按钮和对应的重定向逻辑。
- 实现接收Ticket、调用SSO验证API、解析凭证、根据工号查找本地用户、建立本地会话的接口/端点。
- 可能需要修改本地登录逻辑以兼容两种登录方式。
- SSO系统开发/选型：
- 你需要实现或选择一个成熟的SSO解决方案（如Keycloak, Okta, Ping Identity, Azure AD, 或者基于CAS协议实现的系统）。
- 系统需要提供：用户管理、认证、Ticket生成/验证、用户信息查询API、应用配置管理（注册每个应用，配置回调URL等）、门户页面。
- 用户信息同步 (可选但推荐)：
- 虽然应用本地存储用户信息，但为了确保工号等核心信息一致，建议建立用户信息同步机制（如LDAP/AD同步、SCIM、或定期批处理同步），从SSO系统（作为主数据源）将核心用户信息（工号、姓名、邮箱、状态等）同步到各个应用。这样应用本地用户记录的工号就能和SSO提供的工号正确匹配。
- 凭证设计：
- 最简单的凭证就是工号字符串（但需确保传输安全）。
- 更安全的做法是使用签名的JWT令牌作为凭证，其中包含工号、签发者、有效期等信息，应用系统可以验证签名确保来源可信且未被篡改。
- 错误处理：
- 处理Ticket无效、过期、重复使用的情况。
- 处理应用系统中根据工号找不到对应本地用户的情况（用户不存在或同步问题）。需要清晰的错误页面或重定向机制。
- 会话管理：
- SSO会话与应用本地会话是独立的。SSO会话超时不影响已登录的应用会话（除非应用特别设计）。
- 在SSO门户提供“全局登出”功能（可选但复杂），需要通知所有已登录的应用系统注销用户的本地会话。
- 协议选择： 虽然你描述的是类似CAS的流程，实际实现时也可以考虑使用SAML或OpenID Connect (OIDC)协议。它们更标准化、功能更丰富（如属性传递、单点登出），但集成复杂度可能略高。你的方案本质上是OIDC的简化流程（Authorization Code Flow，用Ticket代替了Authorization Code）。
结论
你的方案完全可行且合理，是企业实施SSO的一种常见且有效的模式。它清晰地划分了职责（SSO负责统一认证和核心身份信息，应用负责本地用户管理和授权），同时兼顾了SSO的便利性和本地登录的灵活性（混合认证）。核心在于利用工号作为身份链接的桥梁。
成功实施的关键在于：
- 选择或构建一个健壮、安全的SSO系统。
- 规划和执行好各个应用系统的集成改造工作。
- 设计好用户信息（尤其是工号）的同步机制，确保一致性。
- 设计安全的Ticket和凭证传递机制。
这个方案能够显著提升员工访问多个内部应用的体验和效率，同时也能加强公司整体身份认证的安全性。