CAS认证（2）：认证过程

上一部分主要是对webflow同spring MVC进行结合进行了粗略的讲解。这里，将对webflow定义的流程进行更加详细的说明。

前面说到用户的认证请求经过spring MVC 对应配置的/login 路径进入webflow中的viewLoginForm 也就是登录界面。该用户的登录界面通过

<transition on="submit" bind="true" validate="true" to="realSubmit">
    <set name="flowScope.credentials"value="credentials" />
    <evaluate expression="authenticationViaFormAction.doBind(flowRequestContext,flowScope.credentials)" />
</transition>

用户点击登录之后，就将登录请求提交到了realSubmit中。realSubmit执行的对应的是AuthenticationViaFormAction中的submit方法。在该方法中，首先通过

final String ticketGrantingTicketId =WebUtils.getTicketGrantingTicketId(context); 

判断用户请求中，是否存在TGT（Ticket grant ticket）。这里说明一下，TGT是以cookie形式存在CASServer域下的。默认情况是只有http请求才向CASServer提交的。该cookie为CASServer识别用户是否登录的唯一标示。如果存在，则认为是用户已经登陆过的，否则认为用户是没有登录过的。

然后一下方法获取service：

 

final Service service =WebUtils.getService(context);

这个service是对应的服务。就是在你访问某个应用程序的时候，该请求被统一认证的过滤器拦截之后跳转到统一认证进行认证。跳转的过程中，会把你之前的请求的路径记录下来并作为参数传递到统一认证。在统一认证系统中配置的所有可以使用统一认证系统的业务系统的配置信息。该认证请求到了统一认证之后，统一认证根据这个路径查找对应的系统的配置信息。详情参照系统管理部分。

如果不存在TGT，则通过下面方法新生成一个TGT。

 

String tempTGT= this.centralAuthenticationService.createTicketGrantingTicket(credentials);

如果TGT存在，则生成ST并将其放入到context中。ST是service ticket的缩写。顾名思义，该ticket是和service对应的。所以，如果验证ticket有效性的时候，发送的验证请求所带service参数同生成ST的时候的参数不一致，就会出现ticket异常。默认的，ST的有效性是有时间和次数的限制的。默认是ST使用一次就失效，在1000秒以后失效。详情参见《CAS中ticket的生成与管理》。

final String serviceTicketId = this.centralAuthenticationService.grantServiceTicket(ticketGrantingTicketId, service,credentials);
WebUtils.putServiceTicketInRequestScope(context, serviceTicketId);
putWarnCookieIfRequestParameterPresent(context);
return "warn";

在webflow中跳转到“warn”状态，该状态中主要是验证流程中是否存在warnCookie，如果存在，则跳转到showWarningView中，否则进入redirect。在往下就是跳转到认证之前的目标路径了。注意，这里跳转的过程中，将ST作为跳转路径中的一个参数进行传递了。