SSO 原理浅谈
单点登录拦截原理
单点登录拦截原理单点登录（Single Sign-On，简称SSO）拦截原理主要基于客户端/服务端架构，具体实现过程如下：1. SSO客户端拦截未登录请求：SSO客户端通过拦截未登录用户请求的方式，将用户引导至SSO认证中心进行登录操作。
Java中可以采用servlet、filter、listener三种方式拦截请求，这里我们采用filter方式。
2. SSO客户端接收并存储令牌：SSO客户端在用户登录成功后，接收并存储由SSO认证中心发送的令牌。
3. SSO客户端与SSO服务器通信：SSO客户端使用令牌与SSO服务器进行通信，校验令牌的有效性。
4. 建立局部会话：SSO客户端在验证令牌有效后，建立局部会话，以便后续对用户请求进行拦截和校验。
5. 拦截用户注销请求：SSO客户端拦截用户的注销请求，并向SSO认证中心发送注销请求。
6. 接收注销请求并销毁局部会话：SSO客户端接收SSO认证中心发出的注销请求，销毁局部会话，完成用户的注销操作。
7. SSO服务器验证用户登录信息：SSO服务器验证用户的登录信息，确保用户已成功登录。
8. 创建全局会话和授权令牌：SSO服务器创建全局会话，并生成授权令牌。
9. SSO服务器与SSO客户端通信发送令牌：SSO服务器将授权令牌发送给SSO客户端，供后续请求校验使用。
10. 校验SSO客户端令牌有效性：SSO服务器校验SSO客户端的令牌有效性，确保用户已成功登录并具有访问权限。
11. 系统注册：SSO服务器接收并存储SSO客户端的注册信息，以便后续管理。
12. 接收SSO客户端注销请求并注销所有会话：当用户选择注销时，SSO 客户端向SSO服务器发送注销请求。
SSO服务器接收请求后，注销所有与该用户相关的会话和令牌。
通过以上步骤，单点登录系统实现了对用户请求的拦截、校验和注销管理，确保了用户在多个应用系统中的单点登录和统一管理。
单点登录技术方案
单点登录技术方案介绍单点登录（SSO）是一种身份验证和授权技术，允许用户只需一次登录即可访问多个相关系统和应用程序。
这减少了用户需要记住多个用户名和密码的负担，提高了系统的易用性和安全性。
本文将介绍单点登录技术的工作原理和常见的实现方案，以及其在企业应用中的优势和挑战。
工作原理单点登录的工作原理基于令牌（Token）的概念。
当用户成功登录主认证系统后，主认证系统会生成一个令牌并将其发送给用户的浏览器。
该令牌包含了用户的身份信息和有效期限等相关信息。
当用户尝试访问其他关联系统时，这些系统会将用户重定向到主认证系统，并携带令牌作为参数。
主认证系统收到请求后，验证令牌的合法性和有效期限。
如果令牌有效，主认证系统会向关联系统发送一个授权凭证，允许用户访问特定资源。
用户的浏览器将授权凭证传递给关联系统，以完成身份验证和授权过程。
实现方案基于Cookie的实现方案基于Cookie的单点登录是最常见的实现方式之一。
主认证系统在用户成功登录后，生成一个包含用户身份信息的加密Cookie，并将其发送给浏览器。
当用户尝试访问其他关联系统时，这些系统会在用户的浏览器中查找该Cookie，并验证其合法性和有效期。
如果Cookie有效，关联系统会完成身份验证，并允许用户访问特定资源。
由于Cookie存储在用户的浏览器中，因此存在一定的安全风险。
为了增强安全性，可以使用加密和签名技术对Cookie进行保护，防止被篡改或伪造。
基于Token的实现方案基于Token的单点登录是一种无状态的实现方式。
主认证系统在用户成功登录后，生成一个包含用户身份信息的令牌，并将其发送给浏览器。
令牌通常使用JSON Web令牌（JWT）的格式进行编码，包含了用户身份信息、有效期限等相关信息。
用户在访问其他关联系统时，将令牌作为参数携带在请求中。
关联系统在接收到请求后，通过验证令牌的合法性和有效期，完成身份验证和授权过程。
基于Token的单点登录相对于基于Cookie的实现更加安全，因为令牌不存储在用户的浏览器中，且可以通过加密和签名技术进行保护。
sso登录原理
sso登录原理SSO（Single Sign-On）即单点登录，是一种允许用户使用一组凭证（例如用户名和密码）访问多个相关但独立的系统的身份验证机制。
SSO的原理是通过将用户认证信息保存在一个中央身份验证服务器上，然后在用户访问其他系统时，这些系统将向中央服务器发送身份验证请求，并根据返回的结果决定是否授权用户访问。
SSO的实现原理如下：1. 用户访问一个需要身份验证的应用程序，例如一个在线商城。
用户尚未登录，因此被重定向到身份验证服务器。
2. 身份验证服务器向用户展示一个登录页面，要求用户输入其凭证信息，例如用户名和密码。
3. 用户输入凭证信息后，身份验证服务器会验证这些凭证信息的有效性。
验证的方式可以是通过比对用户提供的凭证信息与事先存储在身份验证服务器上的用户凭证信息，或者通过与其他身份验证机制（如LDAP或Active Directory）进行通信来验证凭证信息。
4. 如果凭证信息有效，身份验证服务器将生成一个令牌（Token），该令牌包含有关用户身份的信息，并将其发送回给用户的浏览器。
5. 用户的浏览器将令牌保存在本地存储中，例如Cookie或本地存储。
6. 用户再次访问其他需要身份验证的应用程序时，浏览器将自动附加保存的令牌信息。
应用程序收到令牌后，将其发送给身份验证服务器以进行验证。
7. 身份验证服务器验证令牌的有效性，并确认该用户已通过身份验证。
如果令牌有效，身份验证服务器将向应用程序发送授权令牌，以确认用户的身份。
8. 应用程序接受授权令牌，并向用户授予访问权限。
用户可以在不需要重新输入凭证信息的情况下访问应用程序。
通过上述过程，用户只需要登录一次，就可以访问多个相关应用程序，实现了单点登录的目标。
这种机制不仅方便了用户，还提高了用户体验，并减轻了系统管理员的工作负担。
SSO的实现可以采用不同的协议和技术，常见的有基于令牌的SSO 和基于身份提供者的SSO。
基于令牌的SSO通常使用JSON Web Token（JWT）或Security Assertion Markup Language（SAML）等令牌格式来传递用户身份信息。
SSO实现方式深入浅出
SSO实现方式深入浅出SSO，单一登录（single sign-on），意思是指在多套系统并存的环境下，用户只需登录一次即可访问其他授权的系统。
提起SSO（单一登录），大概企业里的IT人员无人不知，但真正意识到其复杂度的，未必有多少，只有亲身实施过的技术人员，也许才明白个中玄妙。
本文基于蓝凌为国内几十家大中型企业的服务案例，针对SSO的相关技术和案例进行一些探讨，希望能帮助到企业IT人员更深刻理解SSO技术及其应用。
一、企业级SSOSSO涉及的领域大致上可以分为三种：社会性网站间的SSO、部门SSO、企业级SSO。
社会性网站间的SSO主要涉及的帐号信息开放性问题，能否实施成功主要取决于各大网站帐号管理是否遵循相同的标准协议，如Openid、Passport等。
部门级SSO比较简单，一般涉及的系统不多，由技术人员通过编程方式实现即可，但一旦牵涉系统众多，安全性要求高的情况，就不适用了。
企业级SSO是三者中最复杂的领域，因涉及的系统可能五花八门，这些系统也许是老旧的C/S结构系统、可能是某种大型软件系统（如SAP），还可能是某种非web登录方式（如windows域登录）；其安全性要求也远比前两者高，如要求同享登录有效时间等，因此企业级SSO在技术难度上是最高的，但也因此是IT人员最愿意钻研的领域。
而绝大部分国内企业，其内部系统常常因为历史原因导致多套系统缺乏统一规划，缺乏标准而导致整合代价高昂。
因此SSO也是许多大中型企业IT部门比较头疼的事情。
本文主要讨论的领域，就是企业级SSO。
二、深入企业级SSOSSO是一把双刃剑：SSO可以简化用户登录过程，提升用户的登录体验；同时可以降低IT管理员大量账户和密码维护成本；SSO还提供了符合萨班斯法案的密码集中管理工具；但SSO同时也产生了一种安全风险，某一系统用户身份一旦被攻破，则意味着所有参与SSO网络的应用系统也被穿透。
因此需要慎重考虑SSO的范围及安全级别的局限性。
SSO实现原理
SSO实现原理SSO实现原理图1、用户登录A系统，系统检查ticket.1.1有，提交认证中心验证，认真通过重定向A系统并返回USERNAME,A系统生成自己的Session.1.2无，提交LOGIN进行COOKIE检查，有则重定向返回A系统并TICKET，A系统生成自己的Session；无则重新登录重点：根据PORTAL服务器上的COOKIE判断用户是否登录过PORTAL, COOKIE里带有TICKET.2、其他系统重复此动作1. SSO需求单点登录（Single Sign On, SSO）是企业应用集成中最常见的需求。
异构系统间往往都有各自的用户管理和身份验证机制，为避免用户在进行系统切换时频繁输入用户名和密码，因此必须要实现单点登录。
2. SSO原理说到SSO的原理，先得说一般Web应用的身份验证原理。
Web身份验证之所以能成为问题主要在于HTTP协议的无状态性，这导致了每次HTTP的请求和响应的无关性。
而应用的状态保持是大部分应用系统的一般性需求，因此必须借助其他机制，这就是Cookie。
2.1. Cookie的原理一个Cookie由name、value、domain、path、expires组成。
可以给HTTP响应添加Cookie，然后Cookie就作为HTTP响应的Headers返回给浏览器，例如Domino的登录成功后的Cookie 响应头为：Set-Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918; path=/没有设置expires就表示仅在当前浏览器进程生命期内有效，不保存到客户机上；若expires 时间大于当前时间，则浏览器在收到这个Cookie以后将其写入到客户机文件中，一般是保存在C:\Documents and Settings\Administrator\Cookies\下。
没有设置domain就表示只在当前域内有效。
单点登录解决方案
单点登录解决方案引言随着互联网的快速发展，单点登录（Single Sign-On，SSO）已经成为各种网络应用中的常见需求。
单点登录指的是用户只需通过一次身份验证，即可在多个应用中访问和使用资源，而无需再次输入用户名和密码。
这大大提高了用户的使用体验，减轻了用户的负担。
本文将介绍单点登录的基本原理以及实现单点登录的常见解决方案。
基本原理单点登录的基本原理包括三个主要组成部分：身份提供者、服务提供者和用户。
身份提供者是负责用户身份验证和授权的服务，通常是一个独立的认证系统，如LDAP、Active Directory等。
服务提供者是各个应用系统，它们依赖于身份提供者来验证用户身份和授权。
用户是最终需要访问各个应用系统的个体。
在单点登录的过程中，当用户访问一个需要身份验证的应用系统时，该系统会将用户重定向到身份提供者进行身份验证。
一旦验证成功，身份提供者将生成一个令牌（Token），并将用户重定向回原始应用系统。
应用系统使用该令牌进行身份验证和授权，从而免除用户在每个应用系统中重复登录的繁琐过程。
解决方案1. 基于代理服务器的单点登录基于代理服务器的单点登录是一种简单且传统的解决方案。
该方案将所有应用系统的流量通过一个代理服务器进行转发，该代理服务器负责身份验证和授权。
用户在访问应用系统之前，需要先登录到代理服务器。
代理服务器通过验证用户的身份后，将用户请求转发到对应的应用系统，并将验证信息添加到请求中。
这种解决方案的优点是简单易用，无需对应用系统进行任何修改。
但是同时也存在一些限制，如需要单独设置代理服务器、影响网络性能等。
2. 基于令牌的单点登录基于令牌的单点登录方案将用户身份信息存储在令牌中，令牌在各个应用系统之间进行传递和验证。
当用户登录成功后，身份提供者会生成一个令牌，并将其返回给用户。
用户在访问其他应用系统时，将该令牌带上并提交到应用系统中进行验证。
这种解决方案的优点是实现相对较为简单，使用方便。
keycloak单点登录原理
Keycloak 单点登录原理解析什么是单点登录？单点登录（Single Sign-On，简称 SSO）是一种身份认证和授权机制，允许用户使用一组凭据（如用户名和密码）登录到多个应用程序或系统中，而不需要在每个应用程序中单独进行身份验证。
在单点登录中，用户只需要登录一次，然后可以无缝地访问其他受信任的应用程序，而无需再次输入凭据。
Keycloak 简介Keycloak 是一个开源的身份和访问管理解决方案，可以为应用程序提供单点登录、身份验证和授权服务。
Keycloak 提供了一组 RESTful API 和前端界面，可以用于管理用户、角色、资源等。
它支持 OpenID Connect、OAuth 2.0 和 SAML 等标准协议，可以与各种应用程序和身份提供商集成。
Keycloak 的单点登录原理基于 OpenID Connect 和 OAuth 2.0 协议，下面将详细介绍其基本原理。
OpenID Connect 原理OpenID Connect（简称 OIDC）是建立在 OAuth 2.0 协议之上的身份认证协议，它扩展了 OAuth 2.0，添加了身份认证的功能。
OIDC 使用 JSON Web Token（JWT）作为身份令牌，以便在不同的应用程序之间传递和验证身份信息。
下面是 OpenID Connect 的基本原理：1.用户访问客户端应用程序，并尝试进行身份验证。
2.客户端应用程序将用户重定向到 Keycloak 的身份验证服务器。
3.用户在 Keycloak 的登录页面上输入用户名和密码。
4.Keycloak 验证用户的凭据，并生成一个身份令牌（ID Token）和访问令牌（Access Token）。
5.Keycloak 将身份令牌和访问令牌返回给客户端应用程序。
6.客户端应用程序使用身份令牌和访问令牌来验证用户的身份和访问权限。
7.客户端应用程序可以通过访问令牌来访问受保护的资源服务器。
sso系统介绍-概述说明以及解释
sso系统介绍-概述说明以及解释1.引言1.1 概述部分应该对SSO系统进行简要介绍，让读者对该系统有一个初步的了解。
以下是概述的一个示例：概述单点登录（Single Sign-On，简称SSO）系统是一种身份验证和授权机制，用于简化用户在不同应用程序之间进行登录的流程。
通过SSO系统，用户只需一次登录，就可以在多个关联应用中进行访问和使用，无需重复输入用户名和密码。
SSO系统的出现是为了满足用户在当今数字化时代中面临的身份验证问题。
在传统的登录方式中，用户在每个应用程序中都需要单独进行登录，这不仅浪费时间，也容易导致繁琐的账号密码管理问题。
而SSO系统通过集成不同应用程序的登录认证，为用户提供了一种便捷、高效的身份验证机制。
相较于传统的登录方式，SSO系统具有许多优势。
首先，用户只需记住一个统一的登录凭证，大大减轻了用户的记忆负担。
其次，SSO系统可以提供更高的安全性，通过集成多种身份验证措施和安全策略，确保用户的身份和数据得到有效保护。
此外，SSO系统还能提高用户的使用便捷性和体验，让用户可以方便地在不同应用中切换和共享数据。
在SSO系统中，存在一个身份提供者（Identity Provider，简称IdP）和一个或多个服务提供者（Service Provider，简称SP）。
用户首先在身份提供者上进行登录认证，成功后，便可以在多个服务提供者上访问相应的资源和功能。
SSO系统通过在应用程序之间传递身份凭证实现用户的无缝登录。
总而言之，SSO系统解决了多应用登录的繁琐问题，提供了一种高效便捷的身份验证机制，为用户提供了更好的使用体验和安全保障。
在接下来的章节中，本文将深入探讨SSO系统的定义和工作原理，以帮助读者全面了解这一身份管理解决方案。
1.2 文章结构文章结构:本文将从以下几个部分来介绍SSO系统。
首先，我们会在引言部分对SSO系统进行概述，包括它的基本概念和作用。
其次，我们将详细讲解文章的结构，以便读者能清晰地了解后续内容的组织方式。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SSO 原理浅谈SSO 是一个非常大的主题，我对这个主题有着深深的感受，自从广州UserGroup 的论坛成立以来，无数网友都在尝试使用开源的CAS ，Kerberos 也提供另外一种方式的SSO ，即基于Windows 域的SSO ，还有就是从2005 年开始一直兴旺不衰的SAML 。
如果将这些免费的SSO 解决方案与商业的Tivoli 或Siteminder 或RSA Secure SSO 产品做对比，差距是存在的。
毕竟，商业产品的安全性和用户体验都是无与伦比的，我们现在提到的SSO ，仅仅是Web SSO ，即Web-SSO 是体现在客户端；另外一种SSO 是桌面SSO ，例如，只需要作为Administrator 登录一次windows 2000 ，我便能够在使用MSN/QQ 的时候免去登录的环节( 注意，这不是用客户端软件的密码记忆功能) ，是一种代理用户输入密码的功能。
因此，桌面SSO 是体现在OS 级别上。
今天，当我们提起SSO 的时候，我们通常是指Web SSO ，它的主要特点是，SSO 应用之间走Web 协议( 如HTTP/SSL) ，并且SSO 都只有一个登录入口。
简单的SSO 的体系中，会有下面三种角色：1 ，User （多个）2 ，Web 应用（多个）3 ，SSO 认证中心（1 个）虽然SSO 实现模式千奇百怪，但万变不离其宗：l Web 应用不处理User 的登录，否则就是多点登陆了，所有的登录都在SSO 认证中心进行。
l SSO 认证中心通过一些方法来告诉Web 应用当前访问用户究竟是不是张三/ 李四。
l SSO 认证中心和所有的Web 应用建立一种信任关系，SSO 认证中心对用户身份正确性的判断会通过某种方法告之Web 应用，而且判断结果必须被Web 应用信任。
2. CAS 的基本原理CAS(Central Authentication Service) 是Yale 大学发起的一个开源项目，据统计，大概每10 个采用开源构建Web SSO 的Java 项目，就有8 个使用CAS 。
对这些统计，我虽然不以为然，但有一点可以肯定的是，CAS 是我认为最简单实效，而且足够安全的SSO 选择。
本节主要分析CAS 的安全性，以及为什么CAS 被这样设计，带着少许密码学的基础知识，我希望有助于读者对CAS 的协议有更深层次的理解。
2.1 CAS 的结构体系从结构体系看，CAS 包含两部分：l CAS ServerCAS Server 负责完成对用户的认证工作，CAS Server 需要独立部署，有不止一种CAS Server 的实现，Yale CAS Server 和ESUP CAS Server 都是很不错的选择。
CAS Server 会处理用户名/ 密码等凭证(Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在XML 文件中检索用户密码，对这种方式，CAS 均提供一种灵活但同一的接口/ 实现分离的方式，CAS 究竟是用何种认证方式，跟CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
l CAS ClientCAS Client 负责部署在客户端（注意，我是指Web 应用），原则上，CAS Client 的部署意味着，当有对本地Web 应用的受保护资源的访问请求，并且需要对请求方进行身份认证，Web 应用不再接受任何的用户名密码等类似的Credentials ，而是重定向到CAS Server 进行认证。
目前，CAS Client 支持（某些在完善中）非常多的客户端，包括Java 、 .Net 、ISAPI 、Php 、Perl 、uPortal 、Acegi 、Ruby 、VBScript 等客户端，几乎可以这样说，CAS 协议能够适合任何语言编写的客户端应用。
2.2 CAS 协议剖析协议就像剖析设计模式，有些时候，协议让人摸不着头脑。
CAS 的代理模式要相对复杂一些，它引入了一些新的概念，我希望能够在这里描述一下其原理，有助于读者在配置和调试CAS SSO 有更清晰的思路。
如果没记错，CAS 协议应该是由Drew Mazurek负责可开发的，从CAS v1 到现在的CAS v3 ，整个协议的基础思想都是基于Kerberos 的票据方式。
CAS v1 非常原始，传送一个用户名居然是”yes\ndavid.turing” 的方式，CAS v2 开始使用了XML 规范，大大增强了可扩展性，CAS v3 开始使用AOP 技术，让Spring 爱好者可以轻松配置CAS Server 到现有的应用环境中。
CAS 是通过TGT(Ticket Granting Ticket) 来获取ST(Service Ticket) ，通过ST 来访问服务，而CAS 也有对应TGT ，ST 的实体，而且他们在保护TGT 的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。
下面，我们看看CAS 的基本协议框架：2.1.1 基础协议CAS 基础模式上图是一个最基础的CAS 协议，CAS Client 以Filter 方式保护Web 应用的受保护资源，过滤从客户端过来的每一个Web 请求，同时，CAS Client 会分析HTTP 请求中是否包请求Service Ticket( 上图中的Ticket) ，如果没有，则说明该用户是没有经过认证的，于是，CAS Client 会重定向用户请求到CAS Server （Step 2 ）。
Step 3 是用户认证过程，如果用户提供了正确的Credentials ，CAS Server 会产生一个随机的ServiceTicket ，然后，缓存该Ticket ，并且重定向用户到CAS Client （附带刚才产生的Service Ticket ），Service Ticket 是不可以伪造的，最后，Step 5 和Step6 是CAS Client 和CAS Server 之间完成了一个对用户的身份核实，用Ticket 查到Username ，因为Ticket 是CAS Server 产生的，因此，所以CAS Server 的判断是毋庸置疑的。
该协议完成了一个很简单的任务，就是User(david.turing) 打开IE ，直接访问helloservice 应用，它被立即重定向到CAS Server 进行认证，User 可能感觉到浏览器在helloservcie 和casserver 之间重定向，但User 是看不到，CAS Client 和CAS Server 相互间的Service Ticket 核实(Validation) 过程。
当CAS Server 告知CAS Client 用户Service Ticket 对应确凿身份，CAS Client 才会对当前Request 的用户进行服务。
2.2.2 CAS 如何实现SSO当我们的Web 时代还处于初级阶段的时候，SSO 是通过共享cookies 来实现，比如，下面三个域名要做SSO ：如果通过CAS 来集成这三个应用，那么，这三个域名都要做一些域名映射，因为是同一个域，所以每个站点都能够共享基于 的cookies 。
这种方法原始，不灵活而且有不少安全隐患，已经被抛弃了。
CAS 可以很简单的实现跨域的SSO ，因为，单点被控制在CAS Server ，用户最有价值的TGC-Cookie 只是跟CAS Server 相关，CAS Server 就只有一个，因此，解决了cookies 不能跨域的问题。
回到CAS 的基础协议图，当Step3 完成之后，CAS Server 会向User 发送一个Ticket granting cookie (TGC) 给User 的浏览器，这个Cookie 就类似Kerberos 的TGT ，下次当用户被Helloservice2 重定向到CAS Server 的时候，CAS Server 会主动Get 到这个TGC cookie ，然后做下面的事情：1，如果User 的持有TGC 且其还没失效，那么就走基础协议图的Step4 ，达到了SSO 的效果。
2，如果TGC 失效，那么用户还是要重新认证( 走基础协议图的Step3) 。
2.2.2 CAS 的代理模式模式1 已经能够满足大部分简单的SSO 应用，现在，我们探讨一种更复杂的情况，即用户访问helloservice ，helloservice 又依赖于helloservice2 来获取一些信息，如同：User à helloservice à helloservice2这种情况下，假设helloservice2 也是需要对User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致User 的IE 窗口不停地闪动) ，CAS 引入了一种Proxy 认证机制，即CAS Client 可以代理用户去访问其它Web 应用。
代理的前提是需要CAS Client 拥有用户的身份信息( 类似凭据) 。
与其说之前我们提到的TGC 是用户持有对自己身份信息的一种凭据，则这里的PGT 就是CAS Client 端持有的对用户身份信息的一种凭据。
凭借TGC ，User 可以免去输入密码以获取访问其它服务的Service Ticket ，所以，这里，凭借PGT ，Web 应用可以代理用户去实现后端的认证，而无需前端用户的参与。
如下面的CAS Proxy 图所示，CAS Client 在基础协议之上，提供了一个额外的PGT URL 给CAS Server, 于是，CAS Server 可以通过PGT URL 提供一个PGT 给CAS Client 。
初学者可能会对上图的PGT URL 感到迷惑，或者会问，为什么要这么麻烦，要通过一个额外的URL( 而且是SSL 的入口) 去传递PGT ？如果直接在Step 6 返回，则连用来做对应关系的PGTIOU 都可以省掉。
PGTIOU 设计是从安全性考虑的，非常必要，CAS 协议安全性问题我会在后面一节介绍。
于是，CAS Client 拿到了PGT( PGTIOU-85…..ti2td ) ，这个PGT 跟TGC 同样地关键，CAS Client 可以通过PGT 向后端Web 应用进行认证。
如下图所示，Proxy 认证与普通的认证其实差别不大，Step1, 2 与基础模式的Step 1,2 几乎一样，唯一不同的是，Proxy 模式用的是PGT 而不是TGC ，是Proxy Ticket （PT ）而不是Service Ticket 。
最终的结果是，helloservice2 明白helloservice 所代理的客户是David. Turing 同学，同时，根据本地策略，helloservice2 有义务为PGTURL=http://helloservice/proxy 服务(PGTURL 用于表示一个Proxy 服务) ，于是它传递数据给helloservice 。