项目需要，对CAS的源代码做了一番了解，记录下来，以备日后可以比较容易地找到思路。
首先是理解CAS用来满足的需求，CAS需要提供CAS1.0和2.0两种协议，这个在http://www.jasig.org/cas/protocol中有叙述，但并不是很有条理。在CAS Client .net版本的站点上倒是非常精炼。（http://www.middleware.vt.edu/doku.php?id=middleware:cas:protocol）简言之，CAS1.0提供了plain text格式的response，CAS2.0提供了xml格式的，另外，CAS2.0最大的不一样是提供了proxy ticket的功能，就是一个service可以代表用户对另外一个service进行访问，而无需用户的交互。在CAS2.0中又分为普通的xml response和符合saml标准的response，其不同之处在于，普通xml response只需要含有userid的信息即可，而saml response可以含有多个attributes，客户端可以按照约定进行解析。用下来觉得CAS2.0 saml比较实用，可以传递email地址，以及权限信息等。（如果对CAS2.0的普通xml response稍加修改也能达到同样效果，但是手工加进去的，如果attributes名字或数量有变化还要再手工修改）
其次，要了解CAS代码的大体结构，就需要知道程序执行的大概顺序。为了达到SSO的效果以及安全性，CAS在用户输入用户名密码点击提交按钮之后，将做两次交互，第一次根据用户名密码验证情况，成功的话发送一个含有TGT的cookie给浏览器，然后CAS Server读取这个cookie，检查其中的TGT是不是由CAS Server发出的，如果是那么就由TGT生成ST，返回带有ST的参数及值。客户端此时拿到ST之后，向CAS的/serviceValidate或者/samlValidate发出验证请求，CAS返回具体的验证信息，包括用户名，email，权限等等，登录结束。
根据上述大致流程，理解代码就要容易一些。整个代码的入口在CentralAuthenticationServiceImpl（上述两次交互通过spring webflow实现，每一步的action都是来调用这个类），在webflow流程中，ServiceValidateController将request中的信息通过 CasArgumentExtractor提取出来l组合成SimpleWebApplicationServiceImpl类（父类是 service->principal）。对用户名密码的验证由AuthenticationManagerImpl实现，在验证通过之后，由credentialsToPrincipalResolvers将具体需要拿到的各种属性取出，封装成SimplePrincipal类（父类为principal）。验证完毕后，返回的是ImmutableAuthentication类，这个类携带了SimplePrincipal。然后由TicketGrantingTicketImpl产生TGT，包括产生时间，过期策略等等。下一步由TGT产生ST，发送回客户端。
CAS代码的结构特点，在代码的结构中，多次用到abstract类，这种类继承了一个或几个接口，实现了其中的部分方法。最终的实现类继承这种abstract类以及接口，以此实现对不同协议需求类型的映射。在使用过程中，对此种类的调用，都采用注入方式，引用的都是其接口，从而实现由配置即可确定提供何种服务的目标，非常值得借鉴。
另外，通过阅读代码，了解其结构，我也做了一些狗尾继貂的改动。本项目需要提供soap api，但需要有权限控制，如果单独写一套也是可以的，可既然已经有了CAS便想利用现有的东西。soap api和CAS client在逻辑上最大的不同是cookie，因为调用soap api的客户端可能性很多，能不能存cookie是不一定的。这样的话，CAS的认证过程就被打破了，也称不上sso了。不过好在soap api的要求也不高，只要求能登录，能控制权限即可，不需要和网页部分的登录发生联系。
需求明确之后，只要在原有代码上做减法即可。看看uml图以及代码便基本了解了方向，只要利用CAS的几样东西，一个是到数据库去取用户信息，一个是生成ticket并保持一段时间。所以，我把原有的东西简化了一下，再利用xfire便得到了具有开发soap api登录功能的CAS。
CAS的代码用文字描述实在不是一件容易的事，需要uml图帮助理解。
