周游舟

(1.重慶城市職業(yè)學院信息與智能工程系， 重慶 402160; 2.永川智能制造公共實訓中心， 重慶 402160)

0 引言

隨著信息技術的飛速發(fā)展，各企事業(yè)單位出現(xiàn)了許多不同的業(yè)務應用系統(tǒng)，如何在保證安全的前提下方便、快捷地管理用戶和認證用戶成為各單位信息化建設首要考慮的問題.采用單點登錄機制，建立統(tǒng)一認證平臺成為各單位解決統(tǒng)一授權、統(tǒng)一調度的常用方式.但是，統(tǒng)一授權、統(tǒng)一調度給用戶登錄帶來便利的同時，也給企業(yè)的信息化建設帶來了很大的維護工作量，很多單位不得不安排專人進行信息系統(tǒng)權限的維護，而且在權限的維護過程中還可能造成業(yè)務流程的臨時中斷，給員工轉崗、調崗、離職等情況下的工作交接造成了很大麻煩.

目前國內外學者對統(tǒng)一認證平臺的研究，主要集中在如何使用單點登錄技術解決使用中的安全性和方便性問題、如何用管理制度解決員工之間的工作交接問題上，對如何用信息技術解決統(tǒng)一認證平臺帶來的業(yè)務管理問題研究較少.本研究對統(tǒng)一認證平臺在實際應用中造成的維護工作量大的問題，針對不同應用場景設計出一種基于交接碼的統(tǒng)一認證用戶綁定模式，解決了統(tǒng)一認證平臺中的用戶工作交接問題.本設計在減輕統(tǒng)一認證平臺維護的工作量的同時，提升了業(yè)務系統(tǒng)的安全性和相關流程連續(xù)性，具有較強的應用推廣前景.

1 需求概述

依托云計算、物聯(lián)網(wǎng)與大數(shù)據(jù)等成熟技術體系，利用重慶市經(jīng)信委內、重慶市內信息平臺建設成果，解決現(xiàn)有業(yè)務系統(tǒng)體系窗口分散、內容支離、數(shù)據(jù)異構、環(huán)境獨立和決策乏力等局限，實現(xiàn)流程統(tǒng)一規(guī)范、資源充分共享、業(yè)務有效協(xié)同、支撐分析能力強大的平臺，是重慶市經(jīng)濟和信息化大數(shù)據(jù)應用平臺(以下簡稱大數(shù)據(jù)平臺)建設的初衷.然而，在統(tǒng)一認證平臺實施之前，各機構、各職能部門已經(jīng)存在相關業(yè)務系統(tǒng)；統(tǒng)一認證平臺解決了各業(yè)務系統(tǒng)的多賬號、多密碼、多入口、安全審計等問題，同時也給各業(yè)務系統(tǒng)的正常運轉帶來了一定的困擾，主要體現(xiàn)在下面幾個方面：

1)相對獨立的用戶權限及各自維護的系統(tǒng)管理人員.在大數(shù)據(jù)平臺下，存在著幾十個子平臺和子系統(tǒng)，如智慧園區(qū)、智能制造、中小企業(yè)月報、產(chǎn)業(yè)技術創(chuàng)新等企業(yè)服務平臺和專家評審、OA等內部辦公系統(tǒng)，同時各系統(tǒng)平臺都擁有各自一套相對獨立的賬號、權限體系，基本上由各信息系統(tǒng)的承建商自行設計與各系統(tǒng)管理員獨立維護，統(tǒng)一改造賬號權限體系的難度較大.

2)存在大量的老舊賬號和新增注冊賬號.大數(shù)據(jù)平臺下的中小企業(yè)公共服務平臺、中小企業(yè)月報、智能制造平臺等企業(yè)服務平臺，已運行多年、積累大量信息不全的老舊賬號，同時也有大量的新增注冊賬號，給賬號的梳理和維護帶來一定的困難.

3)企業(yè)賬號信息變更頻繁.因企業(yè)的賬號信息與企業(yè)的生產(chǎn)經(jīng)營相關，存在著一定量的人員流動和崗位調整，企業(yè)賬號的聯(lián)系人、聯(lián)系電話、及聯(lián)系郵箱經(jīng)常變更成為事實，相應各業(yè)務系統(tǒng)的賬號密碼忘記成為常態(tài).

4)管理部門組織架構及崗位人員調整.重慶市經(jīng)濟和信息化委員會下屬機構及人員調整，導致各業(yè)務系統(tǒng)的賬號調整困難.例如，崗位分工調整，過去由小王負責的A系統(tǒng)流程審批，現(xiàn)在交由小張負責，小王的其他工作不變動，小張繼續(xù)完成小王的審批工作.

總之，伴隨著各業(yè)務系統(tǒng)的需求變更以及各單位對用戶管理需求的不斷增長，一方面加重了各系統(tǒng)管理員的工作負擔，另一方面也加大了各業(yè)務系統(tǒng)的對接難度.由此，需要盡快實現(xiàn)一個相對獨立、安全高效、方便集成的解決方案.

2 總體設計

本文中主要研究的是新舊系統(tǒng)接入統(tǒng)一認證平臺的改造設計，對于新建業(yè)務系統(tǒng)來說，接入統(tǒng)一認證平臺方式比較多，而且所用技術也相對成熟，本文中不單獨說明.在老舊系統(tǒng)準備接入統(tǒng)一認證平臺認證時，因系統(tǒng)已經(jīng)穩(wěn)定運行多時，存在很多重要的用戶關聯(lián)業(yè)務數(shù)據(jù)，而且個別老舊業(yè)務系統(tǒng)沒有完善的文檔，導致技術人員無法入手改造，更談不上改造原有業(yè)務系統(tǒng)的認證方式.針對這樣的情況，采用盡量不改變原有業(yè)務的情況下，設計出一種相對通用的統(tǒng)一認證接入方式來解決新舊系統(tǒng)的接入綁定問題.

本設計的原則是在不改變統(tǒng)一認證平臺獨立性的基礎上，采用中央認證服務(central authentication service,CAS)的方式單點登錄到各業(yè)務系統(tǒng).并通過不改變各業(yè)務系統(tǒng)的原有的權限管理體系，保證各業(yè)務系統(tǒng)能獨立運行的基礎上，平穩(wěn)過渡到統(tǒng)一認證平臺體系中.也就是說重新設計開發(fā)統(tǒng)一認證對接功能模塊，通過業(yè)務系統(tǒng)登錄入口和單點登錄入口并存的方式，逐步過渡到統(tǒng)一認證平臺的單入口模式下.對接功能模塊總體設計流程如圖1所示.

圖1 總體設計流程圖

從圖1中可以看出，業(yè)務系統(tǒng)對接統(tǒng)一認證平臺，主要是通過業(yè)務系統(tǒng)賬號綁定統(tǒng)一認證平臺賬號實現(xiàn)對接，主要流程步驟有以下幾點：

1)用戶登錄統(tǒng)一認證平臺.

用戶如果沒有統(tǒng)一認證平臺賬號，則先進行統(tǒng)一認證平臺賬號的注冊和相應業(yè)務系統(tǒng)的開通申請；通過審批后，用戶就可以通過證書登錄、賬號密碼登錄和短信驗證碼登錄3種方式進行統(tǒng)一認證平臺的登錄驗證.

2)單點登錄過程驗證.

平臺管理員提前將業(yè)務系統(tǒng)名稱、URL、IP等業(yè)務系統(tǒng)參數(shù)配置到統(tǒng)一認證平臺中，當用戶發(fā)起單點登錄請求通過驗證后，業(yè)務系統(tǒng)通過CAS獲取統(tǒng)一認證平臺賬號信息，然后根據(jù)平臺賬號信息與綁定業(yè)務系統(tǒng)賬號信息進行匹配，如果匹配上則跳轉并登錄到業(yè)務系統(tǒng)中，否則跳轉到綁定業(yè)務系統(tǒng)賬號頁面.

3)綁定業(yè)務系統(tǒng)方式選擇.

如果業(yè)務系統(tǒng)允許用戶進行賬號的注冊，則顯示新用戶注冊選項，否則用戶只能通過老用戶和交接用戶的方式進行業(yè)務系統(tǒng)賬號的綁定.如果業(yè)務系統(tǒng)未開通新用戶注冊，并且該用戶又是新用戶，則只能先聯(lián)系業(yè)務系統(tǒng)管理員獲得業(yè)務系統(tǒng)的登錄賬號和密碼，再通過老用戶綁定的方式進行用戶綁定.

4)產(chǎn)生業(yè)務系統(tǒng)用戶交接碼.

當用戶通過單點登錄方式進入到業(yè)務系統(tǒng)后，用戶可以在業(yè)務系統(tǒng)中生成具有有效期的用戶交接碼，一旦用戶交接碼被平臺其他賬戶成功綁定，則該用戶失去業(yè)務系統(tǒng)權限，需要再次綁定才能通過單點登錄的方式進入該業(yè)務系統(tǒng).

5)業(yè)務接收方綁定業(yè)務系統(tǒng).

工作交接時，接收方通過統(tǒng)一認證平臺進入業(yè)務系統(tǒng)時，需要選擇“交接用戶”選項進行交接碼的錄入，當輸入的交接碼通過業(yè)務系統(tǒng)驗證后，會顯示交出方的信息和綁定用戶按鈕.只有接收方用戶在交接碼有效期內確定綁定用戶，業(yè)務交接雙方才能完成業(yè)務系統(tǒng)的交接.

常規(guī)情況下，一個統(tǒng)一認證平臺賬號可以綁定多個業(yè)務系統(tǒng)，而每個業(yè)務系統(tǒng)賬號只允許被一個統(tǒng)一認證平臺賬號綁定.特殊情況下，業(yè)務系統(tǒng)也可以開放一個業(yè)務系統(tǒng)賬號被多個統(tǒng)一認證平臺賬號綁定的功能.

3 詳細設計

統(tǒng)一認證平臺跳轉到綁定業(yè)務系統(tǒng)用戶界面的時候有3種用戶類型選擇，如圖2所示.其中“我是老用戶”，可以通過原有業(yè)務系統(tǒng)的用戶名和密碼進行用戶綁定認證.“我是新用戶”通過模擬原有業(yè)務系統(tǒng)的用戶注冊過程，然后再通過注冊過程中設定的用戶名和密碼再進行自動綁定和認證登錄.而“我是交接用戶”則需要解決交接雙方信息互通及安全方面的問題，所以交接用戶功能需要單獨設計.也就是說系統(tǒng)設計分為兩大部分，一部分解決平臺用戶綁定業(yè)務系統(tǒng)用戶的問題，另外一部分解決用戶交接的問題.

圖2 綁定用戶類型選擇

3.1 綁定用戶設計通過單點登錄方式從統(tǒng)一認證平臺跳轉到業(yè)務系統(tǒng)時，如果統(tǒng)一認證平臺綁定了業(yè)務系統(tǒng)賬號，則通過特定的自動登錄方式進入業(yè)務系統(tǒng)，否則需要在業(yè)務系統(tǒng)中對統(tǒng)一認證平臺賬號進行業(yè)務系統(tǒng)賬號的綁定.

在已綁定業(yè)務系統(tǒng)賬戶的情況，可以通過統(tǒng)一認證平臺唯一ID標識找到綁定業(yè)務系統(tǒng)的用戶登錄賬號等用戶信息，并進行業(yè)務系統(tǒng)的自動登錄操作.但是在沒有綁定業(yè)務系統(tǒng)賬號的情況下，則需要考慮用戶注冊、賬號綁定等過程的停留時間和操作方式是否正常，以及單點登錄跳轉頁面是否與綁定確認頁面是同一個客戶端來源等信息安全問題.針對以上情況的考慮，本設計通過系統(tǒng)端后臺讀取客戶端信息結合數(shù)據(jù)庫記錄過程信息進行用戶驗證，如表1所示.

表1 綁定用戶核心字段

從表1可以看出綁定用戶表除了主鍵ID之外，主要分為統(tǒng)一認證平臺信息、業(yè)務系統(tǒng)賬戶信息和綁定操作過程3部分內容.第一部分，統(tǒng)一認證平臺信息部分主要有：sso_key是統(tǒng)一認證平臺的賬號唯一標識，sso_token是統(tǒng)一認證平臺進行單點登錄的唯一標識，以及本設計表1中未全部列出的其他用戶信息，包括用戶的姓名、性別、部門、頭像、聯(lián)系方式等.第二部分，業(yè)務系統(tǒng)賬號信息部分主要有：user_id是業(yè)務系統(tǒng)賬戶的唯一標識，user_login_name業(yè)務系統(tǒng)的用戶登錄賬號，user_login_password是用戶注冊時設定的用戶密碼或用戶綁定賬號時候進行驗證的用戶密碼.其中，user_login_password根據(jù)不同的業(yè)務系統(tǒng)需要進行不同的處理，如果業(yè)務系統(tǒng)可以進行用戶登錄改造，則就不需要記錄用戶密碼；同樣，如果業(yè)務系統(tǒng)不能進行改造，則要對用戶密碼進行加密保存，然后在后期改造單點登錄的時候可以采取模擬用戶登錄方式進行用戶登錄.第三部分，用戶綁定操作過程，為了保障用戶的綁定過程盡可能安全可靠，綁定過程除了在系統(tǒng)后端進行客戶端驗證之外，同時記錄了用戶綁定過程的兩個核心時間點，sso_time是統(tǒng)一認證平臺跳轉到業(yè)務系統(tǒng)時的時間點，bind_time是用戶完成注冊(或者完成綁定操作)的時間點，后臺通過一定算法對這兩個時間點的合理性進行判斷，如果判定綁定合法則設置綁定完成標志為成功狀態(tài)，否則記錄用戶綁定失敗.

3.2 用戶交接設計在解決用戶交接問題時，本團隊嘗試過“短信驗證交接”“郵箱驗證交接”等方式，但最終都被客戶提出的各種問題否定，最后一致選定基于交接碼的業(yè)務交接方式.在用戶交接時，需要解決以下幾個方面的問題.第一，原有業(yè)務系統(tǒng)的登錄，因為長期通過統(tǒng)一認證平臺的單點登錄方式進行驗證，已經(jīng)忘記業(yè)務系統(tǒng)的用戶名和密碼；第二，原有業(yè)務系統(tǒng)所保存的用戶資料可能與實際用戶不一致；第三，梳理原有用戶所具有的業(yè)務系統(tǒng)權限可能存在遺漏；第四，交接過程中需保證原有業(yè)務系統(tǒng)所辦業(yè)務不被中斷；第五，原有業(yè)務系統(tǒng)交接完成后，不再擁有登錄權限；第六，業(yè)務系統(tǒng)交接給新用戶后，新用戶也有可能再交接給其他用戶.

用戶交接過程主要由產(chǎn)生交接碼、綁定交接碼和用戶識別3部分組成，在這過程所產(chǎn)生的主要數(shù)據(jù)交互如表2所示.

表2 用戶交接核心字段

1)生成交接碼.

為了驗證用戶交接的真實性和安全性，本設計采用交接碼由業(yè)務系統(tǒng)生成和驗證.用戶通過統(tǒng)一認證平臺(或者原有業(yè)務系統(tǒng)的賬號、密碼)登錄業(yè)務系統(tǒng)之后，在用戶信息位置可以清楚地看到“用戶交接”按鈕.只要用戶點擊“用戶交接”按鈕，則進入用戶交接碼生成頁面，可以直接看到生成的“交接碼”和注意事項.同時在用戶進行交接時，業(yè)務系統(tǒng)通過統(tǒng)一認證平臺向交接雙方用戶發(fā)送短信提醒，防止賬號被盜等非正常渠道進行用戶交接.

如“表2 用戶交接核心字段”所示，每個統(tǒng)一認證賬戶對應的業(yè)務系統(tǒng)用戶同一時間只產(chǎn)生一條用戶交接信息.主要有現(xiàn)有統(tǒng)一認證賬戶信息，包括old_sso_account、old_sso_key、old_sso_name、old_sso_time、status、sso_id、authcode等.其中，authcode是由一定算法產(chǎn)生的唯一交接碼，并且與authcode_time(產(chǎn)生交接碼的時間)有關.

2)綁定交接碼.

當接收業(yè)務用戶從統(tǒng)一認證平臺進入業(yè)務系統(tǒng)后，首先業(yè)務系統(tǒng)會跳轉到用戶綁定頁面，選擇“我是交接用戶”進入交接綁定頁面.當接收業(yè)務用戶輸入原用戶提供的交接碼時，前端頁面會進行簡單規(guī)則的驗證；當接收業(yè)務用戶點擊“確定”交接業(yè)務時，業(yè)務系統(tǒng)后臺會根據(jù)交接碼找到產(chǎn)生交接碼的信息并進行特定規(guī)則的驗證.主要讀取old_sso_time、status、sso_id、authcode_time等信息進行驗證，包括幾個時間點產(chǎn)生間隔的合理性驗證、驗證碼的正確性和完整性驗證、通知信息的發(fā)送驗證等.一旦驗證成功，系統(tǒng)會更改原業(yè)務系統(tǒng)用戶在表1中的綁定信息，并新建一條綁定信息，同時完善表2的信息和短信通知交接雙方用戶.

3.3 安全設計為了解決既要操作簡單又要安全可控，保障用戶交接過程是由交接雙方本人操作(或者本人授權操作)的問題，本設計從以下幾個方面來進行用戶安全控制.

1)從登陸入口控制.

包括統(tǒng)一認證平臺在內的客戶端都采用CA認證方式，統(tǒng)一認證平臺根據(jù)用戶登錄網(wǎng)絡和設備進行判斷，如果用戶在辦公區(qū)的常用計算機上進行操作，則啟用普通的賬號、密碼驗證，否則系統(tǒng)根據(jù)安全風險等級啟用短信驗證和USB Key認證.

2)從權限分配上進行控制.

統(tǒng)一認證平臺除進行登陸驗證之外，還要進行用戶平臺的分配控制，只有當用戶有該業(yè)務系統(tǒng)的權限，才會生成唯一的單點登錄鏈接.

3)系統(tǒng)之間進行驗證.

統(tǒng)一認證平臺一方面要驗證業(yè)務系統(tǒng)的請求是否來源于配置的服務器，同時業(yè)務系統(tǒng)也會驗證請求是否來源于統(tǒng)一認證平臺，并且驗證過程中涉及的重要驗證信息還需要從系統(tǒng)后臺的接口進行再次確認.

4)操作過程合理性驗證.

在用戶單點登錄過程中，業(yè)務系統(tǒng)會記錄用戶每一次的操作時間和瀏覽器地址等過程信息，然后后臺會進行綜合計算用戶的停留時間和操作過程是否與實際匹配，如果不匹配則提示操作失敗信息，并記錄日志用于事后定期分析.

4 系統(tǒng)實現(xiàn)

4.1 業(yè)務系統(tǒng)關鍵參數(shù)配置

1)統(tǒng)一認證平臺參數(shù)配置

sso:

#回調統(tǒng)一認證平臺退出地址

ssoOutAddress: https://127.0.0.1∶8323/netcasso/api/logout

#回調統(tǒng)一認證平臺獲取信息根地址

ssoInerAddress: https://127.0.0.1∶8323/netcasso

#業(yè)務系統(tǒng)標識

clientId: HRMS

2)注冊綁定交接關鍵過程過程參數(shù)設置.

public static final String HTTP_URL_USER="/oauth2/userInfo"; // 統(tǒng)一認證平臺用戶信息相對地址

public static final String HTTP_URL_AUTH="/oauth2/authorize"; // 統(tǒng)一認證平臺用戶授權相對地址

public static final String ACCESS_TOKEN=“access_token”; // 統(tǒng)一認證平臺token標識

public static final String SSO_REGISTER=“register”; // 綁定注冊交接頁面控制器

public static final String BIND_URL="/register/bind"; // 綁定注冊交接頁面參數(shù)的一致性判斷

public static final String SSO_OUT_KEY=“l(fā)ogout”; // 退出參數(shù)的一致性判斷

public static final String SSO_OUT_URL="/hrms/login?action=logout"; // 前端頁面退出標識

......

4.2 過濾器關鍵程序實現(xiàn)過程

// 對特定頁面放行

StringBuffer redirectUri=httpServletRequest.getRequestURL();

if (redirectUri.indexOf(SSOConstants.SSO_REGISTER) > 1) {

return true; // 對綁定注冊交接頁面放行

}

......

// 判斷當前用戶是否登錄，登錄返回true, 否則判斷access_token參數(shù)，并進行登錄.

Subject subject=this.getSubject(request, response);

Principal principal=(Principal) subject.getPrincipal();

if (principal !=null && subject.isAuthenticated()) {

return true; // 對重復點擊單點登錄(已經(jīng)登錄業(yè)務系統(tǒng))用戶放行

}

......

// 根據(jù)用戶唯一標識判斷用戶是否綁定，若沒有綁定，則進行綁定初始化并跳轉到綁定注冊交接頁面；否則自動登錄并跳轉業(yè)務系統(tǒng)首頁.

User user=userService.getUserBySsoId(accountId);

if (user==null) {

UserSso csSSo=userService.initBind(json1, accountId, accessToken);

if (csSSo !=null) { //為了用戶綁定安全，設置用戶綁定動態(tài)參數(shù)

request.setAttribute(SSOConstants.SSO_BIND_KEY, csSSo.getSsoKey());

request.setAttribute(SSOConstants.SSO_BIND_ID, csSSo.getId());

return false; //設定請求參數(shù)標識后，再通過onAccessDenied方法跳轉到指定地址

}

} else {

autoLogin(request, user.getUsername(), accessToken); //自動登錄并跳轉業(yè)務系統(tǒng)首頁

return true; // 放行合法單點登錄

}

......

4.3 用戶交接關鍵程序實現(xiàn)過程

// 綁定是否有效判斷

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 ebdsMessageList=userSsoChangeRepository.findAll(where);

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();

......

5 總結

絕大多數(shù)統(tǒng)一認證平臺雖然解決了單點登錄問題，但是針對用戶崗位更換、分管業(yè)務更換等問題后期維護比較復雜，往往需要業(yè)務系統(tǒng)及統(tǒng)一認證平臺管理員協(xié)助處理.針對這種情況，本研究分析了統(tǒng)一認證平臺中用戶工作交接情況的解決辦法，提出了基于交接碼的統(tǒng)一認證綁定設計方案，實現(xiàn)了在統(tǒng)一認證平臺下的業(yè)務系統(tǒng)內的用戶自主綁定及工作交接控制設計，并將該設計在重慶市經(jīng)濟和信息化大數(shù)據(jù)應用平臺、智慧車輛檢測平臺等系統(tǒng)平臺中進行實際應用.1年多的實際應用表明確實解決了統(tǒng)一認證平臺下的工作交接繁瑣、后期維護工作量大等問題.該設計適用于各行業(yè)信息化集成，具有較廣的應用前景.對于設計中的業(yè)務系統(tǒng)改造推廣等功能的完善是本研究的下一步工作.