统一身份认证-CAS配置实现.doc

一、背景描述 随着信息化的迅猛发展，政府、企业、机构等不断增加基于Internet/Intranet 的业务系统，如各类网上申报系统，网上审批系统，OA 系统等。系统的业务性质，一般都要求实现用户管理、身份认证、授权等必不可少的安全措施，而新系统的涌现，在与已有系统的集成或融合上，特别是针对相同的用户群，会带来以下的问题： 1、每个系统都开发各自的身份认证系统，这将造成资源的浪费，消耗开发成本，并延缓开发进度； 2、多个身份认证系统会增加系统的管理工作成本； 3、用户需要记忆多个帐户和口令，使用极为不便，同时由于用户口令遗忘而导致的支持费用不断上涨； 4、无法实现统一认证和授权，多个身份认证系统使安全策略必须逐个在不同的系统内进行设置，因而造成修改策略的进度可能跟不上策略的变化； 5、无法统一分析用户的应用行为 因此，对于拥有多个业务系统应用需求的政府、企业或机构等，需要配置一套统一的身份认证系统，以实现集中统一的身份认证， 并减少信息化系统的成本。单点登录系统的目的就是为这样的应用系统提供集中统一的身份认证，实现“一点登录、多点漫游、即插即用、应用无关CAS（Central Authentication Service），是耶鲁大学开发的单点登录系统（SSO，single sign-on），应用广泛，具有独立于平台的，易于理解，支持代理功能。CAS系统在各个大学如耶鲁大学、加州大学、剑桥大学、香港科技大学等得到应用。Spring Framework的Acegi安全系统支持CAS，并提供了易于使用的方案。Acegi安全系统，是一个用于Spring Framework的安全框架，能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务，包括使用Bean Context，拦截器和面向接口的编程方式。因此，Acegi安全系统能够轻松地适用于复杂的安全需求。Acegi安全系统在国内外得到了广泛的应用，有着良好的社区环境。CAS的设计目标(1)为多个Web应用提供单点登录基础设施，同时可以为非Web应用但拥有Web前端的功能服务提供单点登录的功能；(2)简化应用认证用户身份的流程；(3)将用户身份认证集中于单一的Web应用，让用户简化他们的密码管理，从而提高安全性；而且，当应用需要修改身份验证的业务逻辑时，不需要到处修改代码。CAS的实现原理 CAS（Central Authentication Server）被设计成一个独立的Web应用。它目前的实现是运行在HTTPS服务器的几个Java Servlet上（而客户端可以灵活采用http和https的方式）。CAS创建一个位数很长的随机数（ticket）。CAS把这个ticket和成功登录的用户以及用户要访问的service联系起来。例如，如果用户peon重定向自service S，CAS创建ticket T，这个ticket T允许peon访问service S。这个ticket是个一次性的凭证；它仅仅用于peon和仅仅用于service S，并且只能使用一次，使用之后马上会过期，即ticket通过验证，CAS立即删除该ticket，使它以后不能再使用。这样可以保证其安全性。关于ST，在取一个ST时，即使用deleteTicket(ticketId)同时将一次性的ST删除；而对于TGT或PT，则通过resetTimer(ticketId)以更新TGT或PT的时间。在CAS服务端返回的ST中只能得出用户名。 / 三、统一认证配置实现 1、基础套件 cas-server-3.4.11 spring3 hibernate3(可选) dbcp（数据库连接池，可选） slf4j(log4j) 2、概念 1)、 通道安全性 图：非ssl(HTTP) 图：ssl(HTTPS) 单向认证：传输的数据经过加密，但不会校验客户端的来源 双向认证：传输的数据经过加密，并需要校验客户端。如果客户端浏览器没有导入客户端证书，则访问不了web系统。 2)、CAS服务端 3)、CAS客户端 4)、应用服务端 5)、客户端 3、配置实现 Tomcat(http) 1)、修改配置 将cas-server-webapp-3.4.11.war解压成cas： 图1 在默认情况下，只要用户名和密码是一样的，就可以登录，因此需要根据实际情况作调整。大多数情况下，应用都将用户信息存放于数据库中，数据库中的用户密码也可能是经过加密的。 定位deployerConfigContext.xml，修改认证逻辑，如下图所示： 图2 图3 定位ticketGrantingTicketCookieGenerator.xml，将cookieSecure设为false，即不启用ssl。 图4