D盘

补充阅读：

“RADIUS”在英汉词典中的解释(来源:百度词典)：

radius
KK: []
DJ: []

n.

1. 半径;半径距离;半径范围[C][the S][(+of)]

2. 周围,范围[the S][(+of)]

3. 辐射状部分;(车轮的)辐条[C]

4. 【解】桡骨[C]

5. 【动】径骨[C]

6. 【昆】径脉[C]

查看例句

关键词： 协议 原理 实现 cas

CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目，据统计，大概每 10 个采用开源构建 Web SSO 的 Java 项目，就有 8 个使用 CAS 。对这些统计，我虽然不以为然，但有一点可以肯定的是， CAS 是我认为最简单实效，而且足够安全的 SSO 选择。
       本节主要分析 CAS 的安全性，以及为什么 CAS 被这样设计，带着少许密码学的基础知识，我希望有助于读者对 CAS 的协议有更深层次的理解。
从结构体系看， CAS 包含两部分：
l         CAS Server
CAS Server 负责完成对用户的认证工作， CAS Server 需要独立部署，有不止一种 CAS Server 的实现， Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。
CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式， CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
l         CAS Client
CAS Client 负责部署在客户端（注意，我是指 Web 应用），原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。
目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客户端，几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。
 剖析协议就像剖析设计模式，有些时候，协议让人摸不着头脑。 CAS 的代理模式要相对复杂一些，它引入了一些新的概念，我希望能够在这里描述一下其原理，有助于读者在配置和调试 CAS SSO 有更清晰的思路。
如果没记错， CAS 协议应该是由 Drew Mazurek 负责可开发的，从 CAS v1 到现在的 CAS v3 ，整个协议的基础思想都是基于 Kerberos 的票据方式。
       CAS v1 非常原始，传送一个用户名居然是 ”yes david.turing” 的方式， CAS v2 开始使用了 XML 规范，大大增强了可扩展性， CAS v3 开始使用 AOP 技术，让 Spring 爱好者可以轻松配置 CAS Server 到现有的应用环境中。
CAS 是通过 TGT(Ticket Granting Ticket) 来获取 ST(Service Ticket) ，通过 ST 来访问服务，而 CAS 也有对应 TGT ， ST 的实体，而且他们在保护 TGT 的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。
       下面，我们看看 CAS 的基本协议框架：
基础协议

                                                 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 的用户进行服务。
CAS 如何实现 SSO
       当我们的 Web 时代还处于初级阶段的时候， SSO 是通过共享 cookies 来实现，比如，下面三个域名要做 SSO ：
http://www.blogjava.net
http://www.matrix.org.cn
http://www.csdn.net
如果通过 CAS 来集成这三个应用，那么，这三个域名都要做一些域名映射，
http://blogjava.cas.org
http://matrix.cas.org
http://csdn.cas.org
因为是同一个域，所以每个站点都能够共享基于 cas.org 的 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) 。
 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 。这样， helloservice 便完成一个代理者的角色，协助 User 返回他想要的数据。


   代理认证模式非常有用，它也是 CAS 协议 v2 的一个最大的变化，这种模式非常适合在复杂的业务领域中应用 SSO 。因为，以前我们实施 SSO 的时候，都是假定以 IE User 为 SSO 的访问者，忽视了业务系统作为 SSO 的访问者角色。

　　银行、证券、保险、大型企业等敏感部门会面临更多的风险。黑客技术的公开化和组织化，以及网络应用的开放性也使得网络受到攻击的威胁越来越大，而我们对这一问题严重性的认识和所具备的应付能力还远远不够。

　　通常对密码管理是网络安全其中最大的安全因素。网络上众多的网络设备、服务器主机、办公环境中财务系统、OA系统、ERP系统等应用。每个应用都需要静态的密码保护，一般管理人员不强制使用强口令和定期修改密码的规定，使得使用者会选择一些弱口令（如：123456）并且在各个应用系统跟管理主机上使用同一个静态的密码。当密码一旦被黑客得到，可能造成的巨大的损失。由此，早在90年代就推出双因素动态密码身份认证解决现行静态密码的不安全因素。

双因素身份认证介绍

　　简单来说，双因素身份认证跟大家用的ATM银行卡相类似。初期管理员会给每个密码使用者分派一个动态口令卡，只有你在同时拥有这个动态口令卡与解开这个动态口令卡的密码才能生成一个一次性的动态密码让用户登陆各种应用系统。

动态口令令牌

　　由于动态口令卡脱离虚拟网络，保障每次密码生成过程不会被黑客截取，而且每次都变化的动态密码保障登陆系统的认证强度足以抵抗黑客的木马或病毒不能通过监控使用者的主机而得到登陆应用的权限。

双因素身份认证类型简介

　　现行动态口令一般分为两种：事件同步，时间同步。另外还有一种是更高级的挑战应答模式。

时间同步：

　　基于令牌和服务器的时间同步，通过运算来生成一致的动态口令，基于时间同步的令牌，一般更新率为60s，每60s产生一个新口令，但由于其同步的基础是国际标准时间，则要求其服务器能够十分精确的保持正确的时钟，同时对其令牌的晶振频率有严格的要求，从而降低系统失去同步的几率。从另一方面，基于时间同步的令牌在每次进行认证时，服务器端将会检测令牌的时钟偏移量，相应不断的微调自己的时间记录，从而保证了令牌和服务器的同步，确保日常的使用。故对于时间同步的设备的系统时钟进行保护是十分必要的，特别对于软件令牌，由于其依赖的是用户终端PC机或移动电脑的系统时钟，当令牌数量分散，且终端属于多个不可控网络系统时，保证众多的终端同认证服务器的时钟同步是十分重要的。同样，对于基于时间同步的一台或多台服务器，应严格地保护其系统时钟，不得随意更改，以免发生同步问题，从而影响全部基于此服务器进行认证的令牌。对于失去时间同步的令牌，目前可以通过增大偏移量的技术（前后10分钟）来进行远程同步，确保其能够继续使用，降低对应用的影响，但对于超出默认值（共20分钟）的时间同步令牌，将无法继续使用或进行远程同步，必须由系统管理员在服务器端另行处理。

事件同步：

　　基于事件同步的令牌，其原理是通过某一特定的事件次序及相同的种子值作为输入，在算法中运算出一致的密码，其运算机理决定了其整个工作流程同时钟无关，不受时钟的影响，令牌中不存在时间脉冲晶振，但由于其算法的一致性，其口令是预先可知的，通过令牌，你可以预先知道今后的多个密码，故当令牌遗失且没有使用PIN码对令牌进行保护时，存在非法登陆的风险，故使用事件同步的令牌，对PIN码的保护是十分必要的。同样，基于事件同步的令牌同样存在失去同步的风险，例如用户多次无目的的生成口令等，对于令牌的失步，事件同步的服务器使用增大偏移量的方式进行再同步，其服务器端会自动向后推算一定次数的密码，来同步令牌和服务器，当失步情况经非常严重，大范围超出正常范围时，通过连续输入两次令牌计算出的密码，服务器将在较大的范围内进行令牌同步，一般情况下，令牌同步所需的次数不会超过3次。但在极端情况下，不排出失去同步的可能性，例如电力耗尽，在更换电池时操作失误等。此时，令牌仍可通过手工输入由管理员生成的一组序列值来实现远程同步，而无需返回服务器端重新同步。

挑战应答：

　　对于异步令牌，由于在令牌和服务器之间除相同的算法外没有需要进行同步的条件，故能够有效的解决令牌失步的问题，降低对应用的影响，同时极大的增加了系统的可靠性。异步口令使用的缺点主要是在使用时，用户需多一个输入挑战值的步骤，对于操作人员，增加了复杂度，故在应用时，将根据用户应用的敏感程度和对安全的要求程度来选择密码的生成方式。

双因素典型应用

1） VPN系统和网络系统设备管理的身份认证

　　网络管理员可以通过Telnet方式连接到网络设备时，输入用户名后，系统将在登录窗口要求用户输入动态口令，用户打开自己的动态口令牌，生成动态一次性口令作为登陆网络设备的密码。网络设备使用Radius通用协议到双因素身份认证服务器请求该用户当次密码是否能授权该用户进入网络设备，双因素身份认证服务器返回认证结果给网络设备。

　　同理VPN登录用户打开的VPN Client，在登录界面输入用户名，并用自己的动态口令令牌生成一个一次性的口令，作为密码填写在登录窗口中，进行登录即可。

2） Windows 域用户认证

　　双因素对Windows的保护原理是通过在Windows域控制器上安装双因素身份认证Agent，然后在Windows工作站上安装双因素身份认证 Domain Plug-in。用户在登录Windows域时，必须同时提供Windows域的用户名、密码以及动态口令牌生成的动态口令登录，从而保证系统的安全性。动态口令通过动态身份认证系统特有的EASSP认证协议，由安装在DC上的Agent转发到认证服务器进行认证。认证系统中的访问控制列表可以对用户的访问进行精确的控制，日志系统可以对用户访问进行详细的记录。

　　以上是小编所知道的某些典型应用。在资料上得知，双因素身份认证还保护Unix和Linux主机、Web登陆的认证等典型应用。而且还提供相应的SDK包让核心应用系统（OA、ERP、财务系统）能够根据开发包开发使用动态密码登陆认证模式。