cas服务原理.docxVIP

一、CAS服务端的处理逻辑 CAS服务端总共对外暴露了7个接口，客户端通过访问这7个接口与服务端交互，这7个接口为：/login、/logout、/validate、/serviceValidate、/proxy、/proxyValidate、/CentralAuthenticationService。/login是认证接口，/logout是退出接口，负责销毁认证cookie,/validate、/serviceValidate是验证ticket用的接口，其中/validate是CAS1.0定义的，/serviceValidate是CAS2.0定义的，其中/serviceValidate返回xml格式的数据，/proxy、/proxyValidate是支持代理认证功能的接口，/CentralAuthenticationService接口用于和远程的webservices交互。对于一般web应用的单点登录来讲，/login、/logout、/serviceValidate这3个接口已经可以满足要求。下面是我对CAS各个接口实现的的详细说明。 /login: 登录流程这部分要考虑到不同种类用户凭证的获取方案，以及客户应用传来的service、gateway、renew参数的不同取值组合，CAS为了实现流程的高度可配置性，采用了SpringWebFlow技术。通过阅读CAS发布包里的login-webflow.xml、cas-servlet.xml、applicationContext.xml这3个文件，找到登录有关的所有组件如下图： 注： 1：InitialFlowSetupAction:是流程的入口。用request.getContextPath()的值来设置cookie的Path值，Cookie的path值是在配置文件里定义的，但这个Action负责将request.getContextPath()的值设置为Cookie的path值，这是在cas部署环境改变的情况下，灵活地设置cookiepath的方式；把cookie的值以及service参数的值放入requestContext的flowscope里。 2：GenerateServiceTicketAction此Action负责根据service、GTCcookie值生成ServiceTicket对象，ServiceTicket的ID就是返回给客户应用的ticket参数，如果成功创建ServiceTicket，则转发到WarnAction，如果创建失败，且gateway参数为true，则直接redirect到客户应用，否则则需要重新认证。 3：viewLoginForm这是登录页面，CAS在此收集用户凭证。CAS提供的默认实现是/WEB-INF/view/jsp/simple/ui/casLoginView.jsp。 4：bindAndValidate对应AuthenticationViaFormAction的doBind方法，该方法负责搜集登录页面上用户录入的凭证信息（用户名、密码等），然后把这些信息封装到CAS内部的Credentials对象中。用户在casLoginView.jsp页面上点击提交后，会触发此方法。 5:submit对应AuthenticationViaFormAction的submit方法,如果doBind方法成功执行完，则触发submit方法，此方法负责调用centralAuthenticationService的grantServiceTicket方法，完成认证工作，如果认证成功，则生成TicketGrantingTicket对象，放在缓存里，TicketGrantingTicket的ID就是TGCCookie的value值。 6：warnCAS提供了一个功能：用户在一个web应用中跳到另一个web应用时，CAS可以跳转到一个提示页面，该页面提示用户要离开一个应用进入另一个应用，可以让用户自己选择。用户在登录页面viewLoginForm上选中了id=”warn”的复选框，才能开启这个功能。 WarnAction就检查用户有没有开启这个功能，如果开启了，则转发到showWarnView,如果没开启，则直接redirect到客户应用。 7：SendTicketGrantingTicketAction此Action负责为response生成TGCCookie，cookie的值就是AuthenticationViaFormAction的submit方法生成的TicketGrantingTicket对象的ID。 8：viewGenerateLoginSuccess这是CAS的认证成功页面。 /logout:（对应实现类org.jasig.cas.web.L