最近花了較多時間學習單點登陸以及相關的安全技術，做一個簡單的總結，發表我的一些看法。拋磚引玉，希望各位朋友參與討論。

單點登陸，鳥語原文為Single Sign-On，縮寫為SSO。別以為單點登陸是很時髦高深的技術，相反單點登陸是很古老的技術，例如1980年kerberos v4發布，一直發展至今，被Windows、Mac OS X、Linux等流行的操作系統所采用，是為應用最廣泛的單點登陸技術。

kerberos適用于局域網，十分成熟。互聯網發展之后，多個網站需要統一認證，業界需要適合互聯網的單點登陸技術，也就是WEB SSO。2002年，微軟提出了passport服務，由微軟統一提供帳號和認證服務，理所當然，大家都不愿意受制于微軟，但是很認同微軟提出WEB SSO理念，于是產生了Liberty Alliance，另外指定一套標準，這套標準發展起來就是SAML，目前SAML的版本是SAML V2，屬于OASIS的標準。

--------------
SAML

SAML，鳥語全名為Security Assertion Markup Language，彌漫著學院派的腐尸味道，縮寫十分怪異，令人望而生畏。計算機行業，向來崇尚時髦，SAML這一名稱使得其較少受到大眾程序員的關注。

SAML的標準制定者，來自SUN、BEA、IBM、RSA、AOL、Boeing等大公司，制定技術規范相當專業有水準，系統分層合理，抽象了幾個概念把整個系統描述得很清楚，使用流行技術XML Schema來描述協議，使用到了XML-Sign和XML Encrypt等較為前緣XML安全技術。

SAML的基本部分包括Protocol、Bingding、Profile、Metadata、AuthenticationContext。其中Protocol是交互消息的格式，例如AuthnRuequest/Response（認證請求/響應）的消息對。Bingding是指協議所采用的傳輸方式，例如使用HTTP Redirect或HTTP POST或SOAP的方式傳輸Protocol中所定義的消息。Profile是系統角色間交互消息的各種場景，例如Web Single Sign-ON是一種Profile、Single Sign-Out也是一種Profile、身份聯邦也是一種Profile。各個參與方所提供的服務的描述信息為metadata。系統的認證方法通常是千差萬別的，AuthenticationContext是SAML中定義的認證擴展點，可以是最普通的User Password認證，也可以是kerberos認證，也可以是電信常用的RADIUS，或者是動態密碼卡。

SAML在Java企業應用中，得到廣泛支持，IBM、BEA、ORACLE、SUN的Java應用服務器都提供了SAML的支持，曾經有人說，SAML就是如同JDBC一樣，將會是使系統集成的準入證。SAML有很多開源實現，包括SUN公司的Open SSO，不幸的是，這些開源實現都不夠好，或者相當糟糕，如果我們需要支持SAML協議，可能需要在開源的版本上裁剪或者另行開發。

SAML考慮了Web SSO，也考慮了傳統的SSO集成，包括Kerberos和LDAP的集成，其中Attributed擴展機制以及相關規范，使得SAML擁有良好的擴展性，很好集成傳統協議和支持新協議。

SAML是一個定義良好的規范，概念清晰，分層合理，擴展性良好，一切都很棒，但是有一點不好，就是曲高和寡！

-------------
OpenID
有一些互聯網公司，擁有眾多很多帳號，很牛B，例如GOOGLE、YAHOO、Facebook，希望別人的系統使用它們的帳號登陸。他們希望一種足夠簡單的WEB SSO規范，于是選擇一種草根網絡協議OpenID。OpenID，名字取得好，顧名思義，一看就知道它是干嘛的。國內也有它的Fans，例如豆瓣網。openID的確足夠簡單，但是協議本身是不完善，可能需要一些補充協議才能夠滿足業務需求。例如GOOGLE采用OpenID + OAuth。目前支持OpenID有Yahoo、Google、Windows Live，還有號稱要支持OpenID的Facebook。目前Yahoo和Google宣稱對OpenID的支持，但是其實是有限制的，Yahoo的OpenID只有少數合作伙伴才能獲得其屬性，Google也只有在其Google Apps中才能獲得賬號的Attribute。用戶賬號畢竟是一個互聯網公司的最寶貴資源，希望他們完全分享賬號是不可能的。

Open ID和SAML兩種規范，都將會減少系統間交互的成本，我們提供Open API時，應該支持其中一種或者或兩種規范。

--------------
OAuth

oAuth涉及到3大塊的交互和通信。1. 用戶，2. 擁有用戶資料/資源的服務器A，3. 求資源的服務器B，。

oAuth的典型應用場景（senario）
以前，用戶在 擁有資源 的的網站A有一大堆東西；現在用戶發現了一個新的網站B，比較好玩，但是這個新的網站B想調用 擁有資源的網站A的數據。

用戶在 求資源的網站B 上，點擊一個URL，跳轉到 擁有 資源的網站A。
擁有資源的網站A提示：你需要把資源分享給B網站嗎？Yes/No。
用戶點擊 Yes，擁有資源的網站A 給 求資源的網站B 臨時/永久 開一個通道，然后 求資源的網站 就可以來 擁有資源的網站 抓取所需的信息了。
(參考資料：http://initiative.yo2.cn/archives/633801）
（摘抄）
--------------

內部系統間集成使用LDAP、Kerberos，外部系統集成使用SAML或者OpenID + OAuth，這是一種建議的模式。

------------
PAM

人們尋找一種方案：一方面，將鑒別功能從應用中獨立出來，單獨進行模塊化設計，實現和維護；另一方面，為這些鑒別模塊建立標準 API，以便各應用程序能方便的使用它們提供的各種功能；同時，鑒別機制對其上層用戶（包括應用程序和最終用戶）是透明的。直到 1995 年，SUN 的研究人員提出了一種滿足以上需求的方案--插件式鑒別模塊（PAM）機制并首次在其操作系統 Solaris 2.3 上部分實現。插件式鑒別模塊（PAM）機制采用模塊化設計和插件功能，使得我們可以輕易地在應用程序中插入新的鑒別模塊或替換原先的組件,而不必對應用程序做任何修改，從而使軟件的定制、維持和升級更加輕松--因為鑒別機制與應用程序之間相對獨立。應用程序可以通過 PAM API 方便的使用 PAM 提供的各種鑒別功能，而不必了解太多的底層細節。此外，PAM的易用性也較強，主要表現在它對上層屏蔽了鑒別的具體細節，所以用戶不必被迫學習各種各樣的鑒別方式，也不必記住多個口令；又由于它實現了多鑒別機制的集成問題，所以單個程序可以輕易集成多種鑒別機制如 Kerberos 鑒別機制和 Diffie - Hellman 鑒別機制等，但用戶仍可以用同一個口令登錄而感覺不到采取了各種不同鑒別方法。PAM 后來被標準化為 X/Open UNIX® 標準化流程（在 X/Open 單點登錄服務（XSSO）架構中）的一部分。（摘抄）

如果我們設計一個認證系統，PAM是應該參考借鑒的。

-------------
JAAS
Java Authentication Authorization Service（JAAS，Java驗證和授權API）提供了靈活和可伸縮的機制來保證客戶端或服務器端的Java程序。Java早期的安全框架強調的是通過驗證代碼的來源和作者，保護用戶避免受到下載下來的代碼的攻擊。JAAS強調的是通過驗證誰在運行代碼以及他／她的權限來保護系統面受用戶的攻擊。它讓你能夠將一些標準的安全機制，例如Solaris NIS（網絡信息服務）、Windows NT、LDAP（輕量目錄存取協議），Kerberos等通過一種通用的，可配置的方式集成到系統中。在客戶端使用JAAS很簡單。在服務器端使用JAAS時情況要復雜一些。（摘抄）

-------------
Spring Security，Spring框架大名鼎鼎，Spring Security屬于SpringFramework旗下的一個子項目，源自acegi 1.x發展起來。很多人項目應用了spring security，但我個人看來，spring security絕對不算是一個設計良好的安全框架。其設計感覺就是一個小項目的安全認證實踐罷了。

-------------
CAS
應用最廣的開源單點登陸實現了，其實現模仿Kerberos的一些概念，例如KDC、TGS等等，都是來自于Kerberos。CAS對SAML和OpenID協議支持得不夠好。個人感覺類似Kerberos的機制在互聯網中可能過于復雜了。我感覺單純的ticket機制，過于局限于基于加密解密的安全了，感覺上SAML的Assertion概念更好，Assertion可以包括認證、授權以及屬性信息。

-------------


--------------------------
09博客園紀念T恤
新聞：Wordpress發布實時RSS技術 推動實時網絡發展
網站導航: 博客園首頁  個人主頁  新聞  社區  博問  閃存  找找看