SSO解决方案和技术路线
SSO单点登录解决方案
SSO单点登录解决方案单点登录（SSO）是一种身份验证授权机制，允许用户在多个互联网应用程序和网站之间共享一个单一的登录凭据。
它通过一次认证，使用户能够在各个应用程序中访问受保护的资源，无需再次输入登录凭据。
以下是一个详细介绍SSO单点登录解决方案的文章，超过1200字。
引言：在现代的互联网时代，用户常常需要在多个应用程序和网站上进行登录。
这不仅使用户要记住多个不同的账号和密码，而且给用户带来了繁琐和不便。
为了解决这个问题，单点登录（SSO）技术应运而生。
什么是单点登录？单点登录（SSO）是一种身份验证和授权机制，允许用户一次登录凭据在多个应用程序和网站之间进行身份验证。
用户只需在一个应用程序上进行登录，便可以自由访问所有与之关联的应用程序，而无需再次输入登录凭据。
SSO解决方案的优点：1.提高用户体验：用户只需记住一个登录凭据，即可随意访问所有与之关联的应用程序，大大简化了用户的登录流程，提高了用户的便利性和满意度。
2.提高安全性：通过使用SSO解决方案，用户的登录凭据只需在一个可信的认证系统中验证，而不需要在每个应用程序中都输入凭据。
这减少了密码暴露的风险，并提高了系统的整体安全性。
3.简化管理：通过使用SSO解决方案，管理员可以轻松地管理应用程序和用户，而无需在每个应用程序中都进行独立的帐户管理。
减少了管理员的工作量，提高了管理效率。
4.降低成本：使用SSO解决方案可以减少密码重置和帐户管理等常见问题的费用。
此外，SSO解决方案还可以帮助组织简化其IT基础设施，减少硬件和软件的购买和维护成本。
SSO解决方案的实现方式：1.基于令牌的SSO：这种解决方案使用令牌来实现单点登录。
用户在登录到第一个应用程序时，会向认证服务器发送他们的凭据。
认证服务器会验证凭据的有效性，并生成一个令牌，并将该令牌返回给用户。
用户随后可以在其他应用程序上使用该令牌进行登录。
2.基于代理的SSO：这种解决方案使用代理服务器来实现单点登录。
统一认证单点登录系统SSO解决方案
统一认证单点登录系统SSO解决方案单点登录（SSO）是一种身份认证技术，允许用户通过一次登录，获得访问多个相关系统的权限，而无需重新输入登录凭证。
统一认证单点登录系统(SSO)解决方案是一种集成和授权机制，为用户提供单一的身份验证机制，使其能够快速、方便地访问各种不同的应用程序和系统。
在传统的登录方式中，用户通常需要为每个应用程序和系统拥有一个独立的账号，并需要输入每个应用程序或系统的登录凭证。
这对于用户来说非常繁琐，也容易导致账号和密码的管理困难。
单点登录解决方案通过集成和授权机制，解决了这个问题，并为用户提供了一种更便捷和高效的身份验证方式。
1. 身份提供者（Identity Provider，IdP）：身份提供者是SSO系统的核心组件，负责用户身份的认证和授权。
用户通过身份提供者进行登录，并获得生成和管理身份凭证的权限。
2. 服务提供者（Service Provider，SP）：服务提供者是SSO系统中的应用程序或系统，它依赖于身份提供者来验证和授权用户的身份。
用户只需在身份提供者处登录一次，即可无需重新输入登录凭证，访问多个服务提供者。
3. 身份凭证（Credentials）：身份凭证是由身份提供者生成，以验证用户身份的信息。
它可以是用户名和密码的组合，也可以是使用其他身份验证方式生成的令牌或证书。
4. 单点登录协议：单点登录解决方案使用不同的协议来实现身份验证和授权。
常见的协议包括SAML（Security Assertion MarkupLanguage）、OpenID Connect、OAuth等。
这些协议定义了身份提供者和服务提供者之间的通信规范，以确保安全可靠地传输身份凭证和用户信息。
单点登录解决方案的具体实现步骤如下：1.用户访问服务提供者（SP）应用程序，并被要求进行身份验证。
2.SP应用程序将用户重定向到身份提供者（IdP）登录页面。
3.用户在IdP登录页面上输入其凭据（用户名和密码）。
SSO单点登录解决方案
1 什么是单点登陆单点登录（Single Sign On），简称为SSO，是目前比较流行的企业业务整合的解决方案之一。
SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和IT服务。
例如财务系统为财务人员提供财务的管理、计算和报表服务；人事系统为人事部门提供全公司人员的维护服务；各种业务系统为公司内部不同的业务提供不同的服务等等。
这些系统的目的都是让计算机来进行复杂繁琐的计算工作，来替代人力的手工劳动，提高工作效率和质量。
这些不同的系统往往是在不同的时期建设起来的，运行在不同的平台上；也许是由不同厂商开发，使用了各种不同的技术和标准。
如果举例说国内一著名的IT公司（名字隐去），内部共有60多个业务系统，这些系统包括两个不同版本的SAP的ERP系统，12个不同类型和版本的数据库系统，8个不同类型和版本的操作系统，以及使用了3种不同的防火墙技术，还有数十种互相不能兼容的协议和标准，你相信吗？不要怀疑，这种情况其实非常普遍。
每一个应用系统在运行了数年以后，都会成为不可替换的企业IT架构的一部分，如下图所示。
随着企业的发展，业务系统的数量在不断的增加，老的系统却不能轻易的替换，这会带来很多的开销。
其一是管理上的开销，需要维护的系统越来越多。
很多系统的数据是相互冗余和重复的，数据的不一致性会给管理工作带来很大的压力。
业务和业务之间的相关性也越来越大，例如公司的计费系统和财务系统，财务系统和人事系统之间都不可避免的有着密切的关系。
为了降低管理的消耗，最大限度的重用已有投资的系统，很多企业都在进行着企业应用集成（EAI）。
企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。
事实上，还用一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。
SSO单点登录解决方案
SSO单点登录解决方案SSO（Single Sign-On）单点登录是一种身份验证技术，允许用户使用单个身份凭证（如用户名和密码）登录到多个应用程序或系统中。
这种技术的目标是提供一种方便的方式，让用户无需多次输入身份凭证，即可访问多个应用程序。
1.基于代理的单点登录解决方案：这种解决方案使用代理服务器作为中间人来处理用户的身份验证请求。
当用户尝试登录到一个应用程序时，代理服务器会验证其身份，并在成功验证后将用户重定向到目标应用程序。
代理服务器还负责维护用户的会话状态，以确保用户可以无缝地访问其他应用程序。
一些常见的代理服务器解决方案包括CAS（Central Authentication Service）、OpenAM和Shibboleth。
2.基于令牌的单点登录解决方案：这种解决方案使用令牌来验证用户的身份。
当用户登录到一个应用程序时，该应用程序会生成一个令牌，并将其发送给身份提供者进行验证。
身份提供者验证令牌的有效性后，将用户信息返回给应用程序，以便应用程序可以授权用户访问。
一些常见的基于令牌的单点登录解决方案包括OAuth和OpenID Connect。
3.基于集中式用户存储的单点登录解决方案：这种解决方案使用集中式用户存储来管理用户的身份凭证。
当用户尝试登录到一个应用程序时，应用程序会将用户的身份验证请求发送到集中式用户存储进行验证。
如果验证成功，集中式用户存储会向应用程序发送一个授权令牌，以便应用程序可以授权用户访问。
一些常见的基于集中式用户存储的单点登录解决方案包括LDAP（Lightweight Directory Access Protocol）和Active Directory。
为了实现SSO单点登录，企业需要执行以下步骤：1. 集中用户管理：将所有系统和应用程序的用户信息集中到一个用户存储中，例如LDAP或Active Directory。
这样可以简化用户管理，并确保所有系统都可以访问到最新的用户信息。
平台SSO(单点登陆)技术方案
第三方业务系统单点登陆技术方案1概述单点登录简单说，就是通过用户的一次性鉴别登录，即可获得需访问系统和应用软件的授权，在此条件下，管理员无需修改或干涉用户登录就能方便的实施希望得到的安全控制。
2背景平台负责把各种应用、服务、业务集成，对它们系统的用户信息进行统一管理。
只要在平台登录的用户，都可以得到一个由平台颁发的虚拟令牌，这样便可轻松的来回其它不同业务，对所有被授权的网络资源进行无缝访问了。
这不仅了提高网络用户的工作效率，降低网络操作的费用，还提高了网络的安全性。
3解决方案1、工作流程：2、流程描述(一)登录Portal1)用户向Portal请求登陆。
2)Portal获取用户名和密码后，向AAA请求认证。
3)AAA查询用户名、密码，确认用户存在。
4)AAA生成token加密串，和有效时间（当前时间+默认配置时间），保存token。
5)并把token返回给Portal。
6)Portal创建用户会话，并保存token，返回首页。
(二)访问第三方业务1)当用户在Potal上点击一个业务链接时，系统会访问第三方业务系统，并把当前用户的token和AAA入口地址时作为请求参数带上。
2)第三方业务系统带上token参数，请求AAA认证身份。
3)AAA认证身份通过后并通知第三方业务系统。
4)第三方业务系统建立用户会话，并保存token。
5)系统跳转到第三方业务系统可操作界面。
6)在第三方业务系统中，操作内部服务，仅仅验证用户会话。
(三)从第三方业务系统返回Portal1)在第三方业务系统中，Portal的首页的URL应该为：portal_URL+AAA_URL+token。
2)点击Poratl首页，Portal先验证用户会话是否有效，如果有效，返回首页；否则向AAA请求验证token，验证通过后，Portal重新建立用户会话，并保存token。
3、重点说明1)在系统内部操作时，验证用户会话。
2)当跳转到其他业务系统时(系统切换)，传递token参数。
sso 解决方案
SSO 解决方案简介单点登录（Single Sign-On，SSO）是一种身份认证技术，允许用户只需登录一次即可访问多个互联网应用。
SSO 解决方案旨在简化用户的身份验证过程，提供便利和安全性。
本文将介绍什么是 SSO 解决方案，为什么企业需要它，以及如何实施 SSO 解决方案。
什么是 SSO 解决方案SSO 解决方案是一种集中式的身份认证技术，用户只需在一个认证中心登录一次，即可访问多个互联网应用。
这意味着用户只需记住一个用户名和密码，就可以无缝访问多个应用，提高了用户体验和工作效率。
SSO 解决方案通常包含以下组件：1.认证中心（Identity Provider，IdP）：负责用户的身份验证和认证，维护用户的登录状态。
它与所有需要身份验证的应用程序进行通信，以生成令牌并授权用户的访问请求。
2.服务提供者（Service Provider，SP）：是安全资源的拥有者，依赖于认证中心来验证用户的身份。
当用户尝试访问某个应用程序时，服务提供者会将用户重定向到认证中心，以进行身份认证。
3.用户存储（User Store）：存储用户的身份信息和凭据，例如用户名和密码等。
为什么企业需要 SSO 解决方案SSO 解决方案为企业带来了多种好处：1.提高用户体验：用户只需记住一个用户名和密码，就可以访问多个应用程序，省去了频繁输入用户名和密码的麻烦。
2.增强安全性：SSO 解决方案可以集中管理用户的身份认证和访问权限，减少人为错误和安全漏洞的风险。
企业可以更好地控制用户的访问权限，对敏感数据进行更好的保护。
3.提高工作效率：员工无需反复登录不同的应用程序，可以更快地完成工作任务。
此外，企业还可以通过集成员工的权限和角色，自动化访问控制和授权过程，提高工作效率。
实施 SSO 解决方案实施 SSO 解决方案需要经过以下几个步骤：1. 确定业务需求在实施 SSO 解决方案之前，企业需要明确其业务需求和目标。
例如，企业需要提供给员工、供应商和合作伙伴的应用程序类型和数量，以及对用户访问的安全要求。
单点登录(SSO)_统一身份认证解决方案
工作时，您需要访问公司的多个业务系统，不同的用户名和密码，频繁的登录和切换，简易密码易遭盗用，复杂密码难以记忆。
您是否遭遇过因遗忘密码耽误工作，甚至丢失密码造成泄密……？如果您正巧是IT 系统管理者，维护公司各业务系统中庞大的、不断变化的用户信息，则足以让您精疲力尽。
关系管理系统等。
传统方式下，各业务系统分别为员工创建帐号和密码，拥有各自独立的用户信息；相对应的，每位员工则必须记住多个用户名和密码以访问不同的应用。
问题随之而来：1.用户使用不便。
用户必须设法记住若干个用户名和密码，并在登录每个业务系统时使用，要访问其他系统的资源则必须进行频繁的切换。
2.管理维护复杂。
It 部门需单独维护每套业务系统的用户身份和存取管理，每一次用户情况发生变化都必须逐一在各个业务系统中修改用户信息，分配角色权限，任务繁重且容易出错。
3.安全隐患严重。
造成极大的安全隐患。
由于维护工作头绪繁杂，管理员极有可能疏忽了在某业务系统中禁用离职员工的帐号，造成相应的商业信息被非法访问。
按照业务流程，新进员工会在人力资源中注册，注册员工帐户会自动在活动目录（AD ）中创建，并根据授权自动在其他业务系统中生成，用户信息统一从人力资源系统自动同步。
功能和特性东谷单点登录（SSO ）系统是一套企业级综合身份管理解决方案，帮助企业轻松应对上述难题，主要实现以下功能：1.统一用户管理（UUMS ）东谷SSO 系统中的统一用户管2.组织结构同步上规模的企业都拥有比较复杂的组织结构。
如果组织结构不能自动同步到其他系统，则维护工作将十分繁重。
在AD中，员工调动不仅是组织单位（OU）变动的问题，还涉及用户所属的部门安全组成员变动。
东谷SSO系统改进了AD的安全维护，充分为IT管理人员着想，实现组织结构自动与AD同步，并且自动调整安全组中的人员。
3.密码同步东谷SSO系统支持单点/多点密码修改。
单点密码修改实现起来比较简单，但一般要求用户改变自己修改密码的习惯。
sso方案
sso方案SSO方案引言单点登录（Single Sign-On，简称SSO）是一种身份认证和授权的解决方案，允许用户在进行多个应用程序之间进行无缝的访问。
它的目标是通过使用一组凭据，例如用户名和密码，使用户可以一次登录即可访问多个应用程序。
本文将探讨单点登录的原理、优势以及如何实施一个SSO方案。
单点登录的原理和工作流程原理单点登录允许用户使用一组凭证登录到一个主要的身份提供者，然后再将这些凭证传递给其他相关的应用程序。
该身份提供者负责验证用户的身份，并提供一个令牌，用于作为凭证传递给其他应用程序。
工作流程1. 用户打开一个应用程序，并尝试进行登录。
2. 应用程序检测到用户未经身份验证，将用户重定向到身份提供者的登录页面。
3. 用户输入凭证并提交给身份提供者。
4. 身份提供者验证凭证，并为用户颁发一个令牌。
5. 身份提供者将令牌返回给应用程序。
6. 应用程序使用该令牌进行用户身份验证，并为用户授权访问。
7. 用户在其他相关应用程序上访问时，不需要重新登录，令牌将作为凭证传递给这些应用程序。
SSO的优势简化用户体验SSO方案通过一次登录即可访问多个应用程序，大大简化了用户登录和身份验证的流程。
用户无需为每个应用程序都记住不同的用户名和密码，只需要一次性登录即可。
提高安全性SSO方案使用标准的身份验证协议和加密算法，确保用户的凭证在传输过程中是安全的。
此外，由于用户只需登录一次，减少了输入密码的次数，降低了密码被攻击的风险。
降低开发和维护成本SSO方案可以减少多个应用程序中进行身份验证和授权的代码和逻辑。
这意味着开发人员可以专注于其他核心功能，提高了开发效率；同时，维护一个单独的身份提供者要比每个应用程序中都进行身份验证更简单和易于管理。
实施一个SSO方案的步骤步骤一：选择合适的身份提供者选择一个可靠和受信任的身份提供者非常重要。
身份提供者需要具备以下特点：- 提供标准的身份验证协议，如SAML或OAuth等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CAS配置手册1SSO原理浅谈SSO 是一个非常大的主题，无数网友都在尝试使用开源的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 实现模式千奇百怪，但万变不离其宗：Web 应用不处理 User 的登录，否则就是多点登陆了，所有的登录都在SSO 认证中心进行。
SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是张三/李四。
SSO认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确性的判断会通过某种方法告之Web应用，而且判断结果必须被Web应用信任。
2CAS基本原理CAS(Central Authentication Service)是Yale大学发起的一个开源项目，据统计，大概每10个采用开源构建Web SSO的Java项目，就有8个使用CAS 。
对这些统计，我虽然不以为然，但有一点可以肯定的是，CAS是我认为最简单实效，而且足够安全的SSO选择。
本节主要分析 CAS 的安全性，以及为什么 CAS 被这样设计，带着少许密码学的基础知识，我希望有助于读者对 CAS 的协议有更深层次的理解。
2.1 CAS的结构体系从结构体系看， CAS 包含两部分：CAS ServerCAS Server负责完成对用户的认证工作，CAS Server需要独立部署，有不止一种CAS Server的实现，Yale CAS Server和ESUP CAS Server都是很不错的选择。
CAS Server会处理用户名/密码等凭证(Credentials)，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式，CAS均提供一种灵活但同一的接口/实现分离的方式，CAS究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
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.2.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 会产生一个随机的Service Ticket，然后，缓存该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.2CAS如何实现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.3CAS的代理模式模式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。
这样，helloservice便完成一个代理者的角色，协助User返回他想要的数据。
代理认证模式非常有用，它也是CAS协议v2的一个最大的变化，这种模式非常适合在复杂的业务领域中应用SSO。