?????SSO(Single Sign-On,單點登錄)是身份管理中的一部分。SSO的一種較為通俗的定義是:SSO是指訪問同一服務器不同應用中的受保護資源的同一用戶,只需要登錄一次,即通過一個應用中的安全驗證后,再訪問其他應用中的受保護資源時,不再需要重新登錄驗證。
SSO與身份管理軟件背景
???目前的企業應用環境中,往往有很多的應用系統,如辦公自動化(
OA
)系統,財務管理系統,檔案管理系統,信息查詢系統等等。這些應用系統服務于企業的信息化建設,為企業帶來了很好的效益。但是,用戶在使用這些應用系統時,并不方便。用戶每次使用系統,都必須輸入用戶名稱和用戶密碼,進行身份驗證;而且,應用系統不同,用戶賬號就不同,用戶必須同時牢記多套用戶名稱和用戶密碼。特別是對于應用系統數目較多,用戶數目也很多的企業,這個問題尤為突出。問題的原因并不是系統開發出現失誤,而是缺少整體規劃,缺乏統一的用戶登錄平臺。
???使用SSO技術可以解決以上這些問題,SSO是身份管理中的一部分,關于安全與身份管理軟件市場,可參考:
http://www.blogjava.net/ablix/archive/2005/12/28/25804.html
使用 SSO 的好處
???使用 SSO 的好處主要有:
??????(1) 方便用戶
???用戶使用應用系統時,能夠一次登錄,多次使用。用戶不再需要每次輸入用戶名稱和用戶密碼,也不需要牢記多套用戶名稱和用戶密碼。單點登錄平臺能夠改善用戶使用應用系統的體驗。
??????(2) 方便管理員
???系統管理員只需要維護一套統一的用戶賬號,方便、簡單。相比之下,系統管理員以前需要管理很多套的用戶賬號。每一個應用系統就有一套用戶賬號,不僅給管理上帶來不方便,而且,也容易出現管理漏洞。
??????(3) 簡化應用系統開發
???開發新的應用系統時,可以直接使用單點登錄平臺的用戶認證服務,簡化開發流程。單點登錄平臺通過提供統一的認證平臺,實現單點登錄。因此,應用系統并不需要開發用戶認證程序。
二、
實現SSO的技術主要有:
??????(1)基于cookies實現,需要注意如下幾點:如果是基于兩個域名之間傳遞sessionid的方法可能在windows中成立,在unix&linux中可能會出現問題;可以基于數據庫實現;在安全性方面可能會作更多的考慮。另外,關于跨域問題,雖然cookies本身不跨域,但可以利用它實現跨域的SSO。
??????(2)Broker-based(基于經紀人),例如Kerberos等;
???這種技術的特點就是,有一個集中的認證和用戶帳號管理的服務器。經紀人給被用于進一步請求的電子的身份存取。中央數據庫的使用減少了管理的代價,并為認證提供一個公共和獨立的"第三方"。例如Kerberos、Sesame、IBM KryptoKnight(憑證庫思想)等。
??????(3)Agent-based(基于代理人)
???在這種解決方案中,有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如, 它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在服務器上面,在服務器的認證系統和客戶端認證方法之間充當一個"翻譯"。例如SSH等。
??????(4)Token-based,例如SecurID、WebID、
???現在被廣泛使用的口令認證,比如FTP,郵件服務器的登錄認證,這是一種簡單易用的方式,實現一個口令在多種應用當中使用。
??????(5)基于網關
??????Agent and Broker-based,這里不作介紹。
??????(6)基于安全斷言標記語言(SAML)實現,SAML(Security Assertion Markup Language,安全斷言標記語言)的出現大大簡化了SSO,并被OASIS批準為SSO的執行標準。開源組織OpenSAML 實現了 SAML 規范,可參考 http://www.opensaml.org 。
SUN ?SSO技術
??????SUN SSO技術是Sun Java System Access Manager產品中的一個組成部分。
??????Sun 的新身份管理產品包括Sun Java System Identity Manager、Sun Java System Directory Server Enterprise Edition 和 Sun Java System Access Manager,以上三者為Sun Java Identity Management Suite (身份識別管理套件)的組成部分,它們與Sun Java Application Platform Suite、Sun Java Availability Suite、Sun Java Communications Suite、Sun Java Web Infrastructure Suite組成Java ES。具有革新意義的這一系列產品提供端到端身份管理,同時可與 60 多種第三方資源和技術實現互操作,集成產品可以從SUN公司網站下載,一般以Agent軟件方式提供,是業內集成程序最高、最為開放的身份管理解決方案之一。
???在Sun 的新身份管理產品中,
Sun Java System Access Manager是基中的一個重要組成部分,Java Access Manager基于J2EE架構,采用標準的API,可擴展性強,具有高可靠性和高可用性,應用是部署在Servlets容器中的,支持分布式,容易部署且有較低的TCO。通過使用集中驗證點、其于角色的訪問控制以及 SSO,Sun Java System Access Manager 為所有基于 Web 的應用程序提供了一個可伸縮的安全模型。它簡化了信息交換和交易,同時能保護隱私及重要身份信息的安全。
CAS 背景介紹
??????CAS(Central Authentication Service),是耶魯大學開發的單點登錄系統(SSO,single sign-on),應用廣泛,具有獨立于平臺的,易于理解,支持代理功能。CAS系統在各個大學如耶魯大學、加州大學、劍橋大學、香港科技大學等得到應用。
??????Spring Framework的Acegi安全系統支持CAS,并提供了易于使用的方案。Acegi安全系統,是一個用于Spring Framework的安全框架,能夠和目前流行的Web容器無縫集成。它使用了Spring的方式提供了安全和認證安全服務,包括使用Bean Context,攔截器和面向接口的編程方式。因此,Acegi安全系統能夠輕松地適用于復雜的安全需求。Acegi安全系統在國內外得到了廣泛的應用,有著良好的社區環境。
CAS 的設計目標
??????(1)為多個Web應用提供單點登錄基礎設施,同時可以為非Web應用但擁有Web前端的功能服務提供單點登錄的功能;
??????(2)簡化應用認證用戶身份的流程;
??????(3)將用戶身份認證集中于單一的Web應用,讓用戶簡化他們的密碼管理,從而提高安全性;而且,當應用需要修改身份驗證的業務邏輯時,不需要到處修改代碼。
CAS
的實現原理
??????CAS(Central Authentication Server)被設計成一個獨立的Web應用。實現原理非常簡單,CAS Server
CAS
在應用中的運行硬件環境
??????University of
??????CAS創建一個位數很長的隨機數(ticket)。CAS把這個ticket和成功登錄的用戶以及用戶要訪問的service聯系起來。例如,如果用戶peon重定向自service S,CAS創建ticket T,這個ticket T允許peon訪問service S。這個ticket是個一次性的憑證;它僅僅用于peon和僅僅用于service S,并且只能使用一次,使用之后馬上會過期,即ticket通過驗證,CAS立即刪除該ticket,使它以后不能再使用。這樣可以保證其安全性。
???關于ST,在取一個ST時,即使用deleteTicket(ticketId)同時將一次性的ST刪除;而對于TGT或PT,則通過resetTimer(ticketId)以更新TGT或PT的時間。在CAS服務端返回的ST中只能得出用戶名。
??????另外,CAS3.0版本也已經發布了,現在最新的版本是3.03,希望CAS3.0在向下兼容的同時,更能向我們提供一些新東西。?
?
?
SUN SSO 實現原理
??????SSO的核心在于統一用戶認證,登錄、認證請求通過
IDENTITY SERVER服務器
完成,然后分發到相應應用。
??????SUN SSO是java Access Manager的一個組成部分, SSO 基于 Cookie 實現解釋如下:
??????(1)Policy Agent on Web or Application Server intercepts resource requests and enforces access control;
??????(2)Client is issued SSO token containing information for session Validation with Session service.
??????(3)SSO token has no content- just a long random string used as a handle.
??????(4)Web-based applications use browser session cookies or URL rewriting to issue SSO token.
??????(5)Non Web applications use the SSO API(Java/c) to obtain the SSO token to validate the users identity.
SUN SSO 的應用
???這里說的應用是指
Sun Java System Access Manager
的應用。成功應用例子很多,包括德國電信等公司的應用,國內也有大量高校在使用,也有相當多的其它行業的應用。
SUN SSO的開源
??????Sun 將發布其網絡驗證與網絡單點登錄技術,給一項新的開放源代碼計劃“Open Web Single Sign-On”(Open SSO)。
OpenSSO
網站位于:
https://opensso.dev.java.net/
。該網站對
OpenSSO的概述為:
This project is based on the code base of Sun Java(tm) System Access Manager Product, a core identity infrastructure product offered by Sun Microsystems.
??????OpenSSO 計劃的第一部份源代碼,將于今年年底完成,基本的版本將于明年3月份發布,而完整的版本可能要等到明年五月份。 Sun 采用 與 Solaris 操作系統相同的共同開發暨流通授權( Common Development and Distribution License )方式。
本文以某新聞單位多媒體數據庫系統為例,提出建立企業用戶認證中心,實現基于安全策略的統一用戶管理、認證和單點登錄,解決用戶在同時使用多個應用系統時所遇到的重復登錄問題。
隨著信息技術和網絡技術的迅猛發展,企業內部的應用系統越來越多。比如在媒體行業,常見的應用系統就有采編系統、排版系統、印刷系統、廣告管理系統、財務系統、辦公自動化系統、決策支持系統、客戶關系管理系統和網站發布系統等。由于這些系統互相獨立,用戶在使用每個應用系統之前都必須按照相應的系統身份進行登錄,為此用戶必須記住每一個系統的用戶名和密碼,這給用戶帶來了不少麻煩。特別是隨著系統的增多,出錯的可能性就會增加,受到非法截獲和破壞的可能性也會增大,安全性就會相應降低。針對于這種情況,統一用戶認證、單點登錄等概念應運而生,同時不斷地被應用到企業應用系統中。
統一用戶管理的基本原理
一般來說,每個應用系統都擁有獨立的用戶信息管理功能,用戶信息的格式、命名與存儲方式也多種多樣。當用戶需要使用多個應用系統時就會帶來用戶信息同步問題。用戶信息同步會增加系統的復雜性,增加管理的成本。
例如,用戶X需要同時使用A系統與B系統,就必須在A系統與B系統中都創建用戶X,這樣在A、B任一系統中用戶X的信息更改后就必須同步至另一系統。如果用戶X需要同時使用10個應用系統,用戶信息在任何一個系統中做出更改后就必須同步至其他9個系統。用戶同步時如果系統出現意外,還要保證數據的完整性,因而同步用戶的程序可能會非常復雜。
解決用戶同步問題的根本辦法是建立統一用戶管理系統(UUMS)。UUMS統一存儲所有應用系統的用戶信息,應用系統對用戶的相關操作全部通過UUMS完成,而授權等操作則由各應用系統完成,即統一存儲、分布授權。UUMS應具備以下基本功能:
1.用戶信息規范命名、統一存儲,用戶ID全局惟一。用戶ID猶如身份證,區分和標識了不同的個體。
2.UUMS向各應用系統提供用戶屬性列表,如姓名、電話、地址、郵件等屬性,各應用系統可以選擇本系統所需要的部分或全部屬性。
3.應用系統對用戶基本信息的增加、修改、刪除和查詢等請求由UUMS處理。
4.應用系統保留用戶管理功能,如用戶分組、用戶授權等功能。
5.UUMS應具有完善的日志功能,詳細記錄各應用系統對UUMS的操作。
統一用戶認證是以UUMS為基礎,對所有應用系統提供統一的認證方式和認證策略,以識別用戶身份的合法性。統一用戶認證應支持以下幾種認證方式:
1. 匿名認證方式: 用戶不需要任何認證,可以匿名的方式登錄系統。
2. 用戶名/密碼認證: 這是最基本的認證方式。
3. PKI/CA數字證書認證: 通過數字證書的方式認證用戶的身份。
4. IP地址認證: 用戶只能從指定的IP地址或者IP地址段訪問系統。
5. 時間段認證: 用戶只能在某個指定的時間段訪問系統。
6. 訪問次數認證: 累計用戶的訪問次數,使用戶的訪問次數在一定的數值范圍之內。
以上認證方式應采用模塊化設計,管理員可靈活地進行裝載和卸載,同時還可按照用戶的要求方便地擴展新的認證模塊。
認證策略是指認證方式通過與、或、非等邏輯關系組合后的認證方式。管理員可以根據認證策略對認證方式進行增、刪或組合,以滿足各種認證的要求。比如,某集團用戶多人共用一個賬戶,用戶通過用戶名密碼訪問系統,訪問必須限制在某個IP地址段上。該認證策略可表示為: 用戶名/密碼“與”IP地址認證。
PKI/CA數字證書認證雖不常用,但卻很有用,通常應用在安全級別要求較高的環境中。PKI(Public Key Infrastructure)即公鑰基礎設施是利用公鑰理論和數字證書來確保系統信息安全的一種體系。
在公鑰體制中,密鑰成對生成,每對密鑰由一個公鑰和一個私鑰組成,公鑰公布于眾,私鑰為所用者私有。發送者利用接收者的公鑰發送信息,稱為數字加密,接收者利用自己的私鑰解密; 發送者利用自己的私鑰發送信息,稱為數字簽名,接收者利用發送者的公鑰解密。PKI通過使用數字加密和數字簽名技術,保證了數據在傳輸過程中的機密性(不被非法授權者偷看)、完整性(不能被非法篡改)和有效性(數據不能被簽發者否認)。
數字證書有時被稱為數字身份證,數字證書是一段包含用戶身份信息、用戶公鑰信息以及身份驗證機構數字簽名的數據。身份驗證機構的數字簽名可以確保證書信息的真實性。
完整的PKI系統應具有權威認證機構CA(Certificate Authority)、證書注冊系統RA(Registration Authority)、密鑰管理中心KMC(Key Manage Center)、證書發布查詢系統和備份恢復系統。CA是PKI的核心,負責所有數字證書的簽發和注銷; RA接受用戶的證書申請或證書注銷、恢復等申請,并對其進行審核; KMC負責加密密鑰的產生、存貯、管理、備份以及恢復; 證書發布查詢系統通常采用OCSP(Online Certificate Status Protocol,在線證書狀態協議)協議提供查詢用戶證書的服務,用來驗證用戶簽名的合法性; 備份恢復系統負責數字證書、密鑰和系統數據的備份與恢復。
單點登錄
單點登錄(SSO,Single Sign-on)是一種方便用戶訪問多個系統的技術,用戶只需在登錄時進行一次注冊,就可以在多個系統間自由穿梭,不必重復輸入用戶名和密碼來確定身份。單點登錄的實質就是安全上下文(Security Context)或憑證(Credential)在多個應用系統之間的傳遞或共享。當用戶登錄系統時,客戶端軟件根據用戶的憑證(例如用戶名和密碼)為用戶建立一個安全上下文,安全上下文包含用于驗證用戶的安全信息,系統用這個安全上下文和安全策略來判斷用戶是否具有訪問系統資源的權限。遺憾的是J2EE規范并沒有規定安全上下文的格式,因此不能在不同廠商的J2EE產品之間傳遞安全上下文。
圖1 SSO原理示意圖 |
目前業界已有很多產品支持SSO,如IBM的WebSphere和BEA的WebLogic,但各家SSO產品的實現方式也不盡相同。WebSphere通過Cookie記錄認證信息,WebLogic則是通過Session共享認證信息。Cookie是一種客戶端機制,它存儲的內容主要包括: 名字、值、過期時間、路徑和域,路徑與域合在一起就構成了Cookie的作用范圍,因此用Cookie方式可實現SSO,但域名必須相同; Session是一種服務器端機制,當客戶端訪問服務器時,服務器為客戶端創建一個惟一的SessionID,以使在整個交互過程中始終保持狀態,而交互的信息則可由應用自行指定,因此用Session方式實現SSO,不能在多個瀏覽器之間實現單點登錄,但卻可以跨域。
實現SSO有無標準可尋?如何使業界產品之間、產品內部之間信息交互更標準、更安全呢?基于此目的,OASIS(結構化信息標準促進組織)提出了SAML解決方案(有關SAML的知識參看鏈接)。
用戶認證中心實際上就是將以上所有功能、所有概念形成一個整體,為企業提供一套完整的用戶認證和單點登錄解決方案。一個完整的用戶認證中心應具備以下功能:
1. 統一用戶管理。實現用戶信息的集中管理,并提供標準接口。
2. 統一認證。用戶認證是集中統一的,支持PKI、用戶名/密碼、B/S和C/S等多種身份認證方式。
圖2 統一用戶認證與單點登錄設計模型 |
3. 單點登錄。支持不同域內多個應用系統間的單點登錄。
用戶認證中心提供了統一認證的功能,那么用戶認證中心如何提供統一授權的功能呢?這就是授權管理中,其中應用最多的就是PMI。
PMI(Privilege Management Infrastructure,授權管理基礎設施)的目標是向用戶和應用程序提供授權管理服務,提供用戶身份到應用授權的映射功能,提供與實際應用處理模式相對應的、與具體應用系統開發和管理無關的授權和訪問控制機制,簡化具體應用系統的開發與維護。PMI是屬性證書(Attribute Certificate)、屬性權威(Attribute Authority)、屬性證書庫等部件的集合體,用來實現權限和證書的產生、管理、存儲、分發和撤銷等功能。
PMI以資源管理為核心,對資源的訪問控制權統一交由授權機構統一處理,即由資源的所有者來進行訪問控制。同公鑰基礎設施PKI相比,兩者主要區別在于: PKI證明用戶是誰,而PMI證明這個用戶有什么權限,能干什么,而且PMI可以利用PKI為其提供身份認證。
單點登錄通用設計模型
圖2是統一用戶認證和單點登錄通用設計模型,它由以下產品組成:
1. PKI體系: 包括CA服務器、RA服務器、KMC和OCSP服務器。
2. AA管理服務器: 即認證(Authentication)和授權(Authorization)服務器,它為系統管理員提供用戶信息、認證和授權的管理。
3. UUMS模塊: 為各應用系統提供UUMS接口。
4. SSO: 包括SSO代理和SSO服務器。SSO代理部署在各應用系統的服務器端,負責截獲客戶端的SSO請求,并轉發給SSO服務器,如果轉發的是OCSP請求,則SSO服務器將其轉發給OCSP服務器。在C/S方式中,SSO代理通常部署在客戶端。
5. PMI: 包括PMI代理和PMI服務器。PMI代理部署在各應用系統的服務器端,負責截獲客戶端的PMI請求,并轉發給PMI服務器。
6. LDAP服務器: 統一存儲用戶信息、證書和授權信息。
為判斷用戶是否已經登錄系統,SSO服務器需要存儲一張用戶會話(Session)表,以記錄用戶登錄和登出的時間,SSO服務器通過檢索會話表就能夠知道用戶的登錄情況,該表通常存儲在數據庫中。AA系統提供了對會話的記錄、監控和撤消等管理功能。為保證穩定與高效,SSO、PMI和OCSP可部署兩套或多套應用,同時提供服務。
鏈接
SAML
SAML(Security Assertion Markup Language,安全性斷言標記語言)是一種基于XML的框架,主要用于在各安全系統之間交換認證、授權和屬性信息,它的主要目標之一就是SSO。在SAML框架下,無論用戶使用哪種信任機制,只要滿足SAML的接口、信息交互定義和流程規范,相互之間都可以無縫集成。SAML規范的完整框架及有關信息交互格式與協議使得現有的各種身份鑒別機制(PKI、Kerberos和口令)、各種授權機制(基于屬性證書的PMI、ACL、Kerberos的訪問控制)通過使用統一接口實現跨信任域的互操作,便于分布式應用系統的信任和授權的統一管理。
SAML并不是一項新技術。確切地說,它是一種語言,是一種XML描述,目的是允許不同安全系統產生的信息進行交換。SAML規范由以下部分組成:
1. 斷言與協議: 定義XML格式的斷言的語法語義以及請求和響應協議。SMAL主要有三種斷言: 身份認證斷言、屬性斷言和訪問授權斷言。
2. 綁定與配置文件: 從SAML請求和響應消息到底層通信協議如SOAP或SMTP的映射。
3. 一致性規范: 一致性規范設置了一種基本標準,必須滿足這一SAML標準的實現才能夠稱為一致性實現。這樣有助于提高互操作性和兼容性。
4. 安全和保密的問題: SAML體系結構中的安全風險,具體而言就是SAML如何應對這些風險以及無法解決的風險。
要注意的是,SAML并不是專為SSO設計,但它卻為SSO的標準化提供了可行的框架。??
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
