每年九月學(xué)工系統(tǒng)第一波流量高峰就來了。教學(xué)樓里到處是新生拿著手機問志愿者“迎新系統(tǒng)、學(xué)工系統(tǒng)、繳費平臺是一回事嗎為什么密碼規(guī)則都不一樣”旁邊輔導(dǎo)員也在翻口袋——獎助學(xué)金系統(tǒng)一套口令、心理測評系統(tǒng)一套口令、綜合測評系統(tǒng)又一套。這類場景幾乎每年都在高校信息部門重演也是“統(tǒng)一身份認證”最常被提上日程的導(dǎo)火索。所謂“一號通”本質(zhì)上就是讓全校師生只認一個主賬號、只在統(tǒng)一認證入口登錄一次就能帶著登錄狀態(tài)自由進出已接入的學(xué)工業(yè)務(wù)系統(tǒng)。這篇文章不以理論手冊為目標而是結(jié)合我實際參與某高校學(xué)工系統(tǒng)統(tǒng)一身份認證建設(shè)時的方案設(shè)計、技術(shù)選型、對接調(diào)試和上線后運維經(jīng)驗把“一號通”背后的原理和坑講清楚。1. 從“一堆賬號”到“一號通”學(xué)工系統(tǒng)為什么要動這個手術(shù)1.1 賬號密碼多到連輔導(dǎo)員都受不了從學(xué)生視角看一個在校生常用的賬號至少有這些學(xué)工系統(tǒng)、教務(wù)系統(tǒng)、圖書館系統(tǒng)、一卡通自助平臺、校園網(wǎng)認證、云盤、課程平臺。每套系統(tǒng)由不同廠商建設(shè)賬號密碼規(guī)則各不相同。有系統(tǒng)要求字母數(shù)字特殊字符有系統(tǒng)只認6位純數(shù)字有系統(tǒng)一年強制改一次密碼。密碼規(guī)則越復(fù)雜記不住的人越多結(jié)果是有人把密碼寫在本子上有人所有系統(tǒng)用同一個簡單密碼有人每學(xué)期第一件事就是去服務(wù)臺重置密碼。從輔導(dǎo)員角度看賬號問題帶來的負擔(dān)更隱蔽。獎助學(xué)金材料提交通常要登錄學(xué)工系統(tǒng)但需要先在校內(nèi)統(tǒng)一門戶認證再跳轉(zhuǎn)進業(yè)務(wù)頁面如果門戶會話過期填了一半的表單沒了學(xué)生就會反復(fù)來問。實踐里我們統(tǒng)計過某學(xué)年迎新季服務(wù)臺“忘記密碼”類工單占總工單量接近四成其中一半來自學(xué)工相關(guān)系統(tǒng)。這個數(shù)字看起來很小但每一張工單背后都是學(xué)生辦事的停頓感。統(tǒng)一身份認證要解決的正是這類由“身份碎片化”導(dǎo)致的重復(fù)勞動。真正容易忽略的是安全面同一個密碼在多系統(tǒng)復(fù)用后一旦某個老系統(tǒng)被攻擊拖庫攻擊者會拿賬號密碼去“撞”其他系統(tǒng)。學(xué)工系統(tǒng)里存著學(xué)生家庭情況、獎懲信息、資助記錄是高敏業(yè)務(wù)。把認證入口統(tǒng)一起來降低多口令記憶負擔(dān)同時減少跨系統(tǒng)弱口令復(fù)用這才是“一號通”真正的底層價值。1.2 統(tǒng)一身份認證到底在“統(tǒng)一”什么我經(jīng)常要跟業(yè)務(wù)部門解釋統(tǒng)一身份認證不是把所有業(yè)務(wù)系統(tǒng)合并成一個大系統(tǒng)也不是強制大家把數(shù)據(jù)庫賬號表交出來。它的核心是四件事。第一統(tǒng)一主賬號。每名師生在認證中心里只有一條身份記錄擁有一個全局唯一ID。業(yè)務(wù)系統(tǒng)可以繼續(xù)用自己的內(nèi)部賬號但必須與這個全局ID建立映射。第二統(tǒng)一登錄入口。瀏覽器或App里的登錄統(tǒng)一收斂到認證中心完成。業(yè)務(wù)系統(tǒng)不再各自輸入密碼而是識別“這個人已經(jīng)通過認證中心驗證過”直接放行。第三統(tǒng)一會話憑證。認證成功后在瀏覽器或客戶端里生成可跨系統(tǒng)識別的會話憑證。我訪問學(xué)工系統(tǒng)登錄一次再去資助系統(tǒng)、心理測評系統(tǒng)就不用重新輸密碼。這是“一號通”最直觀的體驗來源。第四統(tǒng)一審計入口。所有系統(tǒng)在認證環(huán)節(jié)產(chǎn)生的失敗、鎖定、風(fēng)險告警都從認證中心集中出日志。以前出安全問題要翻五個系統(tǒng)現(xiàn)在首頁看一張表。還有一個容易被忽略的邊界統(tǒng)一身份認證管的是“你是不是某某”不是“你能不能干某件事”。學(xué)工系統(tǒng)里的“輔導(dǎo)員只能看本學(xué)院學(xué)生”“資助專員才能查看貧困認定結(jié)果”屬于授權(quán)需要權(quán)限中心或業(yè)務(wù)系統(tǒng)自己的角色體系來實現(xiàn)。把認證和授權(quán)混在一起是不少學(xué)校踩坑的根源。2. 我理解的SSO核心組件與協(xié)議分工2.1 認證中心、票據(jù)、應(yīng)用客戶端三者怎么配合用門衛(wèi)來類比比較直觀。認證中心就是大樓一樓門衛(wèi)業(yè)務(wù)系統(tǒng)是樓里的各個辦公室。師生進門時門衛(wèi)驗一次身份發(fā)一張臨時出入證去財務(wù)辦公室、輔導(dǎo)員辦公室、圖書館辦公室都不用再驗身份出示出入證即可。如果出入證過期或丟失才需要回到門衛(wèi)處重新領(lǐng)。技術(shù)實現(xiàn)上最常見的是“重定向 票據(jù)校驗”模型。大致分六步用戶首次訪問學(xué)工系統(tǒng)的某個頁面應(yīng)用發(fā)現(xiàn)有本地會話就放行沒有的話把目標地址打包引導(dǎo)瀏覽器跳轉(zhuǎn)到認證中心登錄頁。用戶在認證中心輸入賬號密碼或其他憑證認證中心校驗成功后在認證中心域下種一個全局會話憑證CAS里叫TGTOIDC里叫ID Token/Refresh Token。認證中心生成一次性票據(jù)CAS的ST或OIDC的authorization code通過瀏覽器重定向帶回業(yè)務(wù)系統(tǒng)。業(yè)務(wù)系統(tǒng)拿到票據(jù)后不一定信任瀏覽器傳來的而是通過服務(wù)端向認證中心發(fā)起校驗請求換取該用戶的核心身份信息。認證中心校驗票據(jù)有效返回用戶ID、姓名、學(xué)工號等必要屬性。業(yè)務(wù)系統(tǒng)在本地建立自己的會話后續(xù)頁面訪問不再經(jīng)過認證中心直到本地會話超時或用戶主動退出。這個模型的關(guān)鍵是瀏覽器在業(yè)務(wù)系統(tǒng)和認證中心之間只傳遞一次性票據(jù)密碼不經(jīng)過業(yè)務(wù)系統(tǒng)票據(jù)用完即廢。我接入學(xué)工老系統(tǒng)時經(jīng)常跟廠商說不要再拿數(shù)據(jù)庫賬號表做“二次密碼校驗”那等于把統(tǒng)一認證繞回去了。真正的統(tǒng)一是讓每個應(yīng)用相信“認證中心說你是誰”這件事情。我們?yōu)槭裁醋越ㄕJ證中心而不是直接買一個現(xiàn)成的SaaS因為學(xué)工場景涉及大量校內(nèi)身份數(shù)據(jù)且需要跟教務(wù)、人事、一卡通等內(nèi)部系統(tǒng)做數(shù)據(jù)聯(lián)動私有化部署更可控。當(dāng)然很多廠商也有成熟的平臺產(chǎn)品但本質(zhì)上都逃不開上述“認證中心—票據(jù)—應(yīng)用客戶端”的角色分工。2.2 協(xié)議選型CAS、OIDC、SAML在學(xué)工場景里怎么挑協(xié)議選型是“一號通”項目的第一個大決策。學(xué)工系統(tǒng)生態(tài)里老系統(tǒng)多、新系統(tǒng)也多不存在一個協(xié)議包打天下。我偏好按場景混用但不混在一個應(yīng)用里。協(xié)議/框架典型形態(tài)主要特點學(xué)工場景適配CAS傳統(tǒng)Web應(yīng)用協(xié)議簡單票據(jù)機制成熟適合純?yōu)g覽器頁面老版學(xué)工系統(tǒng)、門戶網(wǎng)站常用仍需保留OAuth 2.0 / OIDCWeb、App、小程序支持授權(quán)碼、PKCE、Access Token適合移動端和API場景新系統(tǒng)、校內(nèi)移動辦公應(yīng)用強烈推薦SAML老牌企業(yè)級平臺XML斷言適合與外包廠商遺留平臺互通偶爾遇到建議做兼容適配不主動選為什么很多學(xué)校至今還用CAS因為歷史包袱。接入了幾十個老系統(tǒng)它們早就實現(xiàn)了CAS客戶端改造只需配置一下認證中心地址。CAS本身對單點登錄支持很成熟但面向App、小程序、前后端分離架構(gòu)時略顯吃力。OIDC則更現(xiàn)代原生支持移動端和API授權(quán)安全模型也更完善。我在設(shè)計時采取的是“核心協(xié)議OIDC 老系統(tǒng)CAS橋接”的混合方案。新接入的學(xué)工應(yīng)用優(yōu)先OIDC老系統(tǒng)能改CAS就改CAS不能改的認證中心側(cè)提供CAS協(xié)議適配端點。這樣做的好處是不會為了新協(xié)議把舊應(yīng)用全部重寫也能保住“一號通”的體驗一致性。還有一個常被問到的問題能不能用LDAP直接對接LDAP主要是目錄同步和統(tǒng)一認證的一種底層方式但它解決的是“賬號密碼驗證”不解決“瀏覽器免登跳轉(zhuǎn)”。如果所有應(yīng)用都直接連LDAP校驗密碼密碼依然會暴露給全部業(yè)務(wù)系統(tǒng)一旦某個系統(tǒng)被攻破密碼庫就泄漏了。所以LDAP可以做用戶目錄源卻不能替代SSO協(xié)議作為學(xué)工系統(tǒng)的統(tǒng)一認證入口。3. 學(xué)工系統(tǒng)的身份生命周期比企業(yè)SSO復(fù)雜在哪3.1 賬號狀態(tài)從新生未入校到離校歸檔每個狀態(tài)都要有歸屬企業(yè)的賬號生命周期通常很清晰入職創(chuàng)建、離職刪除。學(xué)校卻復(fù)雜得多。一個學(xué)生的狀態(tài)至少包括錄取待報到、新生待激活、在校正常、休學(xué)、復(fù)學(xué)、轉(zhuǎn)專業(yè)、保留學(xué)籍、退學(xué)、畢業(yè)、離校、校友。不同狀態(tài)對系統(tǒng)訪問權(quán)限完全不同。更麻煩的是新生在報到前可能就需要登錄迎新系統(tǒng)完成個人信息采集、宿舍床位選擇、繳費確認。這意味著“一號通”的賬號不能等到入學(xué)才建立而是招生錄取名單出來時就要預(yù)建檔產(chǎn)生預(yù)賬號。預(yù)賬號不能像正式在校生一樣放行全部權(quán)限但必須能登錄迎新相關(guān)應(yīng)用。這里要設(shè)計一個“未激活”狀態(tài)只能訪問迎新板塊激活后才變成正式身份。離校學(xué)生也要小心。學(xué)生畢業(yè)了學(xué)工系統(tǒng)里的歷史班級記錄、獎助學(xué)金材料還要被輔導(dǎo)員和審計查閱所以賬號不能刪除只能“歸檔”。歸檔賬號不能登錄日常業(yè)務(wù)但具備只讀查詢權(quán)限或者完全不登錄由業(yè)務(wù)系統(tǒng)使用歷史快照提供數(shù)據(jù)。我們在項目里把賬號狀態(tài)模型作為最重要的數(shù)據(jù)設(shè)計甚至比密碼策略更上心——因為狀態(tài)錯了權(quán)限就會錯。還有一種容易被忽略的情況休學(xué)學(xué)生。校園卡被停掉統(tǒng)一認證賬號如果也被停掉等學(xué)生復(fù)學(xué)時發(fā)現(xiàn)無法登錄又要去服務(wù)臺重置。更好的做法是“鎖定”而不是“刪除”并保留全局身份ID不變。復(fù)學(xué)審批通過后系統(tǒng)自動解鎖賬號、歷史數(shù)據(jù)、關(guān)聯(lián)消息全部恢復(fù)。我們后來在運維手冊里專門寫了一條學(xué)工系統(tǒng)的學(xué)籍異動推送必須同步觸發(fā)認證中心賬號狀態(tài)變更不能等信息部門人工處理。3.2 多源數(shù)據(jù)同步與“全局身份ID”的建立學(xué)工系統(tǒng)的身份數(shù)據(jù)不是憑空造的它依賴多個源頭教務(wù)系統(tǒng)提供學(xué)號和在讀狀態(tài)人事系統(tǒng)提供輔導(dǎo)員和行政老師信息招生系統(tǒng)提供錄取名單一卡通系統(tǒng)提供卡狀態(tài)宿舍管理系統(tǒng)提供住宿樓棟。這些系統(tǒng)的標識各不相同有人用學(xué)號有人用身份證號有人用一卡通卡號。如果不做映射就會出現(xiàn)“同一個人在三套系統(tǒng)里被當(dāng)成三個人”的悲劇。我在項目里用的辦法是建立一張“全局身份映射表”認證中心自己生成全局ID比如純數(shù)字序列或UUID再把每個業(yè)務(wù)系統(tǒng)的內(nèi)部賬號ID作為屬性關(guān)聯(lián)到該全局ID下。同步規(guī)則遵循主數(shù)據(jù)優(yōu)先以教務(wù)/研究生系統(tǒng)為學(xué)籍唯一權(quán)威源以人事系統(tǒng)為人事唯一權(quán)威源。數(shù)據(jù)同步采用實時消息定時對賬結(jié)合學(xué)籍異動消息立刻推送到認證中心并更新狀態(tài)每天凌晨做一次全量對賬發(fā)現(xiàn)差異后生成告警工單不自動覆蓋。為什么不能用身份證號當(dāng)全局ID因為歷史數(shù)據(jù)里確實存在空號、錯號留學(xué)生沒有本地身份證港澳臺學(xué)生證件類型復(fù)雜。用業(yè)務(wù)系統(tǒng)自帶學(xué)號也會出問題轉(zhuǎn)專業(yè)轉(zhuǎn)班級后學(xué)號可能保留但有些合并院校中學(xué)號會變更還有預(yù)科、專升本等特殊路徑學(xué)號可能重新生成。全局ID一旦確定終身不變只標志“身份的存在”不承載業(yè)務(wù)語義。這個設(shè)計在“一號通”后續(xù)對接數(shù)據(jù)中臺時幫了大忙后面所有系統(tǒng)只要關(guān)聯(lián)全局ID就可以匯總數(shù)據(jù)不會再出現(xiàn)對不上人的情況。4. “一號通”落地實施從賬號治理到老系統(tǒng)對接4.1 賬號清洗與激活讓每一條身份記錄可追溯真正動手前我強烈建議先做賬號盤點不要急著搭認證服務(wù)器。我們當(dāng)時從八個業(yè)務(wù)系統(tǒng)里導(dǎo)出了賬號表按身份證號、學(xué)號、姓名做初步匹配發(fā)現(xiàn)三類問題一是歷史離職人員和轉(zhuǎn)校生賬號沒有停用仍顯示正常二是同一學(xué)生因轉(zhuǎn)專業(yè)在不同系統(tǒng)里生成了兩條記錄三是不少賬號綁定的是已經(jīng)廢棄的手機號沒法做密保找回。這些問題不清理統(tǒng)一身份認證上線后會把原來的“隱形問題”變成“平臺上的顯性問題”。清洗工作按“匹配-合并-停用-補錄”四步走。先以教務(wù)數(shù)據(jù)為準把每名學(xué)生的唯一身份記錄建好然后合并同一人的多個賬號對無法匹配的賬號標記待核實核實確實不存在的賬號停用并歸檔。整個過程要有業(yè)務(wù)部門簽字確認尤其是獎助和宿舍數(shù)據(jù)避免誤刪。清洗之后是激活環(huán)節(jié)。老系統(tǒng)的賬號往往是管理員發(fā)初始密碼統(tǒng)一身份認證上線后我們改成“自助激活”模式新生在迎新頁面輸入錄取通知書編號和身份證后六位設(shè)置新密碼并綁定本人手機號教職工由人事入職流程觸發(fā)激活短信。初始密碼只能使用一次激活后立即失效。這么做的好處是認證中心里不會積壓一批長期沒人用但密碼可能被別人知道的“僵尸賬號”。運維上我們會盯一個指標——新生激活率第一年要求新生報到前激活率達到95%以上否則說明引導(dǎo)路徑有問題需要優(yōu)化。4.2 認證中心接入學(xué)工主流程的配置要點賬號和狀態(tài)就緒后接入工作反而更像“配參數(shù)”。最核心的是三件事。第一回調(diào)地址白名單。無論是CAS的service參數(shù)還是OIDC的redirect_uri必須做精確匹配。很多安全問題都出在回調(diào)地址過寬。學(xué)工系統(tǒng)的域名可能有好幾個門戶老域名、新域名、校內(nèi)測試域名每次都要在認證中心白名單里單獨維護不該用通配符懶省事。第二票據(jù)與會話有效期。這個配置直接影響體驗。票據(jù)有效期太短用戶填表隔了半小時就跳回登錄頁太長則安全風(fēng)險上升。我們的經(jīng)驗是單點登錄全局會話默認8小時業(yè)務(wù)系統(tǒng)本地會話默認30分鐘敏感操作獎助審批、離校確認單次會話15分鐘。超時后不要求整個門戶重新登錄只要求對該業(yè)務(wù)系統(tǒng)重新做一次身份確認。第三Cookie作用域和通信協(xié)議。瀏覽器里明文傳輸票據(jù)等同于裸奔所以所有回調(diào)地址和認證中心地址必須走HTTPS。Cookie的Domain不要隨手設(shè)置成根域尤其注意應(yīng)用自己的會話Cookie名不能和認證中心的Cookie重名否則就會出現(xiàn)下一節(jié)那種“登錄了就掉線”的怪問題。接入校內(nèi)移動辦公App時認證中心還需要暴露OIDC授權(quán)端點并通過App內(nèi)部的免密通道換取用戶身份。移動端場景下瀏覽器里的Cookie機制基本失效要靠Authorization Code PKCE流程。很多廠商把secret內(nèi)置到App里是不對的正確做法是App通過后端服務(wù)保存客戶端密鑰前端只發(fā)起授權(quán)請求。4.3 一次離校系統(tǒng)反復(fù)登錄失敗的排查全記錄這里說一個我印象很深的坑離校系統(tǒng)接好CAS后用戶從門戶進去點“離校事務(wù)辦理”馬上又彈回登錄頁反復(fù)循環(huán)。接口聯(lián)調(diào)時單點測試是好的門戶跳轉(zhuǎn)到認證中心后也能拿到登錄頁但在離校系統(tǒng)本地會話一直建立不起來。排查第一條線是看票證校驗。在認證中心日志里發(fā)現(xiàn)ticket確實被離校系統(tǒng)服務(wù)端請求校驗了而且校驗結(jié)果成功用戶屬性也正確返回。這就很奇怪服務(wù)端明明拿到了用戶信息為什么瀏覽器還是被重定向回登錄頁第二條線看應(yīng)用日志。離校系統(tǒng)的后臺日志顯示“session created”但下一條請求又找不到session。我讓廠商把Cookie抓出來發(fā)現(xiàn)認證中心和離校系統(tǒng)都叫“session_id”而且認證中心把Cookie的Domain寫成了父域離校系統(tǒng)自己的session Cookie則沒設(shè)Domain。瀏覽器按名字域管理Cookie兩個Cookie同名后面的覆蓋前面的導(dǎo)致用戶會話被反復(fù)“頂?shù)簟?。根因明確后修改也簡單把離校系統(tǒng)的會話Cookie名改成“l(fā)x_session_id”同時把認證中心的TGT Cookie限制在認證中心自有域名內(nèi)不做父域下發(fā)。改完再測登錄流程穩(wěn)定了。這條經(jīng)驗后來寫進了我們的對接規(guī)范里接入統(tǒng)一認證的應(yīng)用先自查會話Cookie命名和Domain不要使用和認證中心同名的常見名稱如果業(yè)務(wù)系統(tǒng)框架默認就必須改。還有一個小問題部分老系統(tǒng)沒有做“單點退出”。用戶從統(tǒng)一門戶退出后回到離校系統(tǒng)還能直接看到自己信息因為應(yīng)用本地會話沒被銷毀。單點退出的實現(xiàn)比登錄更麻煩CAS的SLO和OIDC的logout都依賴所有應(yīng)用配合。我們退而求其次——不在應(yīng)用本地做強制的同步銷毀而是在統(tǒng)一門戶的退出頁停留幾秒讓各個應(yīng)用收到退出通知后清掉本地會話。雖然不是百分之百實時但至少能避免“看似退出、實際還在登錄”的暴露。5. 從“能登錄”到“好用”體驗與安全的雙向平衡5.1 常見登錄方式在學(xué)工場景下怎么選“一號通”上線后登錄方式的選擇直接影響師生愿不愿意用。我們做過一期反饋學(xué)生最反感的是“密碼圖片驗證碼”雙重阻力因為圖片驗證碼在自研老系統(tǒng)里經(jīng)常模糊難認。而老師群體更在意速度和穩(wěn)定性不愿意在手機和電腦間來回切換。以下是我在學(xué)工場景里的建議登錄方式優(yōu)點缺點適用場景密碼 智能驗證碼通用性強老驗證碼體驗差默認兜底方案手機短信驗證碼無需記密碼找回快短信有成本可能被轟炸激活、找回、首次登錄掃碼登錄手機確認即可體驗順滑需要App或公眾號配合機房電腦、公共機房最適合校內(nèi)App免密辦公人群接受度高依賴第三方生態(tài)老師、輔導(dǎo)員使用頻率高生物識別體驗最好涉及隱私采集爭議不建議作為強制項僅限自助終端要注意“一號通”不等于“只有一種登錄方式”。統(tǒng)一認證中心要同時支持多因子疊加比如學(xué)生校外訪問時密碼登錄后要求小程序確認老師敏感模塊操作時需要短信二次確認。這些策略不是每個業(yè)務(wù)系統(tǒng)自己做而是認證中心發(fā)布時可配置的風(fēng)險規(guī)則業(yè)務(wù)系統(tǒng)只需要透傳一個“當(dāng)前操作是否需要二次認證”的參數(shù)即可。還有一類體驗優(yōu)化容易被忽視登錄后的無感跳轉(zhuǎn)。學(xué)工系統(tǒng)里的待辦往往分散在個人門戶、輔導(dǎo)員PDA、學(xué)工大屏等多個應(yīng)用。我們做了聚合待辦卡片學(xué)生從門戶點一個待辦帶著統(tǒng)一會話直達目標頁面目標頁面未接入統(tǒng)一認證時再由服務(wù)端代為處理后展示。這樣“一號通”的便捷感才真正落地。5.2 弱口令、異地登錄、高頻嘗試怎么防“號好用了”安全就不能省。統(tǒng)一身份認證平臺本身變成了全校最高價值的攻擊目標防護等級要比其他業(yè)務(wù)系統(tǒng)高一檔。第一道防線是弱口令治理。我們在認證中心密碼策略里內(nèi)置了常用弱密碼字典包括常見數(shù)字序列、學(xué)號后六位、姓名拼音加生日這些高頻組合。學(xué)生改密碼時會直接拒絕命中字典的新口令。密碼本身不能明文存儲用迭代次數(shù)足夠高的哈希算法保存首次激活時校驗新口令強度和是否與舊密碼復(fù)用。第二道防線是登錄風(fēng)險控制。賬號連續(xù)失敗5次鎖定15分鐘同IP短時間失敗次數(shù)超過一定閾值觸發(fā)驗證碼異地IP或深夜登錄要求短信/校內(nèi)App確認。規(guī)則可以在認證中心集中配置不需要每個業(yè)務(wù)系統(tǒng)重復(fù)實現(xiàn)。實測下來鎖定策略能擋住絕大多數(shù)暴力破解嘗試但也別設(shè)太死——比如宿舍里幾個同學(xué)共用同一出口IP導(dǎo)致IP一樣短時間內(nèi)有人輸錯密碼不能把整個樓層的學(xué)生都鎖了要按賬號維度而不是IP維度做嚴格限制。第三道防線是異常會話檢測。我們會在認證中心記錄登錄設(shè)備指紋和常用IP庫。用戶檢測到新的登錄設(shè)備時推送一條“你的統(tǒng)一身份賬號在新設(shè)備登錄”的提醒信息如果用戶不認可可以一鍵踢下線該會話并重置密碼。這套邏輯跟互聯(lián)網(wǎng)產(chǎn)品的“賬號安全中心”類似學(xué)工系統(tǒng)里的學(xué)生很快就能掌握。安全策略的設(shè)計還有一個原則不要在“登錄”這一下把所有安全手段都堆上去。頻繁讓學(xué)生做二次驗證會逼他們尋找繞過路徑。更好的方法是分級——默認密碼可登錄高風(fēng)險操作獎助金審核、離校信息修改、家庭困難認定再疊加一次短信確認或MFA。把驗證資源花在最需要的地方。6. 上線之后我建議留意的幾個運維細節(jié)6.1 監(jiān)控指標、日志審計與降級應(yīng)急統(tǒng)一身份認證上線不是終點真正考驗人的是持續(xù)運維。我們平時主要盯五類指標認證中心QPS、登錄成功率、認證平均耗時、密碼失敗次數(shù)和賬號鎖定量。高峰期選課、迎新、成績發(fā)布要提前壓測認證中心一般不會成為瓶頸但如果并發(fā)訪問量突然飆到日常十倍會話緩存、數(shù)據(jù)庫連接都要檢查。日志審計不能只在出問題時才看。統(tǒng)一認證記錄的是誰在什么時間用什么方式登錄了哪個系統(tǒng)這個數(shù)據(jù)是校內(nèi)安全事件調(diào)查的第一證據(jù)。至少要保證近180天登錄日志在線可查包括成功、失敗、鎖定、退出、票據(jù)簽發(fā)等全量事件。業(yè)務(wù)側(cè)配合上各接入應(yīng)用的服務(wù)端日志也要保存足夠長的時間不能只靠認證中心單方日志定位問題。降級方案是最容易被忽略的。認證中心一旦宕機所有接入系統(tǒng)都會面臨“無法登錄”的連帶故障。我們提前和業(yè)務(wù)廠商約定應(yīng)急模式認證中心不可用超過10分鐘啟用臨時登錄頁允許業(yè)務(wù)系統(tǒng)使用本地的賬號表做密碼校驗。這樣做犧牲了統(tǒng)一會話和統(tǒng)一審計但至少保證學(xué)生能登錄系統(tǒng)完成緊急辦事。應(yīng)急模式入口要嚴格限制并在日志中顯著標記事后復(fù)盤為什么要啟用、用了多久、哪些系統(tǒng)被臨時放開。注意降級本身也是安全事件的高危時段不能隨意放開。6.2 下一步演進從一號通到數(shù)據(jù)通、權(quán)限通統(tǒng)一身份認證跑穩(wěn)之后很多后續(xù)項目會自然依賴它。我建議團隊把身份數(shù)據(jù)當(dāng)成數(shù)字校園的“地基”來運營而不是只做一個登錄頁。比如學(xué)生畫像系統(tǒng)需要跨部門匯總考勤、成績、獎助、心理測評數(shù)據(jù)如果沒有全局ID光數(shù)據(jù)匹配就要消耗大量人工現(xiàn)在統(tǒng)一身份認證有了全局ID各系統(tǒng)數(shù)據(jù)直接關(guān)聯(lián)數(shù)據(jù)中臺的建設(shè)成本會明顯下降。權(quán)限體系也要往前看。學(xué)工系統(tǒng)里的角色很多輔導(dǎo)員、學(xué)院副書記、資助專員、心理健康教育專員、學(xué)生骨干?，F(xiàn)在不少學(xué)校這些角色在各個系統(tǒng)里各管一套管理員維護角色要反復(fù)配置。接下來可以把角色和權(quán)限模型往認證中心上層收構(gòu)建統(tǒng)一權(quán)限中心用RBAC/ABAC策略統(tǒng)一控制“誰能看、能改、能批”。認證中心只管身份權(quán)限中心管授權(quán)兩者配合才是我理解中的“一號通”長期形態(tài)。另外電子簽章、電子離校單、網(wǎng)上繳費、勤工助學(xué)工資單這類應(yīng)用如果都能基于統(tǒng)一身份認證的強會話能力和審計鏈路去做業(yè)務(wù)數(shù)據(jù)與身份數(shù)據(jù)的關(guān)聯(lián)會更加穩(wěn)妥。將來做新生數(shù)據(jù)分析、畢業(yè)生離校協(xié)同也都能沉淀成標準化服務(wù)。最后說一點個人體會。我在整個項目里最大的感悟是一號通不是單純的技術(shù)改造而是把散落在各個院系和廠商手里的身份語義重新整理了一遍。它真正的價值不在于“少輸入幾次密碼”而在于讓每一名師生背后的數(shù)據(jù)有機會被正確連接、被安全調(diào)度。如果正在規(guī)劃類似項目的朋友建議先從賬號數(shù)據(jù)狀態(tài)梳理開始不要被協(xié)議和架構(gòu)的術(shù)語嚇住把人的身份和狀態(tài)理清楚了后面的工作會順暢很多。