一种多维度的数字化校园安全性设计.docxVIP

一种多维度的数字化校园安全性设计 0 web集成平台 数字化校园与大量web应用程序系统紧密相连。统一身份认证是必须解决的问题。单点登录(Single Sign-on,简称SSO)是实现统一身份认证的有效方式,比较成熟和稳定的解决方案有IBM公司的Websphere、SUN公司的Sun Java System Access Manager、Microsoft公司的passport、BEA的WebLogic以及一些基于SAML的产品,如OPENSAML、SourceID等。这些SSO方案的侧重点不一样,实现机制也不尽相同。但对于Web应用这种对系统简洁性需求较高的应用来说,一些解决方案并不非常合适,原因是它们对现有Web应用集成带来的代价过大,产生的负面效应尤为突出。 校园网是数字化校园运转的基础,具有结构相对简单,用户群比较单纯,数据传输质量较高的特点,在数字化校园中应用的SSO系统应尽可能减少对原有Web应用的改造,加快身份验证的速度,并能保证较高的安全性。本文针对数字化校园的特点,提出一种基于Cookie与临时码的SSO解决方案,阐述该方案的设计思路、工作流程和关键技术,讨论该方案的安全问题,最后介绍该方案的实现与应用情况。 1 登录单号的实现模式和战略 1.1 创建全局login百分点 典型的SSO系统都遵循一种通用的模式,由入口检查单元(gatekeeper)、身份认证单元(authenticator)和用户凭证存储单元(user credentials store)三个部分组成。交互关系如下: (1)gatekeeper检查到用户准备访问受到保护的Web资源时,它先检查该用户是否已为该Web应用创建好一个login session,若没有,gatekeeper再检查是否已建立一个和authenticator相关的全局SSO session;若没有,该用户被重定向到authenticator的登录页面,并要求该用户提供凭证信息(用户名和密码等)。 (2)authenticator接收该用户提供的凭证信息,并通过身份认证系统验证该用户。 (3)若验证成功,它将创建一个全局login session,导向至gatekeeper,并在该用户的Web应用中为其创建一个login session。 (4)authenticator和gatekeepers之间通过多种方式进行交互,如共享cookie方式。 1.2 实现平台认证的可行性 基于Web的单点登录实现策略主要有三种:ticket凭证、Web请求代理、密码代理。这三种实现策略的比较如表1所示。 以上对基于Web的单点登录模式和策略进行了比较。可以看出,在已有应用的基础上集成实现SSO系统,基于Web请求代理的认证策略对原有应用系统的改造代价较小,且登录服务器的负载相比密码代理策略小很多。本文基于数字化校园的特点,在借鉴基于Web请求代理策略基本思想的基础上,给出一个适用于数字化校园的简单的SSO系统实现方案。 2 基于临时代码的简单sso系统 2.1 系统访问方案 本方案主要针对数字化校园而设计,实现的关键在于临时码,原理如图1所示。 基本思路为: (1)用户登录到认证服务器后,认证服务器将为其生成一个临时码,并将此临时码与用户信息进行加密,存储到用户端Cookies中; (2)用户初次访问Web应用时,Web应用首先将提交过来的加密信息进行还原,并存储当前凭证(用户名与临时码); (3)Web应用将此凭证提交到认证服务器进行核实,若验证正确,则允许用户访问资源;否则删除(2)中存储的凭证,并作出相应动作; (4)当用户退出时,认证服务器将为其生成另一个临时码(更新临时码表); (5)当用户退出后再重新访问Web应用,在(3)中验证临时码时,临时码此时失效。 方案中临时码是用户状态的唯一标识,可以认为用户的临时码无改变的话,用户状态也没有改变。同时由于临时码是随机生成的,若能保证临时码的安全性,就能保证登录用户的合法性。 2.2 工作流 (1) 产品密码和临时码 用户提交用户名、密码和验证码(以图片形式随机生成)到认证服务器验证,信息提交采用隐藏表单域实现。若提交信息正确,认证服务器随机生成一个临时码,并将此临时码与用户信息进行加密,存储到用户端Cookies中;若否,则返回错误提示或按要求跳转。 (2) 第一次访问web应用程序的过程见图3 此时,Web应用域下的Cookies中没有记录用户信息和凭证,要求用户跳转到认证服务器确认用户是否已经登录。 (3) web应用防护 经历首次访问Web应用系统较为复杂的认证过程后,用户再次访问该Web应用的过程非常简单。此时,用户凭证在Web应用中存在,只需要向认证服务器进行凭证验证即可。 (4) 临时码改变的问题 当用户退出认证