單點登陸sso原理

http://patann.blog.163.com/blog/static/46849990201032511331328/

在結構設計上覆用性是一個很重要的特徵，昨天半夜我發的系統地非侵入性也是很重要的，有同志邀我看看他的SSO系統，不過看後都我以爲不甚滿意，若是要服 用的話須要把分散的代碼一點點摳出來，而後通過反覆的修改調試後才能在新的系統中使用，那位老兄的SSO系統功能可能確實強大，並且還用了新技術，不過在 複用性上我看仍是沒有擺脫集成上的痛苦，做過系統集成的同窗們確定對此深有感觸。

昨天才批判了不少同窗寫東西語焉不詳，結果回頭就本身給了自 己一耳巴子，上幾篇關於SSO的描述都不夠詳細，因而這裏在手把手系列裏咱們來一塊兒看看如何設計一個高度可服用的SSO模塊，這裏咱們假設全部的站點都使 用.NET，由於成熟的SSO須要和採用各類不一樣技術的站點之間實現SSO，因而有JAVA,PHP,COM+,.NET多種形式的PSO模塊。這裏咱們 精力有限，因此先假設都用.NET，若是你會JAVA也能夠本身用java來實現PSO。

通常來講單點認證都須要兩端來完成，在認證中心端的咱們稱之爲SSO，在網站端的模塊咱們稱之爲PSO。兩個模塊之間採用二次重定向技術來實現同步兩端票據的方式來實現單點登錄

首先咱們就來看看這兩個模塊式如何配合來完成單點認證的

第一個場景是用戶首先訪問認證中心登錄再去進入成員網站的狀況：

首 先是登錄後產生一個SSO的票據，這個票據是最重要的，由於它是決定用戶是否登錄的關鍵。這個票據能夠是Cookie,也能夠是Session,我比較傾 向於Cookie，由於如今有3DES加密，加密後篡改Cookie幾乎成爲不可能，因此不管是對於服務器負擔來講仍是安全性都是Cookie比較好，可 能人認爲萬一不支持Cookie呢，不過我想Demo應該沒問題吧，大不了我設計成兩個都支持：}，

PS，爲何不用非對稱加密？其實那個效率不高，3DES的安全性已經足夠了，至少如今尚未人宣稱能破解

在 登錄後就能夠通知用戶你已經登錄了，如今你能夠去訪問成員站點了，這個時候用戶點擊了成員站點的URL，進去了，這個時候首先就須要接受PSO組件的盤 查，你有沒有PSO的票據呢？很顯然是沒有的，因此這個時候請求就被Redirect回了認證中心，認證中心檢查用戶已經有了SSO的票據了，認爲用戶已 經登陸了，就把用戶的SSO票據附加在URL後邊而後Redirect回成員站點，成員站點的PSO這個時候獲取到了SSO票據，因而知道了用戶已經在認 證端登陸了，因而就建立一個PSO票據，而後返回給用戶他所請求的內容。因此咱們來看看其實PSO的邏輯更加複雜一點。

SSO的邏輯：

PSO的邏輯：

這裏咱們能夠看到其實兩個模塊的功能都不算複雜，這裏存在幾個現實的問題，第一個是加密問題，票據須要加密，傳輸的URL也須要加密。

還 有一個就是上一次我上篇文章裏說的，在SSO把票據經過URL發送給PSO的時候，若是咱們可以截獲這個URL，無論他加沒有加密，在下一次咱們直接用這 個URL去訪問站點的時候由於已經包含SSO票據了，因此PSO會認爲已經登錄了而直接產生PSO票據而後就讓用戶進去了，這顯然是一個漏洞。因此呢，我 們須要在這裏給這個URL加一點鹽值（所謂鹽值其實就是加點料），咱們經過在URL里加入時間戳來讓這個URL具有時間限制，這個樣子URL具有失效期， 過了這個時間即便截獲到了這個URL也徹底沒有做用了。