CAS3.0的工作流程:
0.app将用户转发到CAS处, 并将自己的url作为callback参数传给CAS.
1.CAS验证用户成功(authentication)
2.生成用户实体(principal)
3.CAS在TicketRegistry中加入一张新ticket
4.CAS将新加入的这张ticket作为ticket-granting ticket发给用户
5.从该用户处得到一张ticket-granting ticket(其实就是上面发给用户的那张)(validation)
6.拿到这张ticket后,CAS去检查TicketRegistry中是否有这张票对应的注册
7.如果有,那么就在TicketRegistry中加入另一张新的ticket_1.
8.将ticket_1作为service ticket伴随着calback URL将用户转发到app
9.app将刚接受到的service ticket转回CAS,要求确认这张票的真实性.
10.CAS拿到service ticket后检查TicketRegistry中是否对应着有这张票的注册.(validation)
11.如果有返回"yes"和用户netID给app, app象用户提供服务.
关于CAS的定制方法:
大家都知道了,cas其实是一个独立的webapp, 在WEB-INF中的deployerConfigContext.txt文件是所有CAS deployer应该关心的东西,在这里,你可以对CAS的三个核心玩意进行自己的定制:
1.AuthenticationManager
他的任务只有一个"验证操作" - authentication, 可以看看javadaoc来参考一下,上面是写的很明了的.
想要定制自己的AuthenticationManager的话,就动手实现这个接口吧.不过一般来说,CAS自带的实现已经够用啦!
2.credentialsToPrincipalResolvers
这是一个能将credentials转换成principal的转换器的列表, 列表中,主要是些根据不同种类的credential来使用的不同转换类型的转换器,如果你有你自己特有的一种credential的话,那就自己动手做有个能将这个credential转换为principal的转换器吧。制作完成后记得把它添加到这个列表中！现在说说什么是credential,什么是principal，在CAS验证一个credential成功后,需要将一个credential转换为一个principal, 这是符合常理的,credential其实只是表示一个"介绍信",而principal则表示一个已经参与到"工作"中的实体.
3.authenticationHandlers
注意啦,这个authenticationHandler可是所有CAS用户都需要修改的地方啊!authenticationHandler其实就是这个真真正正落实验证业务的"业务员"!CAS自带了一个测试用的username和password的"业务员",这个小同志只是简单的检查你输入的 username(也就是那个netID)和password是不是一对相等的字符串(比如NetID = aa, password = aa),如果是,就判定你登陆成功.可是这么简单的业务当然不能满足你的需求,你的需求也许包括了需要通过检索数据库来比配credential中的 username和password，也可能不是数据库，而是LDAP什么的，总之你得开始制作自己的handler了！credential的种类是很多的，有的基于用户名和密码，有的基于http请求，如果你有你自己的credential的话，就得为它制作有一个handler，来告诉CAS如何处理这种特有的credential。制作完成后记得将它加入这个列表。