电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: 单点登录SSO的介绍和CAS+选型（3） [打印本页]

作者: look_w 时间: 2019-5-11 14:46 标题: 单点登录SSO的介绍和CAS+选型（3）

用户访问流程流程实例

用户第一次访问一个CAS 服务的客户web 应用时（例如访问URL ：http://192.168.1.90:8081/web1 ），部署在客户web 应用的cas AuthenticationFilter ，会截获此请求，生成service 参数，然后redirect 到CAS 服务的login 接口，url为https://cas:8443/cas/login?service=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2F ，认证成功后，CAS 服务器会生成认证cookie ，写入浏览器，同时将cookie 缓存到服务器本地，CAS 服务器还会根据service 参数生成ticket,ticket 会保存到服务器，也会加在url 后面，然后将请求redirect 回客户web 应用，url 为http://192.168.1.90:8081/web1/?t ... MwnbMvxpCBcNAIi6-20 。

这时客户端的AuthenticationFilter 看到ticket 参数后，会跳过，由其后面的TicketValidationFilter 处理，TicketValidationFilter 会利用httpclient 工具访问cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口，由此接口验证ticket 的有效性，TicketValidationFilter 如果得到验证成功的消息，就会把用户信息写入web 应用的session里。

至此为止，SSO 会话就建立起来了，以后用户在同一浏览器里访问此web 应用时，AuthenticationFilter 会在session 里读取到用户信息，所以就不会去CAS 认证，如果在此浏览器里访问别的web 应用时，AuthenticationFilter 在session 里读取不到用户信息，会去CAS 的login 接口认证，但这时CAS 会读取到浏览器传来的cookie ，所以CAS 不会要求用户去登录页面登录，只是会根据service 参数生成一个ticket ，然后再和web 应用做一个验证ticket 的交互。

代码层次如何实现CAS

知道工作原理和流程之后我们来看看应该怎么在代码上实现CAS

一般来说，我们写Web应用只需要熟悉这几个Filter就可以了，如果不需要https连接，连第一个也不用熟悉。但是有人肯定会想，这些 Filter怎么和我的数据库联系起来呢？不用着急，这些Filter并不直接处理用户的认证，也不直接处理用户的授权，而是把它们交给了认证管理器和决策管理器。

对于这两种管理器，那也是不需要我们写代码的，Acegi也提供了现成的类。那么大家又奇怪了：又是现成的，那怎么和我的数据库关联起来呢？别着急，其实这两个管理器自己也不做事，认证管理器把任务交给了Provider，而决策管理器则把任务交给了Voter，如下图：

现在我要告诉你们，这里的Provider和Voter也是不需要我们写代码的。不要崩溃，快到目标了。Acegi提供了多个Provider 的实现类，也就是说CAS的认证方式有很多种，我们可以到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对于很多种方式，CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，可以由我们自己来决定，也就是，这个认证的实现细节可以自己定制和扩展。例如如果我们想用数据库来储存用户的认证数据，那么我们就选择DaoAuthenticationProvider。对于Voter，我们一般选择 RoleVoter就够用了，它会根据我们配置文件中的设置来决定是否允许某一个用户访问制定的Web资源。

　　而DaoAuthenticationProvider也是不直接操作数据库的，它把任务委托给了UserDetailService，如下图：

而我们要做的，就是实现这个UserDetailService。说了这么多总算是引出了我们开发中的关键，那就是我们要实现自己的UserDetailService，它就是连接我们的数据库和Acegi的桥梁。UserDetailService的要求也很简单，只需要一个返回org.springframework.security.userdetails.User对象的 loadUserByUsername(String userName)方法。因此，怎么设计数据库都可以，不管我们是用一个表还是两个表还是三个表，也不管我们是用户-授权，还是用户-角色-授权，还是用户-用户组-角色-授权，这些具体的东西Acegi统统不关心，它只关心返回的那个User对象，至于怎么从数据库中读取数据，那就是我们自己的事了。

反过来再看看上面的过程，我们发现，即使我们要做的只是实现自己的UserDetailService类，但是我们不得不在Spring中配置那一大堆的Bean，包括几个Filter，几个Manager，几个Provider和Voter，而这些配置往往都是重复的无谓的。好在Acegi 2.0也认识到了这个问题，所以，它设计了一个<http>标签，让Acegi的配置得到了简化。
在后面具体的部署实施中我们再来详细讲这些细节。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)