下载掌阅APP，畅读海量书库
立即打开
身份认证就是判断一个用户是否为合法用户的处理过程。网络环境下的身份认证不是对某个事物的资质审查，而是对事物真实性的确认。身份认证要确认通信过程中另一端的个体是谁（人、物、虚拟过程）。计算机网络世界中一切信息包括用户的身份信息都是用一组特定的数据来表示的，计算机只能识别用户的数字身份，所有对用户的授权也是针对用户数字身份的授权。如何保证以数字身份进行操作的操作者就是这个数字身份的合法拥有者，也就是说保证操作者的物理身份与数字身份相对应，身份认证就是为了解决这个问题。作为防护网络安全的第一道关口，身份认证有着举足轻重的作用。
IAM系统除了对各应用系统进行统一身份管理，还具备统一身份认证、统一访问控制、统一访问审计的能力。IAM系统的一个基本应用模式是统一认证模式，它是以统一身份认证服务为核心的服务应用。IAM系统对外提供统一认证的Portal页面，用户通过安全认证登录统一身份认证Portal门户后，即可安全登录有权限访问并使用所有支持统一身份认证服务管理的应用系统，实现了统一认证和单点登录。
IAM系统的统一认证服务通过Web Service对外发布认证服务，实现了平台的无关性，能够与各种主机、各种应用系统对接。另外，IAM系统还提供了一套标准的接口，保证IAM系统与各种应用系统之间对接的易操作性。IAM系统的统一认证中心通过统一管理不同应用体系身份存储方式、统一认证的方式，使同一用户在所有应用系统中的身份一致，且用户在登录第三方应用程序时不必关心身份的认证过程。
身份认证的目的是鉴别通信中另一端的真实身份，防止伪造和假冒等情况发生。根据身份认证的对象不同，认证手段也不同，但针对每种身份的认证都有很多种不同的方法。身份认证的对象可以是人、网络设备、机器，也可以是物联网中的物，这里主要讲解对人的认证。如果被认证的对象是人，则有三类信息可以用于身份认证。
1.基于信息秘密的身份认证
根据你所知道的信息来证明你的身份（What You Know，你知道什么），如口令密码、个人身份识别码（Personal Identification Number，PIN）等。
这种类型的认证，主要特点是实现较为简单，只需要设定相应的账号密码，在用户登录时输入正确的密码，计算机就认为操作者是合法用户。实际上，由于许多用户为了防止忘记密码，经常采用如生日、电话号码等容易被猜测的字符串作为密码，或者把密码抄在纸上放在一个自认为安全的地方，这样很容易造成密码泄露。如果密码是静态的数据，则由于在验证过程中需要在计算机内存和网络中传输，所以可能会被木马程序或网络截获。因此，静态密码机制无论是使用还是部署都非常简单，但从安全性上讲，用户名/密码方式是一种不安全的身份认证方式，存在被暴力破解、木马窃听、线路窃听、重放攻击等安全风险。
2.基于信任物体的身份认证
根据你所拥有的东西来证明你的身份（What You Have，你有什么），如密码本、密码卡、动态密码生产器、U盾等，另外在可信设备上进行扫码或一键确认登录的方式也属于此种身份认证类型。
这种类型的认证是采用用户所持有的东西验证用户的身份，用于身份鉴别的工具通常不容易被复制，安全性非常高。但是此种类型的认证，需要额外增加第三方认证工具，需要增加采购认证工具硬件成本，还存在授权到期不能使用、认证工具遗失、认证工具电池耗尽等问题存在。USB Key需要随身携带，如忘记携带或丢失，则无法进行身份认证，进而无法登录应用系统进行事务办理。近年来移动交易情形的普及，各个银行推出相应的移动蓝牙盾、音频盾等，蓝牙盾、音频盾同样存在难以携带或丢失的情形，同时也存在电量较低无法正常使用的现象，需要保持电量充足。以上所有类型的USB Key都需要向专门的厂商购买，需要一定的工本费，且USB Key的使用权限有限制，授权到期需要再次进行授权才能继续使用。
3.基于生物特征的身份认证
直接根据独一无二的身体生物特征来证明你的身份（What You Are，你是谁），如指纹、人脸、虹膜、笔迹、语音特征等。
这种类型的认证是通过可测量的身体或行为等生物特征进行身份认证的一种技术。生物特征是指唯一的可以测量或可自动识别和验证的生理特征或行为方式。生物特征分为身体特征和行为特征两类。身体特征包括指纹、掌型、视网膜、虹膜、人体气味、脸型、手的血管和DNA等；行为特征包括签名、语音、行走步态等。目前部分学者将视网膜识别、虹膜识别和指纹识别等归为高级生物识别技术；将掌型识别、脸型识别、语音识别和签名识别等归为次级生物识别技术；将血管纹理识别、人体气味识别、DNA识别等归为“深奥的”生物识别技术。采用生物认证方式比口令密码方式的安全性和用户体验都有很大提升，但是生物认证也有一定的局限性，从企业角度来说，老旧设备不支持生物认证，需要外接生物认证设备，增加企业成本，或者需要单独建设生物认证平台；从用户角度来说，长期劳作或手指纹破损无法指纹验证，化妆后无法进行人脸识别，生病后声音变化无法进行声纹识别等现象发生。
在网络世界中，身份认证手段与真实世界中的一致，仅通过一个条件的符合来证明一个人的身份称为单因子认证，为了达到更高的身份认证安全性，某些场景会将上面的3种认证挑选两种或两种以上混合使用，即所谓的双因素认证和多因素认证。
常见的身份认证方式与比较如表3-5所示，接下来分别进行简要介绍。
表3-5 常见的身份认证方式与比较
1.账户密码
用户名/密码认证方式是最简单也是最常用的身份认证方法之一，它是基于“What You Know”的验证手段。每个用户的密码是由这个用户自己设定的，只有他自己才知道，因此只要能够正确输入密码，计算机和应用系统就认为他就是这个用户。然而在实际中，由于许多用户为了防止忘记密码，经常采用诸如自己或家人的生日、电话号码、简单口令等容易被他人猜测到的有意义的或过于简单的字符串作为密码，或者把密码抄写在一个自己认为安全的地方，这都存在许多安全隐患，极易造成密码泄露。即使能保证用户密码不被泄露，由于密码是静态的数据，并且在验证过程中需要在计算机内存和网络中传输，而每次验证过程使用的验证信息都是相同的，很容易被驻留在计算机内存中的木马程序或网络中的监听设备截获。因此，用户名/密码方式是一种极不安全的身份认证方式。可以说它基本上没有任何安全性可言。
随着现在用户使用的应用系统越来越多，多个应用系统设置为同一个密码，容易被撞库造成数据或资金的丢失；若多个应用系统设置为多个密码，则密码难以管理，容易遗忘，找回时需要自身进行密码找回申诉或找系统管理员进行重置，给自身和系统管理员带来诸多额外工作量。
2.扫码
扫码认证方式是近几年出现的一种便捷的免密身份认证及用户登录的一种常见认证方式，扫码认证摒弃了传统密码口令认证方式，实现了安全性和用户体验的完美结合。
在我们使用某个终端登录某个应用系统时，登录页面显示一个登录二维码，然后用移动终端上的App扫一下，移动终端App上显示登录确认的页面，用户点击“确认”按钮后，登录应用系统的终端即可登录到应用系统并跳转到应用内部页面。需要登录的终端上的二维码本质是一个统一资源定位系统（Uniform Resource Locator，URL），如http：//www.phei.com.cn？uuid=xxxxx，这个uuid是生成的当前终端的唯一标识，然后会定时请求后端的API，假设这个请求称为A请求，根据返回的状态来做下一步动作。当移动终端扫码后，会带上这个uuid和用户信息，发送一个请求给后端，后端拿到这个uuid，就知道用户正在请求登录，然后上面的A接口会返回一个已经登录的状态，同时返回用户信息，这样二维码页面会跳转到应用系统内部页，整个扫码登录流程完成。
3.一键推送
一键推送认证方式也是近几年出现的一种便捷的免密身份认证的登录方式，一键推送认证方式大幅度地简化了用户注册/登录流程，且提升了账号安全性，逐步成为新一代的主流验证登录方式之一。
用户在移动终端App上进行账号注册或号码绑定时，不需要接收短信验证码，直接可以以本机号码实现秒级验证。这种新颖且便捷的验证方式称为“一键推送认证”。一键推送认证是依托运营商的移动数据网络，采用“通信网关取号”及SIM卡识别等技术实现的一种移动互联网身份认证方法。它主要有两种形式：一种是“一键登录”，一键登录具备授权页面，App开发者经用户授权后可获得号码，适用于注册、登录等场景；另一种是“本机号码校验”，本机号码校验不返回号码，仅返回待校验号码与本机号码是否一致的结果，适用于基于手机号码的安全风控的场景。对用户来说，无论是一键登录还是本机号码校验，都无须经历输入密码或等待短信验证码的过程，可以真正体验到“秒级验证”的快感。
4.USB Key
基于USB Key的认证方式是近些年发展起来的一种安全的身份认证技术。它采用软硬件相结合、一次一密的强双因子认证模式，很好地解决了安全性与易用性之间的矛盾。USB Key是一种USB接口的硬件设备，它内置单片机或智能卡芯片，可以存储用户的密钥或数字证书，利用USB Key内置的密码算法实现对用户身份的认证。基于USB Key身份认证系统主要有两种应用模式：一种是基于冲击/响应（挑战/应答）的认证模式；另一种是基于PKI体系的认证模式，运用在电子政务、网上银行等。
USB Key在使用上也存在很多弊端。首先，需要随身携带，若忘记携带或丢失，则无法进行身份认证，进而无法登录应用系统进行事务办理；其次，近年来移动交易情形的普及，各个银行推出相应的移动蓝牙盾、音频盾等，蓝牙盾、音频盾同样存在不易携带或丢失的情形，同时也存在电量较低无法正常使用的现象，需要保持电量充足；最后，以上所有类型的USB Key都需要向专门的厂商购买，需要一定的工本费，且USB Key的使用权限有限制，授权到期需要再次进行授权才能继续使用。
5.数字证书
公钥基础设施（PKI）作为一种强实体鉴别技术，能够在开放网络和应用系统中提供身份认证与鉴别，保障信息的真实性、完整性、机密性和不可否认性，对于实现零信任架构是至关重要的。一方面，PKI为每个主体签发一张可信身份数字证书（实名），只有符合安全规则的身份才能通过验证，访问相应的资源，简单高效地解决了信任问题。另一方面，PKI中的密码技术可以用来加密需要保护的数据，从根本上有效地保护了数据资产。公共PKI系统可以在安全的通信中为非受控的端点系统提供信任保证，证书颁发机构为通信双方签发证书以建立安全的通信。端点系统接收到经过签名的证书后，将它的签名信息和系统中已经预置的可信证书颁发机构列表进行比对，就可以验证该证书是否有效。通过在系统中预置可信证书颁发机构列表的方式，端点系统可以和之前从来没有通信过的未知系统建立安全信道。总之，PKI是零信任架构中身份认证的重要部分，也是解决人员信任问题最有效和最高效的技术。基于PKI技术的身份管理方案能有效解决零信任安全体系中“以身份为中心”的核心理念，可以简化身份管理和增强数据安全，更好地为企业实现零信任化转型提供有力的支持。
数字证书是标志网络用户身份信息的一系列数据，用来在网络通信中识别通信各方的身份，即要在Internet上解决“我是谁”的问题，就如同现实中每个人都要拥有一张证明个人身份的身份证或驾驶证一样，以表明我们的身份或某种资格。
数字证书采用公私钥密码体制，即利用一对互相匹配的密钥进行加密、解密。每个用户拥有一把仅为本人所掌握的私有密钥（私钥），用它进行解密和签名；同时拥有一把公共密钥（公钥）并可以对外公开，用于加密和验证签名。当发送一份保密文件时，发送方使用接收方的公钥对数据加密，而接收方则使用自己的私钥解密，这样，信息就可以安全无误地到达目的地了，即使被第三方截获，由于没有相应的私钥，无法进行解密。通过数字证书的手段保证加密过程是一个不可逆过程，即只有用私有密钥才能解密。用户也可以采用自己的私钥对信息加以处理，由于密钥仅为本人所有，这样就产生了别人无法生成的文件，也就形成了数字签名。采用数字签名，能够确认以下两点：一是保证信息是由签名者自己签名发送的，签名者不能否认或难以否认；二是保证信息自签发后到收到为止未曾做过任何修改，签发的文件是真实文件。
数字证书具有非常高的安全性和可靠性，也具有更强的访问控制能力。但数字证书是由权威公正的第三方机构签发的，需要向权威公正的第三方机构购买证书才能使用，成本较高。
6.OTP
一次性密码（One-time Password，OTP）利用What You Have认证类型，是一种动态密码认证方式。动态口令牌是用户手持用来生成动态密码的终端，主流的是基于时间同步的方式，如每60秒变换一次动态口令，口令一次有效，它产生6位动态数字进行一次一密的方式认证。但是由于基于时间同步方式的动态口令牌存在60秒的时间窗口，导致该密码在这60秒内存在风险，现在已有基于事件同步的，双向认证的动态口令牌。基于事件同步的动态口令，是以用户动作触发的同步原则，真正做到了一次一密，并且由于是双向认证的，即服务器验证客户端，并且客户端也需要验证服务器，从而达到杜绝木马的目的。
动态令牌需要随身携带，很多用户将动态令牌随手放在办公桌上，容易被其他人利用，另外动态令牌需要购买相应的硬件，有相应的工本费。目前市面上也出现了相应的软令牌，通过移动智能终端进行显示随机验证码进行验证，相比硬件动态令牌更为方便安全。
7.短信验证码
短信验证码也是利用What You Have的认证类型。用户在登录或交易认证时输入此动态密码，从而确保系统身份认证的安全性。由于手机与用户绑定比较紧密，短信密码生成与使用场景是物理隔绝的，因此密码在通路上被截取概率降至最低。只要会接收短信即可使用，大大降低短信密码技术的使用门槛，学习成本几乎为0，在市场接受度上不存在阻力。
以短信验证码进行身份验证，需要企业建设相应的短信平台，或者以租用公共短信平台的方式（以 x 元/条短信计费）。同时短信验证码也存在不安全因素，如手机中了木马/病毒，伪基站短信劫持、钓鱼短信等方式获取别人短信验证码，使得短信验证存在不安全因素。
8.人脸识别
人脸识别是基于人的脸部特征信息进行身份识别的一种生物识别技术。用摄像机或摄像头采集含有人脸的图像或视频流，并自动在图像中检测和跟踪人脸，进而对检测到的人脸进行脸部识别的一系列相关技术，通常称为人像识别、面部识别。人脸识别系统成功的关键在于是否拥有尖端的核心算法，并使识别结果具有实用化的识别率和识别速度；“人脸识别系统”集成了人工智能、机器识别、机器学习、模型理论、专家系统、视频图像处理等多种专业技术，同时需结合中间值处理的理论与实现，是生物特征识别的最新应用，其核心技术的实现，展现了弱人工智能向强人工智能的转化。
人脸识别技术的应用已经不仅限在商务场所中，而且已经以各种智能家居的形式逐步渗透到平常百姓家。但对于老旧设备不具备人脸信息采集的硬件，需要外接硬件摄像设备，同时企业如果使用人脸识别作为身份认证方式，则需要建设人脸识别系统，或者通过租用人脸识别服务的方式进行认证，有相当高的费用。另外，人脸识别的准确度依赖算法的优劣，有合法用户无法识别的概率。
9.指纹识别
指纹识别是目前较为成熟且价格便宜的生物特征识别技术。目前，指纹识别的技术应用非常广泛，我们不仅在门禁、考勤系统中可以看到指纹识别技术的身影，而且市场上有更多指纹识别的应用，如笔记本电脑、手机、汽车、银行支付等。
虽然每个人的指纹特征都是唯一的，但并不适用于每个行业、每个人。例如，长期手工作业的人们便会为指纹识别而烦恼，他们的手指若有丝毫破损或在干湿环境里、蘸有异物则指纹识别功能就失效了。对于老旧设备不具备指纹信息采集的硬件，需要外接硬件指纹仪。人的指纹信息容易被不法人员获取，用于非法认证等。
上面提到的身份认证方式都可以独立地对用户身份进行验证，随着网络用户数据泄露问题日益严重，单纯使用用户名和密码来保护用户资料已不够安全。重要的网络服务都开始使用多因素认证（Multi-Factor Authentication，MFA）来进一步保护用户数据的安全。
在用户进行身份鉴别时，系统往往要求结合你所知道的（用户名密码、PIN），你拥有的东西（智能卡、USBKey、动态令牌、智能手机），以及你的生物特征（人脸识别，虹膜扫描或指纹认证）进行多维度的身份认证。当用户接入网络或登录应用系统时，从单个因素变成两个或多个因素对用户身份认证时，网络或系统就能更确信在和正确的用户打交道。MFA的目的是建立一个多层次的防御，使未经授权的人访问计算机系统或网络更加困难。用户身份认证的各个维度如图3-10所示。
图3-10 用户身份认证的各个维度
根据2018年Gartner发布的报告《伪造身份和第一方欺诈伪装成信用损失的日益严重的问题》（ The Growing Problem of Synthetic Identity and First - Party Fraud Masquerades as Credit Losses ），报告将身份认证风险分为5个维度，即设备风险、真实身份、数字身份、历史行为、当前行为。设备风险主要包括使用模拟器进行设备仿冒、终端设备木马病毒风险、设备遭受0day漏洞攻击等；真实身份的风险有非本人使用终端设备、生物特征的仿冒等；数字身份的风险主要有数字身份仿冒、账户密码穷举等；历史行为是指用户登录系统的习惯行为、常在时间、常在地点等历史记录；当前行为的风险是参照历史行为记录的异常表现，如异常时间登录、异常地点登录、异常的IP登录、异常的风险操作行为、验证多次失败等。
《信息安全技术 网络安全等级保护基本要求》（GB/T 22239—2019）与《信息安全技术 网络安全等级保护基本要求》（GB/T 22239—2008）相比，第三级、第四级安全要求中在身份鉴别方面都新增了： 应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
故用户身份验证应从多个维度进行验证，而不仅仅是从用户的数字身份维度进行验证，即传统的账户密码。从你所知道的（What You Know）账户密码的维度进行认证，即使账户密码认证通过，也不能辨别用户的优劣。从图3-10中可以看出，在用户的数字身份正常的情况下，其他维度如设备存在安全风险、真实身份有可能伪造、历史行为上存在不良记录的用户行为、当前行为存在安全风险，用户有可能是优质用户（拥有正确的数字身份、良好意图、良好信用），也可能是风险用户（拥有正确的数字身份、不明意图、不良信用），还可能是恶意用户（拥有正确的数字身份、不明意图、不良信用）。所以，仅从数字身份来验证用户身份，不能够验证用户身份是否存在安全风险，应从多个维度对用户身份进行验证，从用户“所知”“所持”“所有”多维度的联合认证用户身份。
针对设备风险，企业应具备相应的风险感知平台，对终端设备是否为模拟器、是否存在攻击框架、是否中了病毒木马、终端上是否安装了安全防护软件、操作系统版本是否合规、有无安装盗版软件等进行检验。另外，用户接入企业网络和应用系统的终端设备应该和常用的账户做绑定，只有存在绑定关系的用户才能使用此终端设备进行登录和办公。
针对用户身份识别风险，面对组织架构复杂、人员组成多样化的特点，外协人员、外协团队、临时项目组、组织架构改变等都会给现有认证体系带来挑战，仅从数字身份维度认证已不能准确识别用户是否为真实的用户，应结合身份认证的所有（What You Are）维度对用户的真实身份进行识别，使用自然人的生物特征对用户身份进行认证，确保用户的真实性。
针对用户行为风险，企业的系统或设备应具备详细的用户行为审计功能，记录用户的历史行为和当前行为，对用户和实体行为进行分析，绘制用户画像，发现虚假用户和真实用户的风险行为，并对用户的风险行为及时进行策略处理。详细的用户和实体行为分析（User and Entity Behavior Analytics，UEBA）见3.6.3节。
单点登录（Single Sign On，SSO）是指在多系统应用群中登录一个系统，即可在其他所有系统中得到授权而无须再次登录，包括单点登录与单点注销两部分。
IAM系统不但具备用户的基本信息、角色、资源权限等集中管理和控制，而且能够提供统一的集中办公门户网站（Portal），在里面无缝连接其他系统的页面。它具备单点登录功能，并且能为第三方应用提供主流的登录认证。打通所有系统的账户密码（或只打通账户，采用免密认证方式进行身份鉴别），只需要记住一个就行，而且登录一个系统后，打开其他系统不再需要用户参与登录，不需要记住多个系统的地址，甚至不需要在多个系统页面频繁跳转，通过一个门户网站，串通起常用功能。单点登录关系架构图如图3-11所示。
图3-11 单点登录关系架构图
用户信息数据独立于各应用系统，形成统一的用户唯一ID，并将其作为用户的主账号。
（1）在通过平台统一认证后，可以从登录认证结果中获取平台用户唯一ID（主账号）。
（2）由平台统一关联不同应用系统的用户账号（从账号）。
（3）最后用关联后的账号访问相应的应用系统。
当增加一个应用系统时，只需要增加用户唯一ID（主账号）与该应用系统账号（从账号）的一个关联信息即可，不会对其他应用系统造成任何影响，从而解决登录认证时不同应用系统之间用户交叉和用户账号不同的问题。
从用户角度来看，单点登录解决了用户需要记忆多个用户名+密码的烦恼，不必再记录复杂的密码组合，大幅度提高了用户使用体验。
从系统管理员角度来看，单点登录系统可以使他们从烦琐的账号密码管理工作中解脱出来，不必每天为重置密码而苦恼，可以集中精力在数据安全保障工作中。
从企业管理角度来看，单点登录提高了员工的工作效率，减少了管理成本，提高了企业信息系统的安全性，也节约了后续开发系统的成本，提高了经济效益。
IAM系统实现多系统之间的单点登录，如第三方应用系统不支持改造，可采用密码代填的方式实现，即IAM系统记忆各个应用系统的密码，在登录各下游系统时，IAM系统将存储需要密码代填的应用系统的密码代填入应用系统登录框内，实现单点登录。密码代填的方式进行单点登录需要存储和传输密码，密码存储需要安全防护，传输需要屏蔽密码被截获的安全风险。若第三方应用系统有相应的技术人员支持改造，则可以采用安全标准协议实现单点登录。常用的单点登录协议有CAS协议、SAML协议、OAuth协议、OpenID协议等。
单点登录的解决方案有很多，如收费的有UTrust、惠普灵动等，开源的有CAS、Smart SSO等，其中应用最为广泛的是CAS。
CAS是一款针对Web 应用的单点登录框架。CAS是耶鲁大学发起的一个开源项目，旨在为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为统一认证的一个项目。
CAS协议结构上包含两部分：CAS服务端（CAS Server）和CAS客户端（CAS Client）。CAS架构图如图3-12所示。
图3-12 CAS框架图
CAS Server负责完成对用户的认证工作，CAS Server需要独立部署，有不止一种CAS Server的实现，Yale CAS Server和ESUP CAS Server都是很不错的选择。CAS Server会处理用户名/密码等凭证（Credentials），它可能会到数据库检索一条用户账号信息，也可能在可扩展标记语言（Extensible Markup Language，XML）文件中检索用户密码，对这种方式，CAS均提供一种灵活但统一的接口/实现分离的方式，CAS协议是分离的，这个认证的实现细节可以自己定制和扩展。
CAS Client部署在客户端（指Web应用），原则上，CAS Client的部署意味着：当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证时，Web应用不再接受任何用户名密码等类似的凭证，而是重定向到CAS Server进行认证。目前，CAS Client支持非常多的客户端语言类型，如Java、.NET、ISAPI、PHP、Perl、uPortal、Acegi、Ruby、VBScript等，几乎可以说，CAS协议能够适合任何语言编写的客户端应用。
整个CAS协议的基础思想都是基于票据方式。CAS协议基本框架如图3-13所示。
图3-13 CAS协议基本框架
CAS Client与受保护的客户端应用部署在一起，以过滤非法访问的方式保护受保护的资源。对于访问受保护资源的每个Web请求，CAS Client会分析该请求的HTTP请求中是否包含服务器验证票据（Service Ticket，ST），若没有，则说明当前用户尚未登录，于是将请求重定向到指定好的CAS Server登录地址，并传递CAS Service地址（也就是要访问的目的资源地址），以便登录成功后转回该地址。用户在第3步中输入用户认证信息，若登录成功，则CAS Server随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到Service所在地址，并为客户端浏览器设置一个Ticket Granted Cookie（TGC），CAS Client 在拿到Service和新产生的Ticket后，在第5步和第6步中与CAS Server进行身份核实，以确保Service Ticket的合法性。
在该协议中，所有与CAS的交互均采用SSL协议，以确保ST和TGC的安全性。协议工作过程中会有2次重定向的过程，但是CAS Client与CAS Server之间进行Ticket验证的过程对用户是透明的，即无须用户参与，用户无感知。
以上讲述的是CAS协议流程，CAS基本模式已可以满足大部分简单的单点登录应用，CAS协议还可以提供Proxy（代理）模式，以适应更加高级、复杂的应用场景，这里不做详述。
安全断言标记语言（Security Assertion Markup Language，SAML）是一个基于XML的开源标准数据格式，它在当事方之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。SAML是结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，OASIS）安全服务技术委员会的一个产品，始于2001年。其最近的主要更新发布于2005年，但协议的增强仍在通过附加的可选标准稳步增加。SAML解决的最重要的需求是网页浏览器单点登录。
SAML协议结构上包括IDP、SP和User 3个部分。
IDP：英文全称为Identity Provider，即身份提供者，在单点登录中用来提供用户权限信息断言的一方。
SP：英文全称为Service Provider，即服务提供者，为用户提供所需服务的一方，通过IDP来实现用户身份验证。
User：用户，通过IDP来登录获取身份断言，使用断言来获取SP提供的服务。身份断言是一个包含用户身份信息的XML文本，其包含了用户的认证信息、用户属性、认证限制。
在使用SAML的案例中，User从SP那里请求一项服务。SP请求IDP并从IDP那里获得一个身份断言。SP可以基于这一断言进行访问控制的判断，即决定User是否有权执行某些服务。
下面以浏览器访问一个Web应用实现单点登录为例来说明单点登录的原理和流程（图3-14）。
步骤1：用户尝试访问Web应用1。
步骤2：Web应用1生成一个SAML身份验证请求。SAML请求将进行编码并嵌入单点登录服务的URL地址中。其包含用户尝试访问的Web应用1应用程序的编码URL地址的RelayState（一个不透明的标识符）参数也会嵌入到单点登录网址中。该RelayState参数作为不透明标识符，将直接传回该标识符而不进行任何修改或检查。
步骤3：Web应用1将重定向发送至用户的浏览器。重定向URL地址包含应向单点登录服务提交的编码SAML身份验证请求。
步骤4：Identity Provider解码SAML请求，并提取 Web应用1的断言消费者服务（Assertion Consumer Service，ACS）URL地址以及用户的目标URL地址（RelayState 参数）。然后，统一认证中心对用户进行身份验证。统一认证中心可能会要求提供有效登录凭据或检查有效会话Cookie以验证用户身份。
步骤5：统一认证中心生成一个SAML响应，其中包含经过验证的用户名。按照SAML 2.0规范，此响应将使用统一认证中心的DSA/RSA公钥和私钥进行数字签名。
步骤6：统一认证中心对SAML响应和RelayState参数进行编码，并将该信息返回用户的浏览器。统一认证中心提供了一种机制，以便浏览器可以将该信息转发到Web应用1的ACS。
步骤7：Web应用1使用统一认证中心的公钥验证SAML响应。若成功验证该响应，则ACS会将用户访问重定向到目标URL地址。
步骤8：验证成功后，应用服务器的ACS将SAML的验证成功结果返回浏览器。
步骤9：浏览器将用户访问重定向到目标URL地址并登录到Web应用1的内部页面。
图3-14 SAML协议单点登录流程图
从安全性上考虑，由于SAML在两个拥有共享用户的站点间建立了信任关系，因此安全性是需考虑的一个非常重要的因素。SAML中的安全弱点可能危及用户在目标站点的个人信息。SAML依靠一批制定完善的安全标准，包括SSL和X.509，来保护SAML源站点和目标站点之间的通信安全。源站点和目标站点之间的所有通信都经过了加密。为确保参与SAML交互的双方站点都能验证对方的身份，还使用了证书进行身份校验。
OAuth是一种授权机制，用来授权给第三方应用，获取第三方应用用户数据，进而实现单点登录。OAuth是一个开放的标准，在移动、Web平台能提供一种安全的API授权，使第三方应用不需要以账号密码通过授权的方式就可以进行登录，安全保障账号数据不被泄露。
OAuth当前有两个版本，OAuth 1.0和OAuth 2.0，OAuth 2.0在OAuth 1.0基础上有了很多改进，且不能兼容OAuth 1.0，本节只对OAuth 2.0做详细介绍。
OAuth 2.0有4种授权模式，分别是授权码模式、简化模式、密码模式、客户端模式，其中授权码模式是功能最完整、流程最严密的授权模式，下面对授权码模式做详细介绍。
OAuth 2.0共包含3种角色，分别是第三方应用客户端（可以是Web应用的浏览器，也可以是移动应用客户端）、统一认证服务（授权第三方应用登录的服务，也称授权服务）和第三方应用服务（需要做单点登录的第三方应用服务）。
授权码方式指的是第三方应用先申请一个授权码，然后再用该码获取令牌。这种方式是最常用的流程，安全性也最高，它适用于那些有后端的Web应用和移动应用。授权码通过前端传送，令牌则是储存在后端的，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄露。
OAuth 2.0单点登录流程图如图3-15所示，下面介绍具体流程。
图3-15 OAuth 2.0单点登录流程图
步骤1：用户使用浏览器登录第三方应用客户端，或者在移动终端打开第三方应用App。
步骤2：第三方应用客户端向统一认证客户端申请登录授权码Code。
步骤3：统一认证客户端检验自身是否已经是登录状态，如果处于未登录状态，则需要用户登录统一认证客户端门户。
步骤4：用户使用相应的认证方式对统一认证客户端门户进行认证。
步骤5：统一认证客户端门户身份验证成功后，第三方应用客户端向统一认证服务端申请授权码Code，到统一认证服务端去验证应用身份。
步骤6：统一认证服务端验证应用身份成功后，返回授权码Code给统一认证客户端。
步骤7：统一认证客户端返回授权码Code给第三方应用客户端，第三方应用客户端收到授权码Code后，即对第三方应用客户端申请统一认证平台授权登录进行了授权。
步骤8：第三方应用客户端携带AppID、Secret、授权码Code和重定向的第三方应用的URL地址向统一认证服务端申请Access_token。
步骤9：第三方应用客户端在收到统一认证服务端返回的Access_token和OpenID后，将Access_Token和OpenID传递给第三方应用服务端并向统一认证服务端换取用户信息。
步骤10：统一认证服务端将用户信息返回给第三方应用客户端，授权登录成功，跳转到第三方应用客户端内部页面。
OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（Identity Provider，IDP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份的提供者。OpenID既解决了问题而又不需要依赖于中心性的网站来确认数字身份。
OpenID是一个以用户为中心的数字身份识别框架。它具有开放、分散、自由等特性。OpenID提高了互联网服务的用户体验。显而易见，就终端用户而言，OpenID降低了用户管理多个网站账号的烦恼，用户可以享受类似单点登录的体验。对企业来说，OpenID降低了用户账号管理的成本。对应用开发者来说，OpenID是一个开放的、去中心化的、免费的、以用户为中心的身份标识体系。OpenID的优势是一处注册，到处使用。
OpenID的创建是基于这样一个概念：我们可以通过统一资源标识符（Uniform Resource Identifier，URI）来识别一个网站。同样，我们也可以通过这样的方式来识别一个用户的身份。OpenID的身份认证就是通过URI来认证用户身份的。目前绝大部分网站都是通过用户名与密码来登录认证用户身份的，这就要求大家在每个要使用的网站上注册一个账号。如果使用OpenID，那么可以在一个提供OpenID的网站上注册一个OpenID，之后可以使用这个OpenID去登录支持OpenID的网站。
OpenID由3个角色组成：End User——终端用户，使用OpenID作为网络通行证的互联网用户；Relying Part（RP）——OpenID支持方，支持End User用OpenID登录自己的网站；OpenID Provider（OP）——OpenID提供方，提供OpenID注册、存储等服务。目前OpenID的最新版本为OpenID Connect，简称OIDC。OIDC是一个基于OAuth 2.0 的轻量级认证+授权协议，是OAuth 2.0的超集，其使用OAuth 2.0的授权服务器来为第三方客户端提供用户的身份认证，并把对应的身份认证信息传递给客户端。OAuth 2.0提供了Access_token来解决授权第三方客户端访问受保护资源的问题；OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。它还使用JOSN签名和加密规范，来传递携带签名和加密的信息。
OIDC的核心在于在OAuth 2.0的授权流程中，一并提供用户的身份认证信息（ID_token）给到第三方客户端，ID_token使用JWT［JSON Web Token，一种基于JSON的开放标准（RFC 7519）］格式来包装，得益于自包含性、紧凑性及防篡改机制，使得ID_token可以安全地传递给第三方客户端程序并且容易被验证。此外，它还提供了UserInfo（用户信息）的接口，用于获取用户更完整的信息。
下面介绍OIDC授权码模式的单点登录流程。OIDC协议单点登录流程图如图3-16所示。
图3-16 OIDC协议单点登录流程图
由于OIDC是一个基于OAuth 2.0 的轻量级认证+授权协议，因此单点登录流程也类似。
步骤1：用户使用浏览器登录第三方应用RP（Relying Part，OpenID支持方应用）客户端。
步骤2：RP客户端向统一认证OP（OpenID Provider，OpenID提供方）客户端申请登录授权码Code。
步骤3：统一认证客户端检验自身是否已经是登录状态，如果处于未登录状态，则需要用户登录统一认证客户端门户。
步骤4：用户使用相应的认证方式对统一认证客户端门户进行认证。
步骤5：统一认证客户端门户身份验证成功后，RP客户端向统一认证服务端申请授权码Code，到统一认证服务端去验证应用身份。
步骤6：统一认证服务端验证应用身份成功后，返回授权码Code给统一认证客户端。
步骤7：统一认证客户端返回授权码Code给RP客户端，RP客户端收到授权码Code后，即对RP客户端申请统一认证平台授权登录进行了授权。
步骤8：RP客户端携带AppID、Secret、授权码Code和重定向的第三方应用的URL地址向统一认证服务端申请Access_token。
步骤9：RP客户端在收到统一认证服务端返回的Access_token和OpenID后，将Access_token和OpenID传递给RP服务端并向统一认证服务端换取用户信息（也称ID_ token）。
步骤10：统一认证服务将用户信息返回给RP客户端，授权登录成功，跳转到RP客户端内部页面。
3.4.5节～3.4.8节主要介绍了当前主流的单点登录协议——CAS、SAML、OAuth、OPenID，这4种协议各有其应用场景和优缺点。各个企业在实现单点登录单点登录时，可根据实际情况选择协议。常见的单点登录协议对比表如表3-6所示。
除上面讲到的单点登录标准协议外，市面上也存在其他单点登录协议，如轻型目录访问协议（Light weight Directory Access Protocol，LDAP）、WS-Federation（WS-Fed）协议。
LDAP是基于X.500标准的轻量级目录访问协议。目录是一个为查询、浏览和搜索而优化的数据库，它成树状结构组织数据，类似文件目录。LDAP 目录服务是由目录数据库和一套访问协议组成的系统。目录数据库和关系数据库不同，有优异的读性能，但写性能很差，并且没有事务处理、回滚等复杂功能，不适用于存储修改频繁的数据。LDAP是开放的Internet标准，支持跨平台的Internet协议，在业界中得到广泛认可，并且在市场上或开源社区上的大多数产品都加入了对LDAP的支持，因此对于这类系统，不需要单独定制，只需要通过LDAP做简单的配置就可以与服务器做认证交互。LDAP用来构建统一的账号管理、身份验证平台，实现单点登录机制，只需进行简单的几步配置就可以达到LDAP的单点登录认证了。
表3-6 常见单点登录协议对比表
WS-Federation（WS-Fed）协议属于Web Services Security（WS-Security或WSS：针对Web Services安全性方面扩展的协议标准集合）的一部分，是由OASIS发布的标准协议，其主要贡献者是微软和IBM。WS-Fed 1.1版本发布于2003年，最新的1.2版本发布于2009年。该协议主要应用于企业服务，并且是在微软自己的产品中主推，其他厂家的产品可能更愿意选择SAML。另外，该标准是基于简单对象访问协议（Simple Object Access Protocol，SOAP）的，整个协议虽然功能强大，细节考虑周全，但实现起来会比较复杂，只有为了能和微软的服务整合，才会优先考虑该协议。