今天完成的事情：CAS的初步学习

这玩意真不好弄，首先就是一个SSL证书和https的设置，然后利用java自带的keytool生成安全证书：

就是这个玩意儿，那这个东西怎么生成呢：

然后是CAS的一个实现原理：

在第一次访问应用app1时，由于没有登录会直接跳转到Cas Server去进行登录认证，此时将附带查询参数service在Cas Server的登录地址上，表示登录成功后将要跳转的地址。此时Cas Server检查到没有之前成功登录后生成的SSO Session信息，那么就会引导用户到登录页面进行登录。用户输入信息提交登录请求，Cas Server认证成功后将生成对应的SSO Session，以及名为CASTGC的cookie，该cookie包含用来确定用户SSO Session的Ticket Granting Ticket（TGT）。之后会生成一个Service Ticket（ST），并将以ticket作为查询参数名，以该ST作为查询参数值跳转到登录时service对应的URL。如：

       http(s)://domain/app1?ticket=ST-2-59fS6KxvmykibRXyoPJE

       之后的操作对用户来说都是透明的，即不可见的。app1之后将以service和ticket作为查询参数请求Cas Server对service进行验证，验证通过后Cas Server将返回当前用户的用户名等信息。app1就会给当前用户生成其自身的Session，以后该用户以该Session都可以成功的访问app1，而不需要再去请求Cas Server进行认证。当该用户再去访问app2的时候，由于其在app2上没有对应的Session信息，将会跳转到Cas Server的登录地址，Cas Server此时发现其包含名为CASTGC的cookie，将获取其中包含的TGT来获取对应的SSO Session，然后会将用户重定向到app2对应的地址，以Service Ticket作为查询参数。之后app2会向Cas Server发送请求校验该Service Ticket，校验成功后app2将建立该用户对应的Session信息，以后该用户以该Session就可以自由的访问app2了。

       综上所述，我们知道，各系统之间的单点登录是通过Cas Server生成的SSO Session来交流的，而用户与实际的应用系统进行交互的时候，各应用系统将建立单独的Session，以满足用户与该系统的交互需求。

明天计划的事情：试着能不能把CAS服务器跑起来 
遇到的问题：

收获：CAS