SSO项目介绍.doc

SSO（Single Sign-On，单点登录）一，SSO技术简介：SSO（Single Sign-On，单点登录）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证二，SSO的优势使用SSO的好处主要有：(1)方便用户用户使用应用系统时，能够一次登录，多次使用。用户不再需要每次输入用户名称和用户密码，也不需要牢记多套用户名称和用户密码。单点登录平台能够改善用户使用应用系统的体验。(2)方便管理员系统管理员只需要维护一套统一的用户账号，方便、简单。相比之下，系统管理员以前需要管理很多套的用户账号。每一个应用系统就有一套用户账号，不仅给管理上带来不方便，而且，也容易出现管理漏洞。(3)简化应用系统开发开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发流程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统并不需要开发用户认证程序。三，实现SSO的技术主要有： (1)基于cookies实现，需要注意如下几点：如果是基于两个域名之间传递sessionid的方法可能在windows中成立，在unix&linux中可能会出现问题；可以基于数据库实现；在安全性方面可能会作更多的考虑。另外，关于跨域问题，虽然cookies本身不跨域，但可以利用它实现跨域的SSO。(2)Broker-based(基于经纪人)，例如Kerberos等；这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的第三方。例如Kerberos、Sesame、IBM KryptoKnight（凭证库思想）等。(3)Agent-based(基于代理人)在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如, 它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个翻译。例如SSH等。(4)Token-based，例如SecurID、W ebID、现在被广泛使用的口令认证，比如FTP，邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。(5)基于网关Agent and Broker-based，这里不作介绍。(6)基于安全断言标记语言(SAML)实现，SAML（Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范，可参考。四、SSO实现原理1、概念：SSO的一种偏向技术的说法：用户只需登陆一次，就可使用多个SSO enable的应用系统。（1）、单一的登陆点。理想的情况是用户通过任何应用系统都能进行SSO，这对于基于Web的系统是可行的。这种单一的登陆点在整个系统的设计中是唯一认证用户的地方，由登陆点将SSO token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）传递给应用系统，应用系统利用SSO token来进行用户已认证的验证。我们将这个单一的登陆点称为SSO Entry。（2）、SSO enable意味着对应用系统的修改不可避免。并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统，屏蔽已有的应用系统的用户认证模块，使用系统提供的SSO API来验证用户，以及对用户的操作进行授权。（3）、需要统一的认证，权限信息库。通常，认证与授权管理模块以一种应用专有的方式实现，系统的授权模型、认证，授权信息存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。这种设计与实现方式的缺点是显而易见的：由于认证、授权模块与应用逻辑之间的紧耦合使得认证、授权模块很难进行扩展与维护；认证、授权模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。这也是越来越多企业应用需要SSO的原因之一。SSO要求有统一的认证，权限存放库。但现实中，有的系统无法使用外部的认证，授权信息库，所以就需要在应用系统和Portal Server之间进行认证，同时进行授权信息的数据同步。2、实现描述：在用户成功登录 weblogic Portal之后，系统提供的Login Delegate机制来为用户登录到其有权可以使用的应用系统。系统提供Logout Delegate机制实现用户的注销功能（即SSO logout）。用户存取由Portal SSO保护的若干资源，SSO会话服务（Session/SSO Service）提供了授权的证明，这样就不再需要用户重新进行身份验证了。在这种方式下，即使用户要访问不同的域（weblogic domain）的应用，我们提供的Portal SSO Service为其保持会话服务。同时，SSO还包括的与登录恰恰相反的，统一的注销点，即用户一旦从Portal注销，则亦当从所有参与Portal SSO的应用注销。此处有一个例外，就是当用户从Portal登录并转向一个应用后，经过一段时间后可能会出现用户的该应用的会话还有效时用户的Portal会话过期时，此时用户将只能使用该应用，直到该用户再次登录Portal。3、通过SSO Agent：当用户试图通过浏览器存取受保护的应用资源时，系统提供安装在不同应用上的SSO Agent来截取用户对资源的请求，并检查请求是否存在会话标识符，即token。如果token不存在，请求就被传递给Portal SSO，在Portal SSO上会话服务负责创建会话token，然后认证服务将提供登陆页面以验证用户。4、创建会话Token：在用户身份验证之前，会话服务就创建了会话token。token为随机产生的Portal Server 会话标识符，该标识符代表了一个确定用户的特定会话。创建会话token后，认证服务把token插入cookie中在用户的浏览器中设定cookie。在token被设定的同时，该用户将会看到一个登陆页面。5、用户认证：用户收到登陆页面和会话token后，填入合适的认证信息。当用户提交登陆页面后，这些认证信息就被发给认证提供者（authentication provider）（LDAP服务器，RADIUS服务器等）进行验证。一旦认证提供者成功验证了认证信息，用户就被认为是通过了认证。Identity Server会从用户的token中取出会话信息并将会话状态设为有效。此后，用户就可以访问这些受保护的资源。6、cookie和会话token：Cookie是由Web服务器创建的信息包，并传递给浏览器。Cookie 保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在Identity Server的实现中，cookie由会话服务产生，并由认证服务设定。而且，Identity Server的cookie是会话cookie，存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产生，并包含Portal Server特有的会话信息。在存取受保护的资源之前，用户由认证服务验证，并创建SSO token。7，要实现SSO，需要以下主要的功能：（1）所有应用系统共享一个身份认证系统。统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。 （2）所有应用系统能够识别和提取ticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。 8，WEB SSO 与 桌面 SSOWEB SSOWeb协议（也就是HTTP）是一个无状态的协议。一个Web应用由很多个Web页面组成，每个页面都有唯一的URL来定义。用户在浏览器的地址栏输入页面的URL，浏览器就会向Web Server去发送请求。如下图，浏览器向Web服务器发送了两个请求，申请了两个页面。这两个页面的请求是分别使用了两个单独的HTTP连接。所谓无状态的协议也就是表现在这里，浏览器和Web服务器会在第一个请求完成以后关闭连接通道，在第二个请求的时候重新建立连接。Web服务器并不区分哪个请求来自哪个客户端，对所有的请求都一视同仁，都是单独的连接。这样的方式大大区别于传统的（Client/Server）C/S结构,在那样的应用中，客户端和服务器端会建立一个长时间的专用的连接通道。正是因为有了无状态的特性，每个连接资源能够很快被其他客户端所重用，一台Web服务器才能够同时服务于成千上万的客户端。但是我们通常的应用是有状态的。先不用提不同应用之间的SSO，在同一个应用中也需要保存用户的登录身份信息。例如用户在访问页面1的时候进行了登录，但是刚才也提到，客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串，并且可以保存在浏览器中。如下图所示，当浏览器访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。为了完成一个简单的SSO的功能，需要两个部分的合作：1,统一的身份认证服务。 2,修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。 桌面SSO的实现从WEB-SSO的概念延伸开，我们可以把SSO的技术拓展到整个桌面的应用，不仅仅局限在浏览器。SSO的概念和原则都没有改变，只需要再做一点点的工作，就可以完成桌面 SSO 的应用。桌面SSO和WEB-SSO一样，关键的技术也在于如何在用户登录过后保存登录的凭据。在WEB-SSO中，登录的凭据是靠浏览器的cookie机制来完成的；在桌面应用中，可以将登录的凭证保存到任何地方，只要所有SSO的桌面应用都共享这个凭证。桌面样例的部署1,运行此桌面SSO需要三个前提条件：a) WEB-SSO的身份认证应用应该正在运行，因为我们在桌面SSO当中需要用到统一的认证服务b) 当前桌面需要运行Mozilla或Netscape浏览器，因为我们将ticket保存到mozilla的cookie文件中c) 必须在JDK1.4以上运行。（WEB-SSO需要JDK1.5以上） 2,解开desktopsso.zip文件，里面有两个目录bin和lib。 3,bin目录下有一些脚本文件和配置文件，其中perties包含了三个需要配置的参数：a) SSOServiceURL要指向WebSSO部署的身份认证的URLb) SSOLoginPage要指向WebSSO部署的身份认证的登录页面URLc) cookiefilepath要指向当前用户的mozilla所存放cookie的文件 4,在bin目录下还有一个login.conf是用来配置JAAS(java安全机制，通过对运行程序的用户的进行验证，从而达到保护系统的目的)登录模块，本样例提供了两个，读者可以任意选择其中一个（也可以都选），再重新运行程序，查看登录认证的变化 5,在bin下的运行脚本可能需要作相应的修改a) 如果是在unix下，各个jar文件需要用“:”来隔开，而不是“;”b) java 运行程序需要放置在当前运行的路径下，否则需要加上java的路径全名。五，用户单点登录流程1用户访问应用系统。图 3.3 用户单点登录流程 - 步骤一2、应用系统如果检查到用户没有在自己的服务器登录，则将用户请求重定向到单点登录服务器上。（使用重定向就可以处理各服务器跨域的情况）图 3.4 用户单点登录流程 - 步骤二3、单点登录服务器检查到用户已经单点登录（如果用户没有单点登录则要求用户登录，登录标志存储为客户端浏览器的Cookie），找到该用户在相应应用系统上绑定的账号。图 3.5 用户单点登录流程 - 步骤三4、单点登录服务器根据第三步的结果生成用户令牌，重定向回应用系统。图 3.6 用户单点登录流程 - 步骤四5、应用系统接收统一格式的用户令牌，取得用户在本系统上的登录账号，将用户在本系统上状态置为登录，返回用户请求访问的页面。图 3.7 用户单点登录流程 - 步骤五如果用户在访问应用系统之前已经在单点登录服务器上登录过，第二步到第四布对用户来说就是透明的，用户感觉只是向应用系统发出了访问请求，然后得到了页面反馈。实现SSO的开源框架介绍:一， CAS 背景介绍 CAS（Central Authentication Service），是耶鲁大学开发的单点登录系统（SSO，single sign-on），应用广泛，具有独立于平台的，易于理解，支持代理功能。CAS系统在各个大学如耶鲁大学、加州大学、剑桥大学、香港科技大学等得到应用。Spring Framework的Acegi安全系统支持CAS，并提供了易于使用的方案。Acegi安全系统，是一个用于Spring Framework的安全框架，能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务，包括使用Bean Context，拦截器和面向接口的编程方式。因此，Acegi安全系统能够轻松地适用于复杂的安全需求。Acegi安全系统在国内外得到了广泛的应用，有着良好的社区环境。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（Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务） 的票据方式。 CAS v1 非常原始，传送一个用户名居然是 ”yesndavid.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 的判断是毋庸置疑的。首先让我们从CAS 协议（非proxy模式）入手，CAS 实现SSO的过程如下：1、终端客户请求访问应用系统。2、CAS Client重定向到CAS Server请求验证。3、如果用户未登陆SSO安全域，CAS Server进行身份验证。4、身份验证通过后CAS Server生成Service Ticket并重定向用户到CAS Client（附加用户信息和ST）。5、CAS Client 和 CAS Server 之间完成了对用户的身份核实。6、最后将访问控制权交还给应用系统。 该协议完成了一个很简单的任务，就是 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 ： 如果通过 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) 。 Yale CAS使用了Ticket Granting Cookie （简称TGC）去作为获取Service Ticket（简称ST）的凭据，这个TGC 是保存在客户端的cookie，即当第2次被其他CAS Client重定向的时候，CAS Server实际上已经从用户的Cookie中抓取到TGC，然后知道TGC对应的用户，因此避免了再次登录，如果CAS Server抓取不到TGC，则用户需要登陆。文章引用自： 众所周知，cookie是不能跨域的。但是CAS能够做和的sso，因为CAS Server缓存了所有的ticket，所以Client无需共享cookies。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 。 CAS代理模式 初学者可能会对上图的 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，功能相当于ST ）而不是 Service Ticket (ST)。 最终的结果是， helloservice2 明白 helloservice 所代理的客户是 David. Turing 同学，同时，根据本地策略， helloservice2 有义务为 PGTURL=http:/helloservice/proxy 服务 (PGTURL 用于表示一个 Proxy 服务 ) ，于是它传递数据给 helloservice 。这样， helloservice 便完成一个代理者的角色，协助 User 返回他想要的数据。 代理认证模式非常有用，它也是 CAS 协议 v2 的一个最大的变化，这种模式非常适合在复杂的业务领域中应用 SSO 。因为，以前我们实施 SSO 的时候，都是假定以 IE User 为 SSO 的访问者，忽视了业务系统作为 SSO 的访问者角色。 CAS 安全性 CAS 的安全性是一个非常重要的 Topic 。 CAS 从 v1 到 v3 ，都很依赖于 SSL(安全套接层协议层)，它假定了这样一个事实，用户在一个非常不安全的网络环境中使用 SSO ， Hacker 的 Sniffer 会很容易抓住所有的 Http Traffic ，包括通过 Http 传送的密码甚至 Ticket 票据。 1.TGC/PGT 安全性 对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。 SSO 的安全性问题比普通应用的安全性还要严重，因为 SSO 存在一种门槛效应。以前即使 Hacker 能够截获用户在 Web 应用 A 的密码，它也未必能知道用户在 Web 应用 B 的密码，但 SSO 让 Hacker 只需要截获 TGC( 突破了门槛 ) ，即能访问所有与该用户相关的所有应用系统。 PGT 跟 TGC 的角色是一样的，如果被 Hacker 获得，后果可想而知。 从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。 因此，某些人认为 CAS 可以不使用 SSL 的想法需要更正一下， CAS 的传输安全性仅仅依赖与 SSL 。 跟 Kerberos 一样 TGT ， TGC 也有自己的存活周期。下面是 CAS 的 web.xml 中，通过 grantingTimeout 来设置 CAS TGC 存活周期的参数，参数默认是 120 分钟，在合适的范围内设置最小值，太短，会影响 SSO 体验，太长，会增加安全性风险。 edu.yale.its.tp.cas.grantingTimeout 7200 TGC 面临的风险主要并非传输窃取。比如你登陆了之后，没有 Logout ，离开了电脑，别人就可以打开你的浏览器，直接访问你授权访问的应用 ) ，设置一个 TGC 的有效期，可以减少被别人盗用，或者被 Hacker 入侵你的电脑直接获取你系统目录下的 TGC Cookie 。 2. Service Ticket/Proxy Ticket 安全性 首要明白， Service Ticket 是通过 Http 传送的，以为着所网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 协议从几个方面让 Service Ticket 变得更加安全。 l Service Ticket 只能使用一次。 CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会将服务端的缓存中清除该 Ticket ，从而可以确保一个 Service Ticket 被使用两次。 l Service Ticket 在一段时间内失效。 假设用户拿到 Service Ticket 之后，他请求 helloservice 的过程又被中断了， Service Ticket 就被空置了，事实上，此时， Service Ticket 仍然有效。 CAS 规定 Service Ticket 只能存活一定的时间，然后 CAS Server 会让它失效。通过在 web.xml 中配置下面的参数，可以让 Service Ticket 在多少秒内失效。 edu.yale.its.tp.cas.serviceTimeout 300 该参数在业务应用的条件范围内，越小越安全。 l Service Ticket 是基于随机数生成的。 Service Ticket 必须足够随机，如果 Service Ticket 生成规则被猜出（如果你使用了 ST+Helloservice+ 自增序列的方式， Hacker 就可以构造下一个 Ticket ）， Hacker 就等于绕过 CAS 认证，直接访问所有服务。 (一).Tomcat（版本Tomcat5.0.30）配置CAS服务器及客户端本文使用同一个Tomcat（版本Tomcat5.0.30）配置CAS服务器及客户端，分别在8443端口及8080端口。下面是在Tomcat中使用Yale CAS实现单点登陆的详细步骤： 1，安装CAS服务器1.1.下载CAS发行包，下载地址：CAS 服务器： /tp/cas/cas-server-2.0.12.zip 或 /wiki/download/attachments/924/cas-server-2.0.12.zip CAS 客户端： /tp/cas/cas-client-2.0.11.zip 或 /wiki/download/attachments/827/cas-client-2.0.11.zip 1.2.将cas-server-2.0.12.zip解压，并将lib/cas.war拷贝到Tomcat的webapps下，测试CAS服务器是否发布正常，可以访问http:/localhost:8080/cas/login出现登陆窗口。输入用户名密码（用户名密码），出现登陆成功页面说明发布正常。2，配置Tomcat使用https协议2.1.使用Java自带的keytool命令，产生SERVER的证书D: keytool -genkey -alias my-alias-name -keyalg RSA -keystore keystore-file 其中 my-alias-name 为别名，这行命令的作用是产生一个新的公共 / 私有钥匙对。 keystore-file 为存储钥匙和证书的文件。 命令运行后，根据提示回答。注意在开始问“你的名字”或“DName”的时候，必须填写你服务器所在域名（在局域网中测试时，使用主机名或hosts文件中注册的域名,本机可以使用localhost）。 2.2.在Tomcat的8443端口配置SSL在 Tomcat_Pathconfserver.xml 文件中配置 SSL 的地方，增加如下配置： 其中，keystoreFile使用绝对路径，keystorePass为第3点输入的keystore密码。配置完成后，启动Tomcat,访问https:/localhost:8443 ，访问成功说明SSL配置成功。也可以访问https:/localhost:8443/cas/login 。 3，配置 CAS客户端以Tomcat中自带的Servlet examples应用为例，在Web应用中使用配置CAS客户端。 3.1.在Servlet examples应用里配置CAS客户端，需修改servlets-examples/WEB-INF/web.xml，在web.xml文件中,加入如下Filter配置： CASFilter edu.yale.its.tp.cas.client.filter.CASFilter edu.yale.its.tp.cas.client.filter.loginUrl https:/localhost:8443/cas/login edu.yale.its.tp.cas.client.filter.validateUrl https:/localhost:8443/cas/proxyValidate edu.yale.its.tp.cas.client.filter.serverName localhost:8080 CASFilter /servlet/* 其中，第一，二个localhost都改成CAS服务器域名或主机名，第三个改成你servelt example应用域名或主机名，由于本文中CAS服务器与客户端在同一主机同一Tomcat上，所以都为localhost。若不在同一主机，则分别使用两主机的域名或主机名。 3.2.将cas-client-2.0.11.zip解压，把java/lib/casclient.jar拷贝到Tomcat的webapps/servlets-examples/WEB-INF/lib目录下（如果没有就建一个）3.3.导出SERVER的证书，用来给所有需要用到的客户端导入D: keytool -export -file myserver.cert -alias my-alias-name -keystore keystore-file 3.4.在客户端的JVM里导入信任的SERVER的证书，输入keystore密码时，注意现在的keystore为cacerts，而cacerts的初密码为changeit，而不是前面keystore-file的密码，所以要是没有改过cacerts密码应该输入changeit.D: keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -file myserver.cert -alias my-alias-name 其中，$JAVA_HOME改成JDK的绝对路径。 4，测试SSO启动Tomcat，访问 http:/localhost:8080/servlets-examples/ ，随便执行一个servlet，系统会自动跳转到一个验证页面，随便输入一个相同的账号,密码，认证通过之后，就会访问到你点击的servlet了。 CAS (Central Authentication Service)是Yale大学的ITS开发的一套JAVA实现的开源的SSO(single sign-on)的服务。这里用一个简单的例子来说明用CAS来