科普：零信任架构基础篇之单点登录 - FreeBuf网络安全行业门户

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

工具

科普：零信任架构基础篇之单点登录

持安科技 2022-03-24 11:41:09 242889

所属地北京

#1 什么是SSO

零信任理念遵循的“持续验证，永不信任”原则，零信任架构中需要使⽤到的SSO，即单点登录 (Single sign-on) ，是⼀种⾝份验证⽅法。它只需要⽤户使⽤⼀组账号密码或登录凭据，就可以快速、安全地登录多个应⽤系统。持安零信任平台不仅具备基于Cookie⽅式的SSO单点登录⽅式，还具备超强融合其他单点系统的能⼒，当第三⽅SSO单点登录系统使⽤标准的OAuth2.0、SMAL或CAS等协议时，持安零信任平台可在不改变⽤户原有的认证⽅式和使⽤体验的情况下对内，加强原有IAM系统的⽹关审计、管控和安全防护能⼒。

1648093127_623be7c7ef9d723569ef9.png!small

#2 为什么我们需要SSO

当企业使⽤了优质的 SSO 解决⽅案时，它会增加更多的安全性、可⽤性、易⽤性并让运维⼈员省时省⼒。

1.更⾼的安全性和合规性

在常⻅的攻击场景中，⽆论是浏览器保存的⽤户名密码、本地存放的密码或是加密软件保护的密码，其本质都是保存了对⽤户可⻅的账号与密码，这些密码对攻击者的价值往往⾮常⼤。尽管我们在⽇常接受的安全教育和培训中，总是提到不要使⽤相同的密码，尽量使⽤复杂度较⾼的密码，但因为懒惰和健忘是⽆法避免的，所以即便是深谙安全之道的安全从业者，也很难做到这⼀点，更不⽤说安全意识没有那么⾼的普通⽤户了。

单点登录（SSO）技术的出现⼀定程度上规避了这种⻛险。在零信任架构中，使⽤⼀次⾝份认证后的凭证，即可访问多个应⽤系统。即便攻击者们通过代理或隧道的⽅式，能够访问到应⽤系统的登录界⾯，也⽆法通过信息收集、钓⻥、暴⼒破解等⽅式获取到的账号密码来登录系统。

2. 更好的可⽤性和良好的⽤户体验

正是这种⼀次登录凭证，可以访问多个应⽤系统的特性，使得员⼯们⽆需为多套系统记住多个账号密码，就可以访问多套应⽤，减少了在多套应⽤系统内来回切换所浪费的时间与精⼒。

3. 减少运维成本

单点登录（SSO）技术可以通过减少运维⼈员时间的⽅式来降低员⼯成本。假设⼀个企业的内部有多套系统，这些系统的使⽤⼈员可能是本公司的员⼯，也可能是外包⼈员或者供应商，企业的⼈员越多，运维⼈员管理这些系统账号密码的成本也就越⼤。如果⼀个员⼯忘记密码了，想要找到运维⼈员帮助重制密码，那在企业⼈员超过⼀定规模的时候，很可能仅为了重制密码⼀项，就需要⼀位运维⼈员来处理。对于SSO⽽⾔，⽤户只需要记住⼀套账号密码即可，密码重制的功能，也可以由SSO来完成，⽆需由运维⼈员参与进来。

#3 SSO的原理

随着⽇常办公应⽤系统的增加，⽤户需要在多套系统之间来回切换，SSO的认证机制能够帮助⽤户解决这个问题。

1648093149_623be7dd11698775b1cbb.png!small

以上场景中，假设⽤户需要同时访问Wiki和Git，在不使⽤SSO技术的场景下，需要分别访问两个站点，并由这两个站点分别鉴权判断⽤户是否有权限访问，由运维⼈员单独管理账号密码。

在使⽤了SSO技术之后，⽤户只需要使⽤⼀套账号密码，即可访问两个或以上接⼊ SSO的系统。

SSO的访问和流程⼤致可以列为以下步骤：

1. ⽤户想要访问Wiki，向服务端发起请求；

2. 如果⽤户的请求中携带会话信息，那么Wiki服务器会携带此会话凭证向SSO服务器进⾏认证；

3. 如果SSO服务器校验通过，则会返回登录凭证，并将⽤户的登录凭证存储在浏览器中；

4. 如果SSO服务器校验未通过，则会提⽰⽤户进⾏SSO登录认证，认证成功后，重复第三步；

5. 此时⽤户希望登录另外的Git系统，向Git系统发起登录请求，此时SSO服务器上仍然保存了⽤户的有效登录会话，在判断⽤户确实有权限访问Git系统后，重复第三步。

这种登录⽅式极⼤简化了登录流程，⽆论是对使⽤者还是管理者来说，都更⾼效、安全和快捷了。

#4 SSO的实现⽅式

基于Cookie的单点登录

基于 Cookie 的单点登录是最简单的单点登录实现⽅式，它使⽤ Cookie 作为媒介，存放⽤户凭证。

⽤户登录⽗应⽤之后，应⽤返回⼀个加密的 Cookie，⽤户访问⼦应⽤的时候，携带上这个 Cookie，授权应⽤解密 Cookie 并进⾏校验，校验通过则登录当前⽤户。

基于JWT的单点登录

JWT全称是JSON Web Token，是⼀种开放的、⾏业标准的RFC 7519⽅法，⽤在客户端与服务端之间的安全通信技术。

常⻅的形式如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

数据是由 . 进⾏分割的，依次由三部分内容组成，Header、Payload和Signature。

Header.Payload.Signature

头部解出来的数据是这样

{

"alg": "HS256",

"typ": "JWT"

}

上⾯的JSON数据中， alg 键值表⽰签名的算法，默认是 HMAC SHA256， typ 属性表示这个token的类型。经常观察⽹络数据包的同学⼀眼就看出来，这是由base64编码组成的数据， ejJ 字符在解码之后的数据，就是 {" 。也就是说，JWT中的⼀部分数据，是可以通过base64 解码的⽅式得到的，所以切勿在JWT中放⼊重要的信息，例如⽤户的⾝份信息、账户密码信息、重要的系统信息等等。基于Cookie的单点登录⽅式⽐较难以实现跨域通信，因为浏览器的同源策略限制⽽导致扩展性不强。JWT认证的⽅式恰好弥补了这样的需求，JWT可以⾮常⽅便的跨域通信，所有的认证数据都将保存在客户端，每次请求都发回服务器。

基于Auth 2.0的单点登录

OAuth是⼀个关于授权（authorization）的开放⽹络标准，在全世界得到⼴泛应⽤，⽬前的版本是2.0版。

OAuth在客户端与服务端之间，设置了⼀个授权层。客户端不能直接登录服务端，只能登录授权层。

认证的流程如下：

1. ⽤户希望登录第三⽅应⽤，点击登录后，客户端向认证服务器发送请求，在请求中携带上⾃⼰的⾝份，希望进⾏认证，⽤户授权完成后的回调url；

2. 认证服务器展⽰给出⽤户授权界⾯；

3. ⽤户进⾏授权操作，认证服务器验证成功后，⽣成⼀个授权编码token，并跳转到第三⽅的回调url；

4. 第三⽅应⽤拿到token后，连同⾃⼰在平台上⾝份信息发送给认证服务器，再⼀次进⾏验证请求，以换取访问⽤户资源的权限；

5. 认证服务器对请求信息进⾏验证，认证成功后，⽣成访问资源服务器的令牌AccessToken，交给第三⽅应⽤；

6. 第三⽅应⽤使⽤AccessToken向资源服务器请求资源；

7. 资源服务器验证AccessToken成功后返回响应资源。

这个过程⼤多数操作需要⽤户⼿动点击，需要⼀定的交互。所以在使⽤此类认证模式时，需要防⽌点击劫持。防⽌点击劫持最有效的办法是在返回的请求头中，加⼊ X- Frame-Options 的HTTP响应头，使得攻击者⽆法通过嵌套的⽅式加载⽹⻚。

基于SAML 2.0的单点登录

SAML（Security Assertion Markup Language）名为安全断⾔标记语⾔，SAML 2.0 是⼀种XML标准，⽤于安全地交换 SAML 断⾔，在 SAML 机构（称为⾝份提供商或 IdP）和 SAML 消费者（称为服务提供商或 SP）之间传递有关⽤户的信息，借助 SAML，在线服务提供商可与独⽴的在线⾝份提供商联系，从⽽对尝试访问安全内容的⽤户进⾏⾝份验证。

以下过程说明了⽤户如何通过合作伙伴运营的基于 SAML 的 SSO 服务登录到托管 Google 应⽤。

如下所⽰，介绍了⽤户通过基于 SAML 的 SSO 服务登录到 Gmail 等 Google 应⽤的过程。图⽚之后的编号列表更详细地说明了各个步骤。

注意：进⾏以下程序之前，合作伙伴必须向 Google 提供其 SSO 服务的⽹址以及 Google ⽤来验证 SAML 响应的公钥。 1648093176_623be7f8323b997b46478.png!small

此图⽚说明了以下步骤。

1.⽤户尝试访问托管 Google 应⽤，例如 Gmail、初始⻚或其他 Google 服务。

2. Google ⽣成 SAML ⾝份验证请求。系统会对此 SAML 请求进⾏编码，并嵌⼊到合作伙伴的 SSO 服务⽹址中。SSO ⽹址中还包括 RelayState 参数，其中包含⽤户尝试访问的 Google 应⽤的编码⽹址。此 RelayState 参数是⼀种隐性标识符，返回时不会经过任何修改或检查。

3. Google 将重定向⽹址发送到⽤户的浏览器。重定向⽹址包含应向合作伙伴 SSO 服务提交的经过编码的 SAML ⾝份验证请求。

4. 合作伙伴解码 SAML 请求，并提取 Google 的 ACS（声明消费者服务）⽹址和⽤户的⽬标⽹址（RelayState 参数），然后对⽤户进⾏⾝份验证。合作伙伴可能会要求提供有效登录凭据或检查有效会话 Cookie，以验证⽤户⾝份。

5. 合作伙伴⽣成⼀个 SAML 响应，其中包含经过验证的⽤户的⽤户名。按照 SAML 2.0 规范，系统会使⽤合作伙伴的 DSA/RSA 公钥和私钥对此响应进⾏数字签名。

6. 合作伙伴对 SAML 响应和 RelayState 参数进⾏编码，并将该信息返回到⽤户的浏览器。合作伙伴提供⼀个转发机制，以便浏览器将信息转发给 Google 的 ACS。例如，合作伙伴会将 SAML 响应和⽬标⽹址嵌⼊到表单之中，然后提供⼀个按钮，让⽤户点击该按钮即可将表单提交给 Google。合作伙伴还可能在⻚⾯中加⼊ JavaScript，以便⾃动向 Google 提交表单。

7. Google ACS 使⽤合作伙伴的公钥验证 SAML 响应。如果成功验证响应，则 ACS 会将⽤户重定向到⽬标⽹址。

8. ⽤户重定向到⽬标⽹址并登录到 Google。

基于CAS的单点登录

CAS（Central Authentication Service），名为集中式认证服务。是⼀种针对Web应⽤的单点登录协议。它的⽬的是允许⼀个⽤户访问多个应⽤程序，⽽只需向认证服务器提供⼀次凭证（如⽤户名和密码）。这样⽤户不仅不需在登陆web应⽤程序时重复认证，⽽且这些应⽤程序也⽆法获得密码等敏感信息。了解CAS的认证流程，⾸先需要了解⼏个名词的意思。

1. TGC（Ticket-Granting Cookie）

票据授予 cookie 是 CAS 在建⽴单点登录会话时设置的cookie。该cookie保存客户端的登录状态，当它有效时，客户端可以将其发送给 CAS⽤来代替主要凭证。

2. TGT（Ticket Granting Ticket）

TGT是CAS为⽤户签发的登录票据，拥有了TGT，⽤户就可以证明⾃⼰在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的⽤户信息。⽤户在CAS认证成功后，CAS⽣成cookie，写⼊浏览器，同时⽣成⼀个TGT对象，放⼊⾃⼰的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有 CAS⽣成的cookie，则CAS以此cookie值为key查询缓存中有⽆TGT ，如果有的话，则说明⽤户之前登录过，如果没有，则⽤户需要重新登录。

3. ST（Service Ticket）

ST是CAS为⽤户签发的访问某⼀Web应⽤的票据。⽤户访问该服务时，如果服务端发现⽤户没有ST，则会要求⽤户去CAS获取ST。⽤户向CAS发出获取ST的请求，如果⽤户的请求中包含Cookie，则CAS会以此Cookie来查询缓存或数据库中有⽆TGT，如果存在TGT，则⽤此TGT签发⼀个ST，返回给⽤户。⽤户凭借ST去访问Web应⽤，Web应⽤拿ST去CAS校验，校验通过之后将指定的内容返回给⽤户。

1648093195_623be80b181b351efa1d9.png!small