ICFP中CAS集成开发进展.pptVIP

CAS中央认证系统集成进展 CAS原理介绍 CAS1.0 　CAS1.0也称为基础模式 　适用场合：参与SSO的应用都为Web应用，且各应用之间相互独立，没有复杂的集成关系。 CAS2.0 　CAS2.0称为代理模式 　适用场合： 参与SSO的应用存在非Web应用（CAS使用Cookie，故非Web应用不宜于直接做CAS的客户应用） 应用之间，存在集成关系。 CAS协议内容 CAS协议定义了一组术语，一组票据，一组接口。 术语：Client、Server、Service、Proxy、Target。 接口：/login、/logout /validate、/serviceValidate、/proxyValidate /proxy 票据：TGT、ST、PGT、PGTIOU、PT Client、CAS Server、Service三者，是通过各种票据 的传递与验证，来实现单点认证功能的。 CAS1.0协议的动画显示 场景介绍： 在本演示中，用户先访问工时系统TR，去填工时，之后又去服务支持系统SR，查看问题解答。 访问TR时，用户需要先去CAS登录，之后访问SR时， 就不需再次登录了。 https://CAS4ICAP/login?service=http://SR/index.html CASTGC ICFP登录认证框架时序 ICFP中CAS的应用场景 ICFP中CAS的应用开发 认证信息数据源支持 LDAP： IBM Tivoli Directory Server Oracle Internet Directory OpenLDAP 数据库： DB2 INFORMIX ORACLE …… ICFP中CAS的应用开发 2. 应用系统集成方式支持 ACEGI安全框架直接集成 Filter：CASFilter 应用系统使用Filter方式提供安全控制 未使用filter的LegacyApplication，但安全控制粒度是URL级别的 Servlet：CASServlet 未使用filter，且需要控制比URL更小的粒度 ICFP中CAS的应用开发 3. 自定义登录界面 登录界面在CAS Server中 login 登录界面在应用系统中 RemoteLogin ICFP中CAS的应用后续开发 如何保证CAS系统的高可用性（HA） 如何保留应用系统的原有登录认证机制（DA partially） 如何监控CAS Server的健康状态（HA） 如何动态切换登录方式，保证下游系统的可用性（DA） 如何提供系统访问权限控制（ICFP takeover） ICFP中CAS的HA方案-EhCache ICFP中CAS的HA方案-Memcache Memcache与EhCache比较 双入口（Dual Access）解决方案 双入口（Dual Access）解决方案 * * CFP项目. ICFP Portal分项目 Ticket Grangting Ticket 。TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。当HTTP请求到来时，CAS以此Cookie值为key查询缓存中有无TGT ，如果有的话，则相信用户已登录过。 Service Ticket 。ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，CAS发现用户有TGT，则签发一个ST，返回给用户。用户拿着ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。 Proxy TicketGranting Ticket。Proxy Service认证成功后，CAS会生成PGT，并将值回传给Proxy Service 。Proxy Service拿到PGT后，就可以为Target Service做代理，为其申请PT。 Proxy TicketGranting Ticket IOU。PGTIOU是CAS协议中定义的一种附加票据，它增强了传输、获取PGT的安全性。 Proxy Ticket。PT是用户访问Target Serivce的票据。用户经由Proxy Service去CAS获取到PT后，再访问Target Serivce，Target Serivce去CAS验证PT成功后，才允许用户访问。 接受用户输入用户名和密码，并启动验证机制的入口 注销用户单点登录会话的借口 CAS1.0协议的验证接口，用于验证Service Ticket的合法性，