在沒有wif之前,我們在構建我們的應用程式時,往往都會設計自己的使用者庫和驗證邏輯,比如給公司開發乙個中文cms系統和乙個英文的電子商務系統(由於各種原因比如兩個專案是不同軟體公司設計的,總之兩個系統未能整合在一起),而這兩個系統的後台管理員理論上是有可能共享的,因為後台操作只會限定在公司內部成員.甚至將來還會繼續開發其它的應用系統...
面對這樣不尷不尬的情景,乙個經典的作法是給這些系統額外的設計單點登入.
說到單點登入,不得不說的是乙個一致的身份驗證策略設計往往只有在若干安全領域專家輔助時才能完成.
如果公司沒有超強的安全領域知識積累,設計的sso將是脆弱的,隨著時間的推移,一些不合理的設計最終將成為擴充套件的瓶頸! 這些感受我想很多人都有過.
以上糟糕的情形還是被微軟看出來了,終於,他們集結很多業界安全大師設計了一套全新的基於宣告的新訪問平台,wif就是此平台元件之一(其它兩個是adfs v2和windows cardspace).
乙個貌似很熟悉的名詞"基於宣告"展現了一種新的方案,下面來形象的解釋下wif的驗證流程.
以購買機票的流程來解釋:
有一天你要去買機票(訪問信賴方rp系統),
售票阿姨必須要你出示使用者名稱,生日,住址(宣告),同時提供的資訊必須是這位阿姨可以相信的,你不能自己隨便寫乙個,很自然的你想到了身份證(安全令牌 ps:身份證是可掃瞄的,內部資料是加密的).
因為身份證是公安局(頒發機構)頒發給你的,同時公安局也是航空公司可以信賴的,信賴身份證就像信賴公安局一樣,所以沒什麼要懷疑的,你成功的買到票了.
從上面的過程我們可以看出,航空公司沒有維護自己的使用者庫,也沒有自己去驗證使用者資訊的真實性,因為身份證可以證明買票者同時提供了航空公司需要的資訊(宣告).
航空公司把這一切驗證都外包給了乙個統一的機構.同時這一機構可以提供足夠的使用者資訊.
人類這些聰明的社會行為同樣的被拿到軟體設計上.下面用真實的web系統說明:
rp 公開了描述其位址、繫結和協定的策略。 但是該策略也包括 rp 所需的宣告列表，如使用者名稱、電子郵件位址和角色成員身份。 該策略還告知智慧型客戶端應從中檢索這些宣告的 sts 的位址。 檢索此策略後 (1)，
客戶端此時已知道到**去進行身份驗證：sts。 使用者出示憑據 (2)，
智慧型客戶端向 sts 提出 web 服務請求 (3)，
從而請求 rp 在其策略中所要求的宣告。 sts 的工作是對使用者進行身份驗證，並返回為 rp 提供所有所需宣告的安全令牌。 然後智慧型客戶端會對依賴方提出請求 (4)，
從而在安全 soap 標頭中傳送安全令牌。 rp 此時收到各個請求的宣告，只拒絕那些不包括來自其信任的頒發機構的安全令牌的請求。
下面我來列出一些術語:
sts: securitytokenservice(安全令牌服務),相當於公安局,提供身份證資訊審查/辦理/查詢驗證服務.
rp: 信賴方. 當某個公司需要使用身份證來辦理公司業務時,它必須信賴公安局(sts),這個公司此時參與的角色被稱謂 信賴方.
rp-sts:(信賴方sts) /ip-sts:(標識方sts)
聯合身份驗證概述
ORACLE 入門系列 1
最近開始重新梳理自己的oracle知識，寫出來以備記錄和供大家共享。1.安裝oracle服務端軟體自不必說。2.使用dos介面連線資料庫 執行以下命令 sqlplus nolog 回車 conn 使用者名稱 密碼 如果使用sys登陸，這樣寫 conn sys sys as sysdba 回車 顯示已...
react系列（1）入門
react對初學者入門較難，它也是現在前端三大主流框架之一。想了想，還是寫一些文章吧，一來可以幫助想學習react的初學者，二來也可以總結經驗，把這些知識點共享出來。在挑選react版本的時候，發現react最新版的v16.x和v15.x之間會有api出入。比如，v16.x不再支援最基本的渲染元件r...
jstorm系列 1 入門
storm 是乙個類似hadoop mapreduce的系統，使用者按照指定的介面實現乙個任務，然後將這個任務遞交給jstorm系統，jstorm將這個任務跑起來，並且按7 24小時執行起來，一旦中間乙個worker 發生意外故障，排程器立即分配乙個新的worker替換這個失效的worker。因此，...