欢迎光临
我们一直在努力

ASP 单点登录实战:用 CAS 协议打通多个系统的统一身份认证

ASP 单点登录实战:用 CAS 协议打通多个系统的统一身份认证

摘要:一个集团里往往跑着十几个甚至几十个业务系统——OA、HR、CRM、报表、图书管理……每个都要单独登录,账号密码散落各处。本文从架构视角拆解单点登录(SSO)的核心模型,并以 CAS 协议为例,给出 ASP/ASP.NET 应用的集成方案与令牌安全要点,帮助你在不动业务代码的前提下,把"处处登录"变成"一次登录、处处通行"。


一、为什么需要单点登录?

在绝大多数企业里,身份体系是"碎片化"的:

  • 密码疲劳:员工每天要在五六个系统重复输入账号密码。
  • 账号散落:每个系统一套账户,离职员工残留账号难清理。
  • 安全风险:弱密码、重复密码在各系统间横向移动。
  • 合规压力:等保 2.0 对"身份鉴别"与"访问控制"有明确审计要求,分散身份无法统一留痕。
  • 单点登录(Single Sign-On,SSO)的目标,是把所有系统的身份认证收拢到一个统一的认证服务器(IdP),应用系统(SP)只信任它签发的令牌,不再各自管理密码。


    二、SSO 的核心模型

    ┌──────────────────────────────────────────────────────┐
    │ 用户(浏览器) │
    └───────────────┬───────────────────────┬──────────────┘
    │ ① 访问业务系统 │ ② 统一登录
    ▼ ▼
    ┌──────────────────────────┐ ┌──────────────────────────┐
    │ 业务系统 A(ASP 应用) │ │ CAS 统一认证服务器(IdP) │
    │ 信任令牌,不存密码 │ │ 签发 TGC / 服务票据 ST │
    └──────────────────────────┘ └──────────────────────────┘
    ▲ ③ 携带 ST 校验

    ┌──────────────────────────┐
    │ 业务系统 B / C / … │
    └──────────────────────────┘

    三个核心概念:

    • 一次登录,处处通行:用户只在 IdP 登录一次,拿到全局票据(TGC),之后访问任何接入系统都免登录。
    • 应用不存密码:业务系统只校验 IdP 签发的令牌,自身不再保管用户口令。
    • 集中管控:账号启用/禁用、强认证策略、审计日志,全部在 IdP 统一完成。

    三、CAS 协议流程(时序)

    CAS(Central Authentication Service)是成熟的 SSO 协议,流程如下:

  • 用户访问业务系统 A,A 发现未登录,重定向到 CAS 登录页。
  • 用户在 CAS 输入凭证登录,CAS 写入 TGC(全局票据,存于浏览器 Cookie),并重定向回 A,附带服务票据 ST。
  • 业务系统 A 后端拿着 ST 向 CAS 校验(/serviceValidate)。
  • CAS 返回用户信息,A 建立本地会话,放行。
  • 用户再访问业务系统 B,B 重定向到 CAS,CAS 发现已有 TGC,直接签发新的 ST 给 B,无需再次输入密码。

  • 四、ASP/ASP.NET 集成示例

    以 ASP.NET 应用接入 CAS 为例,核心是一个认证中间件:

    // ASP.NET Core 中间件:未登录请求重定向到 CAS
    public async Task InvokeAsync(HttpContext ctx)
    {
    if (!ctx.User.Identity.IsAuthenticated)
    {
    var casLogin = $"https://sso.example.com/cas/login" +
    $"?service={Uri.EscapeDataString(ctx.Request.GetDisplayUrl())}";
    ctx.Response.Redirect(casLogin);
    return;
    }
    await _next(ctx);
    }

    回调校验票据(伪代码):

    // 回调地址:CAS 携带 ticket 跳转回来后校验
    public async Task<IActionResult> Callback(string ticket, string service)
    {
    // 后端向 CAS 校验 ST
    var xml = await http.GetStringAsync(
    $"https://sso.example.com/cas/serviceValidate?ticket={ticket}&service={service}");
    if (CasValidateSuccess(xml, out var user))
    {
    // 建立本地登录态
    await HttpContext.SignInAsync(CookieScheme, BuildPrincipal(user));
    return Redirect(service);
    }
    return Challenge();
    }

    业务系统只需关心"拿到的用户是谁",密码与登录流程完全交给 CAS。


    五、令牌与会话安全要点

    • ST 短期有效:服务票据一次性、短时效,校验后立即失效,防重放。
    • TGC 加密存储:全局票据存于浏览器 HttpOnly Cookie,并启用 Secure 标记。
    • 全程 HTTPS:登录与票据校验必须走加密通道。
    • 集中注销(SLO):在 IdP 退出时,向所有已登录 SP 发送单点登出通知。

    六、与强认证、国密合规结合

    单点登录解决"统一身份",但登录环节的强度同样关键。在实际落地中可叠加:

    • 多因素认证(MFA):在 CAS 登录环节叠加 UKEY、手机令牌或人脸/指纹,满足等保"双因子"要求。
    • 国密合规:认证服务器支持国密 SM2/SM4 算法,令牌签名与传输符合密评要求。

    七、落地 checklist

  • 梳理全量业务系统清单,确定接入优先级。
  • 部署统一认证服务器(IdP),配置账号源(LDAP/AD/数据库)。
  • 业务系统改造:增加 CAS 客户端中间件,移除本地密码登录。
  • 配置强认证策略与单点登出(SLO)。
  • 开启统一审计日志,留存登录与票据校验记录。
  • 灰度切换:先非核心系统,验证通过后全面推广。

  • 作者注:本文聚焦单点登录的架构与核心机制,所涉统一认证、强认证与国密能力可结合实际身份基础设施落地。具体部署建议结合业务规模与合规要求评估。

    免责声明:本文仅供技术交流,具体合规要求请以官方标准文件为准。

    赞(0)
    未经允许不得转载:171主机测评 » ASP 单点登录实战:用 CAS 协议打通多个系统的统一身份认证
    分享到: 更多 (0)

    评论 抢沙发

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址