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

Posted 2023-03-29 zhazhacong

#1

什么是SSO

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

#2

为什么我们需要SSO 

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

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

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

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

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

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

3. 减少运维成本 

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

#3

SSO的原理

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

以上场景中，假设⽤户需要同时访问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 响应的公钥。

此图⽚说明了以下步骤。 

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校验，校验通过之后将指定的内容返回给⽤ 户。

当浏览器试图访问Web应⽤时，Cookie中的TGT会随着Cookie⼀同发送到CAS服务 端，CAS通过验证TGT是否存在于其数据库中，以及该TGT在过去6⼩时内是否被使 ⽤来检查票据授予的有效性。如果TGT是有效的，CAS认为该会话已被认证。

CAS的认证流程⼤致如下：

1. ⽤户请求访问接⼊CAS的Web引⽤ ；

2. CAS检测到⽤户未登录，要求⽤户登录CAS ；

3. CAS校验⽤户的登录凭证 ；

4. CAS确定⽤户存在并校验通过 ；

5. CAS⽣成服务票据并且将浏览器重定向到⽤户具有权限的Web应⽤；

 6. Web应⽤校验服务票据 ；

7. Web应⽤校验通过，并将指定的内容返回给⽤户。

#5

总结

SSO实现⽅式还有很多，在多年的发展过程中技术已经成熟，在零信任架构中SSO也 是⾮常重要的⼀环。 

有效的零信任策略组合利⽤了多种现有技术和⽅法，“持续验证，永不信任”这种概 念，⽽SSO技术恰好与零信任的概念紧密贴合，在采⽤SSO登录⽅式时，可以结合多因⼦认证（MFA）的⽅式，使得SSO的登录更为安全。 

当然，想要实现完整的零信任架构，优秀的SSO仅仅是开始，还需要⾝份和访问管理 （IAM）、特权访问管理 （PAM）、⽹络分段等等，来实现全⾯的深度防御，即使⽤ 户已经认证成功，也应当以最⼩化的权限去访问⽤户所属的应⽤系统。

持安科技创始团队，在⾰命性的零信任安全领域已有数年的持续积累和国内⾸家零信 任实际落地经验，并参与了⾏业的相关标准建⽴、⼈才培训等⼯作，积累了丰富的经 验，我们将在该领域深度耕耘，打造出独特出众的产品，为企业提供有价值的服务。

#6

参考资料

• https://en.wikipedia.org/wiki/Single_sign-on https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol 

• https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/ 

• https://www.onelogin.com/learn/how-single-sign-on-works 

• https://www.cloudflare.com/learning/access-management/what-is-sso/ 

• https://infrastructure.tamu.edu/auth/CAS/Flows.html 

• https://support.google.com/a/answer/6262987?hl=zh-Hans

架构之路 | 浅谈单点登录（SSO）技术实现机制

1

何为单点登录?

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

２

用来解决什么问题?

解决了用户只需要登录一次就可以访问所有相互信任的应用系统，而不用重复登录。

3

常见的实现方式

单点登录有不同的实现方式，本文就罗列我开发中所遇见过的实现方式。

以Cookie作为凭证媒介：

最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。

用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。

以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑：

• Cookie不安全

• 不能跨域实现免登

对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露，攻击者通过伪造Cookie则可以伪造特定用户身份，这是很危险的。

对于第二个问题，更是硬伤。

通过JSONP实现：

对于跨域问题，可以使用JSONP实现。
用户在父应用中登录后，跟Session匹配的Cookie会存到客户端中，当用户需要登录子应用的时候，授权应用访问父应用提供的JSONP接口，并在请求中带上父应用域名下的Cookie，父应用接收到请求，验证用户的登录状态，返回加密的信息，子应用通过解析返回来的加密信息来验证用户，如果通过验证则登录用户。

这种方式虽然能解决跨域问题，但是安全性其实跟把信任存储到Cookie是差不多的。如果一旦加密算法泄露了，攻击者可以在本地建立一个实现了登录接口的假冒父应用，通过绑定Host来把子应用发起的请求指向本地的假冒父应用，并作出回应。

因为攻击者完全可以按照加密算法来伪造响应请求，子应用接收到这个响应之后一样可以通过验证，并且登录特定用户。

通过页面重定向的方式：

最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。

父应用提供一个GET方式的登录接口，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个的登录页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证Token的接口，通过解密和校验之后，子应用登录当前用户

 这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，但是并没有前面两种方式方便。

安全与方便，本来就是一对矛盾。

使用独立登录系统：

一般说来，大型应用会把授权的逻辑与用户信息的相关逻辑独立成一个应用，称为用户中心。

用户中心不处理业务逻辑，只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕返回凭证，第三方应用验证凭证，通过后就登录用户。

以下讲解下以使用独立登录系统的实现机制：

4

单点登录的技术实现机制

先看下图：

当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4,6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

从上图可以看出sso的实现技术点：

1）所有应用系统共享一个身份认证系统

统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。

2）所有应用系统能够识别和提取ticket信息

　要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

关于统一身份认证机制：如下图

①用户请求访问业务系统。

③在统一身份认证平台提供的页面中，用户输入身份凭证信息，平台验证此身份凭证信息，若有效，则生成一个有效的令牌给用户，进入第④步；若无效，则继续进行认证，直到认证成功或退出为止。

④用户携带第③步获取的令牌，再次访问业务系统。

⑤业务系统获取用户携带的令牌，提交到认证平台进行有效性检查和身份信息获取。

⑥若令牌通过有效性检查，则认证平台会把令牌对应的用户身份信息返回给业务系统，业务系统把身份信息和有效令牌写入会话状态中，允许用户以此身份信息进行业务系统的各种操作；若令牌未通过有效性检查，则会再次重定向到认证平台，返回第③步。

通过统一身份认证平台获取的有效令牌，可以在各个业务系统之间实现应用漫游。

5

单点登录的优、缺点

优点：

1）提高用户的效率。

　　用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。 

2）提高开发人员的效率。

　　SSO 为开发人员提供了一个通用的身份验证框架。实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。 

3）简化管理。

　　如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。

缺点：

1）不利于重构

　　因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时

2） 无人看守桌面

　　因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。

帅的人都已经点赞、转发了 ！！！！蟹蟹

▼

大咖聊技术

微信号：591566764

推荐理由：

在这里，我们一起聊一聊互联网，人工智能，大数据时代的那点事，有想法的都可以给小编留言沟通。

 ▼长按下方↓↓↓二维码识别关注