SSO (Single Sign-on)原理讲义.docVIP

SSO (Single Sign-on)原理 SSO 分为Web-SSO和桌面SSO。桌面 SSO 体现在操作系统级别上。Web-SSO体现在客户端，主要特点是： SSO 应用之间使用 Web 协议 ( 如 HTTPS) ，并且只有一个登录入口。我们所讲的SSO，指 Web SSO 。 SSO 的体系中，有下面三种角色： User（多个） Web应用（多个） SSO认证中心（一个） SSO 实现模式千奇百怪，但万变不离其宗，包含以下三个原则： 所有的登录都在 SSO 认证中心进行。 SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是通过认证的用户。 SSO 认证中心和所有的 Web 应用建立一种信任关系。 CAS 的基本原理 CAS(Central Authentication Service) 是 Yale 大学发起的构建 Web SSO 的 Java开源项目。 CAS 的结构体系 CAS Server CAS Server 负责完成对用户信息的认证，需要单独部署，CAS Server 会处理用户名 / 密码等凭证 (Credentials) 。 CAS Client CAS Client部署在客户端，当有对本地 Web 应用受保护资源的访问请求，并且需要对请求方进行身份认证，重定向到 CAS Server 进行认证。 CAS 协议 基础协议 上图是一个基础的 CAS 协议， CAS Client 以 过滤器的方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的， CAS Client 会重定向用户请求到 CAS Server （ Step 2 ）。 Step 3 是用户认证过程，如果用户提供了正确的认证信息 ， CAS Server 会产生一个随机的 Service Ticket ，会向 User 发送一个 Ticket granting cookie (TGC) 给 User 的浏览器，并且重定向用户到 CAS Client （附带刚才产生的 Service Ticket），Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实，用 Ticket 查到 Username ，认证通过。 CAS 如何实现 SSO 当用户访问Helloservice2再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情： 如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果。 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。 实践配置 下面我们以tomcat 5.5 为例进行说明(这里，我将Server和Client同时放在了同一个Tomcat服务器下)。5.5 ant-1.6.5, jdk1.5.0_06 下载cas-server-3.0.4.zip和cas-clientcas-server-jdbc-3.0.5-rc2.jar和mysql 5.0.16和tomcat 5.5.15 /downloads/cas/cas-server-3.0.4.zip /tp/cas/cas-client-2.0.11.zip /maven/cas/jars/cas-server-jdbc-3.0.5-rc2.jar / 将一个或者一些页面进行支持HTTPS传输协议（意义：对某些页面进行了安全传输）（重点掌握） 产生SERVER的证书keytool -genkey -alias tomcat -keyalg RSA [-keystore keystore-file] 并将证书文件放在web容器的目录下。 (在server)配置tomcat使用HTTPS$CATALINA_HOME/conf/server.xml里 Connector port=8443 maxHttpHeaderSize=8192 keystorePass=changeit keystoreFile=\conf\.keystore maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true