周游舟
(1.重庆城市职业学院信息与智能工程系, 重庆 402160; 2.永川智能制造公共实训中心, 重庆 402160)
随着信息技术的飞速发展,各企事业单位出现了许多不同的业务应用系统,如何在保证安全的前提下方便、快捷地管理用户和认证用户成为各单位信息化建设首要考虑的问题.采用单点登录机制,建立统一认证平台成为各单位解决统一授权、统一调度的常用方式.但是,统一授权、统一调度给用户登录带来便利的同时,也给企业的信息化建设带来了很大的维护工作量,很多单位不得不安排专人进行信息系统权限的维护,而且在权限的维护过程中还可能造成业务流程的临时中断,给员工转岗、调岗、离职等情况下的工作交接造成了很大麻烦.
目前国内外学者对统一认证平台的研究,主要集中在如何使用单点登录技术解决使用中的安全性和方便性问题、如何用管理制度解决员工之间的工作交接问题上,对如何用信息技术解决统一认证平台带来的业务管理问题研究较少.本研究对统一认证平台在实际应用中造成的维护工作量大的问题,针对不同应用场景设计出一种基于交接码的统一认证用户绑定模式,解决了统一认证平台中的用户工作交接问题.本设计在减轻统一认证平台维护的工作量的同时,提升了业务系统的安全性和相关流程连续性,具有较强的应用推广前景.
依托云计算、物联网与大数据等成熟技术体系,利用重庆市经信委内、重庆市内信息平台建设成果,解决现有业务系统体系窗口分散、内容支离、数据异构、环境独立和决策乏力等局限,实现流程统一规范、资源充分共享、业务有效协同、支撑分析能力强大的平台,是重庆市经济和信息化大数据应用平台(以下简称大数据平台)建设的初衷.然而,在统一认证平台实施之前,各机构、各职能部门已经存在相关业务系统;统一认证平台解决了各业务系统的多账号、多密码、多入口、安全审计等问题,同时也给各业务系统的正常运转带来了一定的困扰,主要体现在下面几个方面:
1)相对独立的用户权限及各自维护的系统管理人员.在大数据平台下,存在着几十个子平台和子系统,如智慧园区、智能制造、中小企业月报、产业技术创新等企业服务平台和专家评审、OA等内部办公系统,同时各系统平台都拥有各自一套相对独立的账号、权限体系,基本上由各信息系统的承建商自行设计与各系统管理员独立维护,统一改造账号权限体系的难度较大.
2)存在大量的老旧账号和新增注册账号.大数据平台下的中小企业公共服务平台、中小企业月报、智能制造平台等企业服务平台,已运行多年、积累大量信息不全的老旧账号,同时也有大量的新增注册账号,给账号的梳理和维护带来一定的困难.
3)企业账号信息变更频繁.因企业的账号信息与企业的生产经营相关,存在着一定量的人员流动和岗位调整,企业账号的联系人、联系电话、及联系邮箱经常变更成为事实,相应各业务系统的账号密码忘记成为常态.
4)管理部门组织架构及岗位人员调整.重庆市经济和信息化委员会下属机构及人员调整,导致各业务系统的账号调整困难.例如,岗位分工调整,过去由小王负责的A系统流程审批,现在交由小张负责,小王的其他工作不变动,小张继续完成小王的审批工作.
总之,伴随着各业务系统的需求变更以及各单位对用户管理需求的不断增长,一方面加重了各系统管理员的工作负担,另一方面也加大了各业务系统的对接难度.由此,需要尽快实现一个相对独立、安全高效、方便集成的解决方案.
本文中主要研究的是新旧系统接入统一认证平台的改造设计,对于新建业务系统来说,接入统一认证平台方式比较多,而且所用技术也相对成熟,本文中不单独说明.在老旧系统准备接入统一认证平台认证时,因系统已经稳定运行多时,存在很多重要的用户关联业务数据,而且个别老旧业务系统没有完善的文档,导致技术人员无法入手改造,更谈不上改造原有业务系统的认证方式.针对这样的情况,采用尽量不改变原有业务的情况下,设计出一种相对通用的统一认证接入方式来解决新旧系统的接入绑定问题.
本设计的原则是在不改变统一认证平台独立性的基础上,采用中央认证服务(central authentication service,CAS)的方式单点登录到各业务系统.并通过不改变各业务系统的原有的权限管理体系,保证各业务系统能独立运行的基础上,平稳过渡到统一认证平台体系中.也就是说重新设计开发统一认证对接功能模块,通过业务系统登录入口和单点登录入口并存的方式,逐步过渡到统一认证平台的单入口模式下.对接功能模块总体设计流程如图1所示.
图1 总体设计流程图
从图1中可以看出,业务系统对接统一认证平台,主要是通过业务系统账号绑定统一认证平台账号实现对接,主要流程步骤有以下几点:
1)用户登录统一认证平台.
用户如果没有统一认证平台账号,则先进行统一认证平台账号的注册和相应业务系统的开通申请;通过审批后,用户就可以通过证书登录、账号密码登录和短信验证码登录3种方式进行统一认证平台的登录验证.
2)单点登录过程验证.
平台管理员提前将业务系统名称、URL、IP等业务系统参数配置到统一认证平台中,当用户发起单点登录请求通过验证后,业务系统通过CAS获取统一认证平台账号信息,然后根据平台账号信息与绑定业务系统账号信息进行匹配,如果匹配上则跳转并登录到业务系统中,否则跳转到绑定业务系统账号页面.
3)绑定业务系统方式选择.
如果业务系统允许用户进行账号的注册,则显示新用户注册选项,否则用户只能通过老用户和交接用户的方式进行业务系统账号的绑定.如果业务系统未开通新用户注册,并且该用户又是新用户,则只能先联系业务系统管理员获得业务系统的登录账号和密码,再通过老用户绑定的方式进行用户绑定.
4)产生业务系统用户交接码.
当用户通过单点登录方式进入到业务系统后,用户可以在业务系统中生成具有有效期的用户交接码,一旦用户交接码被平台其他账户成功绑定,则该用户失去业务系统权限,需要再次绑定才能通过单点登录的方式进入该业务系统.
5)业务接收方绑定业务系统.
工作交接时,接收方通过统一认证平台进入业务系统时,需要选择“交接用户”选项进行交接码的录入,当输入的交接码通过业务系统验证后,会显示交出方的信息和绑定用户按钮.只有接收方用户在交接码有效期内确定绑定用户,业务交接双方才能完成业务系统的交接.
常规情况下,一个统一认证平台账号可以绑定多个业务系统,而每个业务系统账号只允许被一个统一认证平台账号绑定.特殊情况下,业务系统也可以开放一个业务系统账号被多个统一认证平台账号绑定的功能.
统一认证平台跳转到绑定业务系统用户界面的时候有3种用户类型选择,如图2所示.其中“我是老用户”,可以通过原有业务系统的用户名和密码进行用户绑定认证.“我是新用户”通过模拟原有业务系统的用户注册过程,然后再通过注册过程中设定的用户名和密码再进行自动绑定和认证登录.而“我是交接用户”则需要解决交接双方信息互通及安全方面的问题,所以交接用户功能需要单独设计.也就是说系统设计分为两大部分,一部分解决平台用户绑定业务系统用户的问题,另外一部分解决用户交接的问题.
图2 绑定用户类型选择
3.1 绑定用户设计通过单点登录方式从统一认证平台跳转到业务系统时,如果统一认证平台绑定了业务系统账号,则通过特定的自动登录方式进入业务系统,否则需要在业务系统中对统一认证平台账号进行业务系统账号的绑定.
在已绑定业务系统账户的情况,可以通过统一认证平台唯一ID标识找到绑定业务系统的用户登录账号等用户信息,并进行业务系统的自动登录操作.但是在没有绑定业务系统账号的情况下,则需要考虑用户注册、账号绑定等过程的停留时间和操作方式是否正常,以及单点登录跳转页面是否与绑定确认页面是同一个客户端来源等信息安全问题.针对以上情况的考虑,本设计通过系统端后台读取客户端信息结合数据库记录过程信息进行用户验证,如表1所示.
表1 绑定用户核心字段
从表1可以看出绑定用户表除了主键ID之外,主要分为统一认证平台信息、业务系统账户信息和绑定操作过程3部分内容.第一部分,统一认证平台信息部分主要有:sso_key是统一认证平台的账号唯一标识,sso_token是统一认证平台进行单点登录的唯一标识,以及本设计表1中未全部列出的其他用户信息,包括用户的姓名、性别、部门、头像、联系方式等.第二部分,业务系统账号信息部分主要有:user_id是业务系统账户的唯一标识,user_login_name业务系统的用户登录账号,user_login_password是用户注册时设定的用户密码或用户绑定账号时候进行验证的用户密码.其中,user_login_password根据不同的业务系统需要进行不同的处理,如果业务系统可以进行用户登录改造,则就不需要记录用户密码;同样,如果业务系统不能进行改造,则要对用户密码进行加密保存,然后在后期改造单点登录的时候可以采取模拟用户登录方式进行用户登录.第三部分,用户绑定操作过程,为了保障用户的绑定过程尽可能安全可靠,绑定过程除了在系统后端进行客户端验证之外,同时记录了用户绑定过程的两个核心时间点,sso_time是统一认证平台跳转到业务系统时的时间点,bind_time是用户完成注册(或者完成绑定操作)的时间点,后台通过一定算法对这两个时间点的合理性进行判断,如果判定绑定合法则设置绑定完成标志为成功状态,否则记录用户绑定失败.
3.2 用户交接设计在解决用户交接问题时,本团队尝试过“短信验证交接”“邮箱验证交接”等方式,但最终都被客户提出的各种问题否定,最后一致选定基于交接码的业务交接方式.在用户交接时,需要解决以下几个方面的问题.第一,原有业务系统的登录,因为长期通过统一认证平台的单点登录方式进行验证,已经忘记业务系统的用户名和密码;第二,原有业务系统所保存的用户资料可能与实际用户不一致;第三,梳理原有用户所具有的业务系统权限可能存在遗漏;第四,交接过程中需保证原有业务系统所办业务不被中断;第五,原有业务系统交接完成后,不再拥有登录权限;第六,业务系统交接给新用户后,新用户也有可能再交接给其他用户.
用户交接过程主要由产生交接码、绑定交接码和用户识别3部分组成,在这过程所产生的主要数据交互如表2所示.
表2 用户交接核心字段
1)生成交接码.
为了验证用户交接的真实性和安全性,本设计采用交接码由业务系统生成和验证.用户通过统一认证平台(或者原有业务系统的账号、密码)登录业务系统之后,在用户信息位置可以清楚地看到“用户交接”按钮.只要用户点击“用户交接”按钮,则进入用户交接码生成页面,可以直接看到生成的“交接码”和注意事项.同时在用户进行交接时,业务系统通过统一认证平台向交接双方用户发送短信提醒,防止账号被盗等非正常渠道进行用户交接.
如“表2 用户交接核心字段”所示,每个统一认证账户对应的业务系统用户同一时间只产生一条用户交接信息.主要有现有统一认证账户信息,包括old_sso_account、old_sso_key、old_sso_name、old_sso_time、status、sso_id、authcode等.其中,authcode是由一定算法产生的唯一交接码,并且与authcode_time(产生交接码的时间)有关.
2)绑定交接码.
当接收业务用户从统一认证平台进入业务系统后,首先业务系统会跳转到用户绑定页面,选择“我是交接用户”进入交接绑定页面.当接收业务用户输入原用户提供的交接码时,前端页面会进行简单规则的验证;当接收业务用户点击“确定”交接业务时,业务系统后台会根据交接码找到产生交接码的信息并进行特定规则的验证.主要读取old_sso_time、status、sso_id、authcode_time等信息进行验证,包括几个时间点产生间隔的合理性验证、验证码的正确性和完整性验证、通知信息的发送验证等.一旦验证成功,系统会更改原业务系统用户在表1中的绑定信息,并新建一条绑定信息,同时完善表2的信息和短信通知交接双方用户.
3.3 安全设计为了解决既要操作简单又要安全可控,保障用户交接过程是由交接双方本人操作(或者本人授权操作)的问题,本设计从以下几个方面来进行用户安全控制.
1)从登陆入口控制.
包括统一认证平台在内的客户端都采用CA认证方式,统一认证平台根据用户登录网络和设备进行判断,如果用户在办公区的常用计算机上进行操作,则启用普通的账号、密码验证,否则系统根据安全风险等级启用短信验证和USB Key认证.
2)从权限分配上进行控制.
统一认证平台除进行登陆验证之外,还要进行用户平台的分配控制,只有当用户有该业务系统的权限,才会生成唯一的单点登录链接.
3)系统之间进行验证.
统一认证平台一方面要验证业务系统的请求是否来源于配置的服务器,同时业务系统也会验证请求是否来源于统一认证平台,并且验证过程中涉及的重要验证信息还需要从系统后台的接口进行再次确认.
4)操作过程合理性验证.
在用户单点登录过程中,业务系统会记录用户每一次的操作时间和浏览器地址等过程信息,然后后台会进行综合计算用户的停留时间和操作过程是否与实际匹配,如果不匹配则提示操作失败信息,并记录日志用于事后定期分析.
4.1 业务系统关键参数配置
1)统一认证平台参数配置
sso:
#回调统一认证平台退出地址
ssoOutAddress: https://127.0.0.1∶8323/netcasso/api/logout
#回调统一认证平台获取信息根地址
ssoInerAddress: https://127.0.0.1∶8323/netcasso
#业务系统标识
clientId: HRMS
2)注册绑定交接关键过程过程参数设置.
public static final String HTTP_URL_USER="/oauth2/userInfo"; // 统一认证平台用户信息相对地址
public static final String HTTP_URL_AUTH="/oauth2/authorize"; // 统一认证平台用户授权相对地址
public static final String ACCESS_TOKEN=“access_token”; // 统一认证平台token标识
public static final String SSO_REGISTER=“register”; // 绑定注册交接页面控制器
public static final String BIND_URL="/register/bind"; // 绑定注册交接页面参数的一致性判断
public static final String SSO_OUT_KEY=“logout”; // 退出参数的一致性判断
public static final String SSO_OUT_URL="/hrms/login?action=logout"; // 前端页面退出标识
......
4.2 过滤器关键程序实现过程
// 对特定页面放行
StringBuffer redirectUri=httpServletRequest.getRequestURL();
if (redirectUri.indexOf(SSOConstants.SSO_REGISTER) > 1) {
return true; // 对绑定注册交接页面放行
}
......
// 判断当前用户是否登录,登录返回true, 否则判断access_token参数,并进行登录.
Subject subject=this.getSubject(request, response);
Principal, ?> principal=(Principal) subject.getPrincipal();
if (principal !=null && subject.isAuthenticated()) {
return true; // 对重复点击单点登录(已经登录业务系统)用户放行
}
......
// 根据用户唯一标识判断用户是否绑定,若没有绑定,则进行绑定初始化并跳转到绑定注册交接页面;否则自动登录并跳转业务系统首页.
User user=userService.getUserBySsoId(accountId);
if (user==null) {
UserSso csSSo=userService.initBind(json1, accountId, accessToken);
if (csSSo !=null) { //为了用户绑定安全,设置用户绑定动态参数
request.setAttribute(SSOConstants.SSO_BIND_KEY, csSSo.getSsoKey());
request.setAttribute(SSOConstants.SSO_BIND_ID, csSSo.getId());
return false; //设定请求参数标识后,再通过onAccessDenied方法跳转到指定地址
}
} else {
autoLogin(request, user.getUsername(), accessToken); //自动登录并跳转业务系统首页
return true; // 放行合法单点登录
}
......
4.3 用户交接关键程序实现过程
// 绑定是否有效判断
csSSo=this.getOne(bindId);
if (csSSo==null) {
return false; // 没有进行绑定初始化操作,返回失败
}
long nowSecond=new Date().getTime();
long ssoInitSecond=csSSo.getSsoTime().getTime();
long hour=(nowSecond - ssoInitSecond) / 1000 / 60 / 60;
if (hour >=UserService.BIND_OVER_TIME) {
return false; // 绑定过程超过正常操作时间,返回失败
}
if (csSSo.getBindOver()) {
return false; // 防止恶意操作,绑定过程必须按照程序设计步骤进行,否则返回失败
}
......
// 生成一个不重复的交接码
String authcode=null;
while (true) {
authcode=RandomStringUtils.randomAlphanumeric(10);
Where where=new Where();
where.addQl("authcode=:authcode").addParams(“authcode”, authcode);
List
if (null==ebdsMessageList || 0==ebdsMessageList.size()) {
return authcode;
}
}
......
// 交接超时判断
Date date=new Date();
date.setTime(date.getTime() - UserChangeService.OUTTIME * 1000 * 60);
return userChange.getCreateTime().getTime() < date.getTime();
......
绝大多数统一认证平台虽然解决了单点登录问题,但是针对用户岗位更换、分管业务更换等问题后期维护比较复杂,往往需要业务系统及统一认证平台管理员协助处理.针对这种情况,本研究分析了统一认证平台中用户工作交接情况的解决办法,提出了基于交接码的统一认证绑定设计方案,实现了在统一认证平台下的业务系统内的用户自主绑定及工作交接控制设计,并将该设计在重庆市经济和信息化大数据应用平台、智慧车辆检测平台等系统平台中进行实际应用.1年多的实际应用表明确实解决了统一认证平台下的工作交接繁琐、后期维护工作量大等问题.该设计适用于各行业信息化集成,具有较广的应用前景.对于设计中的业务系统改造推广等功能的完善是本研究的下一步工作.