單點登錄方法原理

單點登錄三個方法及原理:

  • 共享Session
  • 基于OpenId的單點登錄
  • 基于Cookie的OpenId存儲方案

共享Session

共享Session可謂是實現單點登錄最直接、最簡單的方式鼻疮。將用戶認證信息保存于Session中比规,即以Session內存儲的值為用戶憑證兴枯,這在單個站點內使用是很正常也很容易實現的,而在用戶驗證摆舟、用戶信息管理與業(yè)務應用分離的場景下即會遇到單點登錄的問題丰泊,在應用體系簡單汇恤,子系統(tǒng)很少的情況下,可以考慮采用Session共享的方法來處理這個問題访锻。

基于Redis的Session共享方案褪尝。將Session存儲于Redis上,然后將整個系統(tǒng)的全局Cookie Domain設置于頂級域名上期犬,這樣SessionID就能在各個子系統(tǒng)間共享河哑。

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

<%

 String JSESSIONID = request.getSession().getId();//獲取當前JSESSIONID (不管是從主域還是二級域訪問產生)

 Cookie cookie = new Cookie("JSESSIONID", JSESSIONID);
 cookie.setDomain(".test.com"); //關鍵在這里,將cookie設成主域名訪問龟虎,確保不同域之間都能獲取到該cookie的值璃谨,從而確保session統(tǒng)一
 response.addCookie(cookie);  //將cookie返回到客戶端

 request.getRequestDispatcher("indes.jsp").forward(request, response);

%>

基于OpenId的單點登錄

  • 當用戶第一次登錄時,將用戶名密碼發(fā)送給驗證服務鲤妥;
  • 驗證服務將用戶標識OpenId返回到客戶端佳吞;
  • 客戶端進行存儲;
  • 訪問子系統(tǒng)時旭斥,將OpenId發(fā)送到子系統(tǒng)容达;
  • 子系統(tǒng)將OpenId轉發(fā)到驗證服務;
  • 驗證服務將用戶認證信息返回給子系統(tǒng)垂券;
  • 子系統(tǒng)構建用戶驗證信息后將授權后的內容返回給客戶端花盐。

基于Cookie的OpenId存儲方案

  • 在提供驗證服務的站點里登錄;
  • 將OpenId寫入頂級域名Cookie里菇爪;
  • 訪問子系統(tǒng)(Cookie里帶有OpenId)
  • 子系統(tǒng)取出OpenId通過并向驗證服務發(fā)送OpenId
  • 返回用戶認證信息
  • 返回授權后的內容

B/S多域名環(huán)境下的單點登錄處理

在多個頂級域名的情況下算芯,我們將無法讓各個子系統(tǒng)的OpenId共享。處理B/S環(huán)境下的跨域問題凳宙,我們首先就應該想到JSONP的方案熙揍。

驗證步驟如下:

  • 用戶通過登錄子系統(tǒng)進行用戶登錄;
  • 用戶登錄子系統(tǒng)記錄了用戶的登錄狀態(tài)氏涩、OpenId等信息届囚;
  • 用戶使用業(yè)務子系統(tǒng)有梆;
  • 若用戶未登錄業(yè)務子系統(tǒng)則將用戶跳轉至用戶登錄子系統(tǒng);
  • 用戶子系統(tǒng)通過JSONP接口將用戶OpenId傳給業(yè)務子系統(tǒng)意系;
  • 業(yè)務子系統(tǒng)通過OpenId調用驗證服務泥耀;
  • 驗證服務返回認證信息、業(yè)務子系統(tǒng)構造用戶登錄憑證蛔添;(此時用戶客戶端已經與子業(yè)務系統(tǒng)的驗證信息已經一一對應)
  • 將用戶登錄結果返回用戶登錄子系統(tǒng)痰催,若成功登錄則將用戶跳轉回業(yè)務子系統(tǒng);
  • 將授權后的內容返回客戶端迎瞧;

安全問題

在整個開發(fā)過程初期夸溶,我們采用用戶表中紀錄一個OpenId字段來保存用戶OpenId,而這個機制下很明顯存在一些安全性凶硅、擴展性問題缝裁。這個擴展性問題主要體現在一個方面:OpenId的安全性和用戶體驗的矛盾。

整個單點登錄的機制決定了OpenId是會出現在客戶端的咏尝,所以OpenId需要有過期機制压语,假如用戶在一個終端登錄的話可以選擇在用戶每次登錄或者每次退出時刷新OpenId,而在多終端登錄的情況下就會出現矛盾:當一個終端刷新了OpenId之后其他終端將無法正常授權编检。而最終胎食,我采用了單用戶多OpenId的解決方案。每次用戶通過用戶名/密碼登錄時允懂,產生一個OpenId保存在Redis里厕怜,并且設定過期時間,這樣多個終端登錄就會有多個OpenId與之對應蕾总,不再會存在一個OpenId失效所有終端驗證都失效的情況粥航。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市生百,隨后出現的幾起案子递雀,更是在濱河造成了極大的恐慌,老刑警劉巖蚀浆,帶你破解...
    沈念sama閱讀 219,039評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件缀程,死亡現場離奇詭異,居然都是意外死亡市俊,警方通過查閱死者的電腦和手機杨凑,發(fā)現死者居然都...
    沈念sama閱讀 93,426評論 3 395
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來摆昧,“玉大人撩满,你說我怎么就攤上這事。” “怎么了伺帘?”我有些...
    開封第一講書人閱讀 165,417評論 0 356
  • 文/不壞的土叔 我叫張陵昭躺,是天一觀的道長。 經常有香客問我曼追,道長窍仰,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,868評論 1 295
  • 正文 為了忘掉前任礼殊,我火速辦了婚禮,結果婚禮上针史,老公的妹妹穿的比我還像新娘晶伦。我一直安慰自己,他們只是感情好啄枕,可當我...
    茶點故事閱讀 67,892評論 6 392
  • 文/花漫 我一把揭開白布婚陪。 她就那樣靜靜地躺著,像睡著了一般频祝。 火紅的嫁衣襯著肌膚如雪泌参。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,692評論 1 305
  • 那天常空,我揣著相機與錄音沽一,去河邊找鬼。 笑死漓糙,一個胖子當著我的面吹牛铣缠,可吹牛的內容都是我干的。 我是一名探鬼主播昆禽,決...
    沈念sama閱讀 40,416評論 3 419
  • 文/蒼蘭香墨 我猛地睜開眼蝗蛙,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了醉鳖?” 一聲冷哼從身側響起捡硅,我...
    開封第一講書人閱讀 39,326評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎盗棵,沒想到半個月后壮韭,有當地人在樹林里發(fā)現了一具尸體,經...
    沈念sama閱讀 45,782評論 1 316
  • 正文 獨居荒郊野嶺守林人離奇死亡漾根,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,957評論 3 337
  • 正文 我和宋清朗相戀三年泰涂,在試婚紗的時候發(fā)現自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片辐怕。...
    茶點故事閱讀 40,102評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡逼蒙,死狀恐怖,靈堂內的尸體忽然破棺而出寄疏,到底是詐尸還是另有隱情是牢,我是刑警寧澤僵井,帶...
    沈念sama閱讀 35,790評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站驳棱,受9級特大地震影響批什,放射性物質發(fā)生泄漏。R本人自食惡果不足惜社搅,卻給世界環(huán)境...
    茶點故事閱讀 41,442評論 3 331
  • 文/蒙蒙 一驻债、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧形葬,春花似錦合呐、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,996評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至猖腕,卻和暖如春拆祈,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背倘感。 一陣腳步聲響...
    開封第一講書人閱讀 33,113評論 1 272
  • 我被黑心中介騙來泰國打工放坏, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人侠仇。 一個月前我還...
    沈念sama閱讀 48,332評論 3 373
  • 正文 我出身青樓轻姿,卻偏偏與公主長得像,于是被迫代替她去往敵國和親逻炊。 傳聞我的和親對象是個殘疾皇子互亮,可洞房花燭夜當晚...
    茶點故事閱讀 45,044評論 2 355

推薦閱讀更多精彩內容