1、-單點登錄技術的研究與應用中聯敏捷2021.12. z-前言隨著公司提供的醫療行業解決方案的不斷開展和深入，提供的業務應用系統數量不斷地增加，在傳統的醫院管理信息系統及區域衛生醫療系統兩大業務體系下，衍生出大量的專業性的應用系統，在缺乏整體規劃的條件下，這些系統不同程度的存在數據冗余和重復的問題，這些系統之間隨著應用的成熟，不同系統之間的業務和業務之間的相關性越來越大，為了降低管理消耗和維護本錢，企業應用集成在不同層面上進展運用，例如在數據層面上的“數據大集中，在信息利用、傳輸層面上的“消息交換平臺、在用戶界面上的“通用企業門戶等等，其中的一個層面就是系統用戶身份認證的整合，即單點登錄。通常來

2、說，每個單獨的系統都會有自己的平安體系和身份認證系統。每個系統需要各自的身份認證系統造成資源的浪費，消耗開發本錢，另外進入每個系統都需要進展登錄，這樣的局面不僅給管理上帶來了很大的困難，增加了整個系統的管理工作本錢，同時，用戶需要記憶多個賬戶和密碼，用戶為了圖省事，直接使用默認密碼或者簡化密碼，另外需要屢次重復輸入密碼，被窺視的時時機大大增加，這樣也在平安方面也埋下了重大的隱患。另外，在面向效勞架構體系下以及與外部程序進展數據通訊的需求下，引入“單點登錄的規體系能夠大大簡化這些場景下的平安問題，提高效勞與效勞之間的可信性以及效率。單點登錄系統的目的就是為應用系統以及效勞提供集中統一的身份認證，

3、實現“一點登錄、多點漫游、即插即用、應用無關"的目標，利于系統的集成，方便用戶使用。一、概述1.1概念SSO的英文全稱是Single Sign On,意思是單點登錄，SSO是一項技術，而不是一類軟件。單點登錄簡單說，就是通過用戶的一次性鑒別登錄，即可獲得需系統和應用軟件的授權，在此條件下，管理員無需修改或干預用戶登錄就能方便的實施希望得到的平安控制。這是一個為了能夠在分布式計算機環境中，平安和方便的鑒別用戶而產生的課題1.2背景隨著信息技術和網絡技術的開展，企業部存在著很多不同的應用系統，以醫院信息化為例，根據醫院的規模不同，存在的應用系統可能從一種到十余種不等，可能一個方案提供商提

4、供的解決方案中就包含了幾種獨立的應用系統，常見的應用系統有：HIS醫院管理信息系統、LIS實驗室管理信息系統、PACS影像歸檔和通信系統、PIS病理信息系統、EMR電子病歷系統、體檢系統等等，除此之外，還包括一些根底類的信息化應用，比方辦公系統OA、系統、網絡代理等等。用戶在日常應用中，需要登錄到不同的應用系統中，每個系統都要求用戶遵循一定的平安策略，比方要求輸入用戶名和口令。隨著用戶需要登錄系統的增多，不僅影響了工作效率，而且，出錯的可能性就會增加，受到非法截獲和破壞的可能性也會增大，平安性就會相應降低。因此，提出了這樣一種需求：用戶可以基于最初應用系統時的一次身份驗證，對所有被授權的信息資

5、源進展無縫的。從而提高用戶的工作效率，降低操作的費用，并提高應用系統的平安性。1.3應用場景在目前中聯產品體系中，因為未采用單點登錄技術，實際上大多數應用場景是，用戶登錄到ZLHIS系統，如果需要再OA系統，需要重新再次輸入用戶名口令登錄系統，即使是兩種應用采用同樣的用戶身份憑證，也會要求重新進展一次身份驗證。應用系統之間應用場景可能存在以下幾種情況：l 身份憑證來源不同系統之間的用戶憑證來源不一樣，一樣的用戶在不同的系統中具有不同的身份，各個系統維護其獨立的用戶憑證源，為了統一身份，這樣就要求系統之間需要進展用戶身份的映射；l 運行環境不同應用系統運行在多種運行環境下，運行環境包括了操作系統

6、環境、運行模式，例如，應用系統的操作系統環境可能是Windows或者Linu*操作系統，運行模式可以C/S或者B/S模式以及Web效勞之間的調用。l 身份驗證機制不同不同應用系統的身份驗證機制可能不同，除了傳統的基于口令的認證方式，還存在智能卡、生物識別、證書認證等多種認證方式。如何實現“一點登錄、多點漫游，讓用戶只需要登錄一次就可以暢游所有的應用，以下就是實現SSO的幾種應用場景分析。使用不同驗證機制實現SSOl 場景描述假設有兩個應用程序A和B，A應用使用LDAP目錄效勞器進展身份認證，B應用使用數據庫進展身份驗證，A應用通過了LDAP身份認證后，得到認證效勞返回的用戶身份信息身份令牌，由

7、A應用漫游到B應用,A提供身份令牌給B應用，B應用能夠通過身份令牌識別已經在A應用登錄用戶的身份，并將其轉換成用戶在B系統中的身份，獲取用戶在B系統的資源權限，同理，已在B系統登錄的用戶采用同樣的方式漫游到A系統。l 實現方法1、 A和B采用統一的身份令牌生成和驗證機構，身份認證效勞根據不同的登錄請求來源判斷所要采用的身份驗證方法，不同的驗證方法校驗用戶提交的欲驗證的身份憑證，生成統一的身份令牌。2、 A和B各自有其自己的身份令牌和驗證機構，各自的身份驗證機構構成認證聯邦，由不同的認證效勞進展驗證，生成的身份令牌在互信的另外的認證效勞中會被成認。程序與桌面程序實現SSOl 場景描述有兩個應用A

8、和B，A應用是WEB應用程序，B是桌面應用程序，A應用通過網頁登錄后，點擊網頁上的，能夠啟動桌面應用程序B，實現應用漫游，同樣，B系統登錄后，通過界面上的界面元素能夠直接翻開瀏覽器A應用的資源，實現桌面應用和WEB應用的無縫連接。l 實現方法A應用成功登錄后，WEB應用效勞器會話中保存該用戶的身份令牌信息，A應用網頁上的是能夠獲取到該令牌信息的資源的URL，B客戶端可以通過URL獲得該令牌信息，B客戶端對令牌進展校驗，確認令牌的有效性，確認用戶身份。同樣，B客戶端登錄成功后，本地存中存儲已登錄用戶的身份令牌信息，當B應用需要其他客戶端應用或者WEB應用時，B客戶端提交其身份令牌信息給認證效勞器

9、做驗證，認證效勞器校驗令牌的有效性，生成新的令牌信息，并用資源URL的形式返回給客戶端，客戶端生成身份認證效勞令牌資源的的URL，用戶URL，獲得新的身份信息令牌，確認令牌的有效性，確認用戶身份。效勞之間實現SSOl 場景描述兩個應用A和B，各自公布了一個WEB效勞，A應用提供的Web效勞為訂單申請效勞，WS-訂單申請，B應用提供的Web效勞為訂單審核效勞，WS-訂單審核。應用A調用WEB-訂單申請，效勞中又調用了應用B的Web效勞:Wed-訂單審核,該效勞需要驗證調用效勞的提供的身份信息。l 實現方法應用A登錄成功后，調用WS-訂單效勞時，將其驗證通過的用戶身份令牌參加到WebService

10、的Head信息中或者按照WebService-Security標準，將身份令牌參加到WS-Security Header的<wsse:Security>節點中，應用B的Web-訂單審核效勞接收到調用請求時，首先驗證SOAP包的Head信息，對傳入的用戶身份令牌信息進展驗證，確認用戶的有效身份后，應用B繼續執行返回執行結果。企業門戶實現SSOl 場景描述用戶提供用戶憑證登錄企業門戶Portal，門戶將關系到該登錄用戶的系統資源、信息資源、數據資源組織起來集中展示在門戶頁面上。用戶只需登錄Portal一次就可以所有其他應用，而無需再分別登錄每一個應用，例如：用戶登錄Portal之后通過

11、展示的應用列表，可以分別ZLHIS桌面客戶端程序，通過瀏覽器重定向到區域醫療公共衛生平臺Web應用上。l 實現方法用戶登錄Portal門戶后，Portal效勞器將用戶憑證提交給身份驗證效勞進展驗證，驗證通過后，Portal效勞器會話保存身份令牌信息，當用戶需要通過門戶其他應用時，門戶生成對應提取該身份令牌信息的URL資源，客戶端程序或者重定向的Web應用URL資源，從Portal效勞器獲取身份令牌信息并進展驗證，確認該身份令牌信息的有效性，驗證有效后，將該令牌信息保存在客戶端或者Web應用效勞器上，供應用漫游使用。1.4實現目標單點登錄系統需要實現以下幾個目標：1. 從用戶的視角看，雖然是在復

12、雜的企業應用環境中，單點登錄不會影響到諸如業務過程，響應效率，網絡吞吐量等事情，并將互操作性方面的問題減至最少，任何事情都在順利工作。2. 所有的應用系統都能夠識別和提取單點登錄的身份信息容，忽略各個應用系統的運行環境，真正實現應用無關，要實現SSO的功能，讓用戶只登錄一次，就必須讓應用系統能夠識別已經登錄過的用戶。應用系統應該能對已登錄用戶的身份信息容進展識別和提取，通過與認證效勞進展通訊，判斷登錄身份信息是否有效，從而完成單點登錄的功能。3. 當一個單點登錄系統被參加使用，遷移應該容易，應該能夠與已有系統很方便的接駁，例如和現有的系統、應用效勞器系統等等。4. 單點登錄的認證方式是附加的，

13、易于改造的，實現所謂的“即插即用，所有的應用程序,可以不需要或只需很少的改動即可適應這種新的認證方式。另外需要注意的是1、 單點登錄系統應該是用戶信息無關的，有很多應用系統都有對用戶信息的獨立存儲，對于單點登錄技術而言，統一的、單一的用戶信息存儲并不是必須的，事實上，只要有統一的認證票據的產生和驗證系統或機制，無論用戶用戶信息存儲在哪里，都可以實現單點登錄。2、 單點登錄的身份驗證機構并不是單一的，單點登錄的認證效勞機構可以是多個，認證效勞機構之間可以通過標準的通訊協議，可以相互交換認證信息，認證效勞之間形成互信機制，相互間可以信任，實現更高級別的聯邦式單點登錄，真正意義上的“一點登錄、多點漫

14、游。例如：當用戶在應用A企業的應用系統時，由A企業的認證效勞器進展認證后，得到由此效勞器產生的身份憑證。當需要B企業的應用系統的時候，B企業的認證效勞器能夠識別用戶提交的身份憑證是由A企業的認證效勞器產生的，并且A企業已與B企業同屬于一個聯邦，構成互信，B企業成認用戶提交的身份信息。二、SSO解決方案2.1實現原理當用戶第一次應用系統1的時候，因為還沒有登錄，會被引導到認證系統中進展登錄；根據用戶提供的登錄信息，認證系統進展身份校驗，如果通過校驗，應該返回給用戶一個認證的憑據ticket；用戶再別的應用的時候就會將這個ticket帶上，作為自己認證的憑據，應用系統承受到請求之后會把ticket

15、送到認證系統進展校驗，檢查ticket的合法性。如果通過校驗，用戶就可以在不用再次登錄的情況下應用系統2和應用系統3了。比方，我們可以通過QQ即時通訊。在進入及時通訊后可以通過選擇其他效勞不用再次輸入用戶名和密碼就可以進入、空間等。第1步，用戶第一登錄，需要用戶提供QQ/密碼第2步，認證系統進展身份校驗，如果通過校驗，應該返回給用戶一個認證的憑據ticket。第3步，用戶登錄成功，進入到即時通訊界面。第4、5、6步，用戶通過即時通訊界面進入其他系統，因為此時客戶端已經獲取到了憑據ticket，此時就不用輸入QQ號和密碼。2.2 實現方案2.2.1 幾種實現方案通過上面QQ登錄的過程了解到，SS

16、O的重要點就是用戶通過認證系統進展身份校驗后返回給用戶的ticket，通過ticket實現二次登錄。然而在整個技術實現中有很多種實現技術，下面就介紹常用的7中方式：1) Cookies 這是瀏覽器中常用的認證方式，通過將用戶登錄成功后的信息存儲到Cookies中。每次效勞器容時，效勞器都需要從Cookies中讀取用戶信息如果用戶已經經過認證就可以直接返回的容。2) Broker-based(基于經紀人)這種技術的特點就是有一個集中的認證和用戶管理的效勞器“登錄中心如以下圖，站點A、B、C系統自身沒有認證的系統都需要公獨立的"第三方"登錄中心的用戶名和密碼。比方：Kerber

17、os。Kerberos是業界的標準網絡身份驗證協議，該協議是在麻省理工學院起草的，旨在給計算機網絡提供"身份驗證"。Kerberos協議的根底是基于信任第三方，如同一個經濟人broker集中的進展用戶認證和發放電子身份憑證，它提供了在開放型網絡中進展身份認證的方法，認證實體可以是用戶或用戶效勞。這種認證不依賴宿主機的操作系統或主機的IP地址，不需要保證網絡上所有主機的物理平安性，并且假定數據包在傳輸中可被隨機竊取篡改。Kerberos協議具有以下的一些優勢：a) 與授權機制相結合。b) 實現了一次性簽放的機制，并且簽放的票據都有一個有效期。c) 支持雙向的身份認證，既效勞器

18、可以通過身份認證確認客戶方的身份，而客戶如果需要也可以反向認證效勞方的身份。d) 支持分布式網絡環境下的認證機制，通過交換"跨域密鑰"來實現。第1,2步：用戶要A站點，首先都需要經過Kerberos效勞器認證獲取票據許可。第3,4步：通過Ticketgrenting效勞器獲取A站點的進入票據。第5步：進入A站點。3) Agent-based(基于代理人)基于代理人Agent-Based的SSO，有一個代理程序可以自動為不同的應用系統認證用戶。代理程序可以用不同的方式實現。假設Agent部署在客戶端，它能裝載獲得用戶名/口令列表，自動替用戶完成登錄過程，減輕客戶端程序的認證負

19、擔。假設Agent部署在效勞器端，它就是效勞器的認證系統和客戶端認證方法之間的“翻譯。當軟件提供商提供了大量的與原有應用系統的程序進展通信的Agent時，Agent-based方案可使應用遷移變得十分容易。比方：SecureShell通過使用SSH，你可以把所有傳輸的數據進展加密，這樣就能夠防止DNS和IP欺騙。這是一個為在網上進展平安連接的客戶/效勞器類型加密軟件，實現了一個密鑰交換協議，以及主機及客戶端認證協議。SSH的用戶可以使用包括RSA算法的不同認證方法。當使用RSA認證時，代理程序可以被用于單點登錄。代理程序可以在PC，便攜機，或終端上運行，當被認證身份參加到代理程序中，如果該代理

20、程序有新的子連結產生，則繼承原有連結的認證。遠程系統往往需要一個SSH效勞器，用以與代理程序通信。SSH包括如下構造a) 連接協議SSH-CONN：把加密通道分化成多個邏輯通道b) 用戶認證協議SSH-USERAUTH：為效勞器鑒別客戶端用戶c) 傳輸層協議SSH-TRANS：提供效勞器身份認證和完整性d) TCP/IP：為上層提供底層不平安的可靠的數據流TCP/IP在具體的SSH協議中，主碼是一個RSA私鑰，用于確認主機。效勞器密碼也是一個RSA私鑰，每小時更新。主機可以擁有多個用不同算法產生的主碼。多個主機也可以共享同一主碼。每個主機必須至少用每個必須的公鑰算法產生一個私鑰。利用個性化的平

21、安代理來實現時，每個運行SSH的主機不管是效勞器還是客戶端必須有一個平安代理程序在上面運行。例如，要獲得主碼和效勞器密碼個性化代理參與如下的兩局部：a) 密鑰生成和存儲：當效勞器需要生成主碼和效勞器密碼時，它會要求本地的平安代理來完成這一工作。本地平安代理或是自己生成密鑰對，或是要求另一個平安代理來生成。SSH協議并不區分這兩種情況。生成的密鑰由平安代理保管，在需要時使用。b) 身份認證：當客戶端得到主碼或效勞器密碼，它要傳給自己的平安代理，由平安代理負責對密碼進展認證。作為認證結果，平安代理會返回"成功"或"失敗"。SSH協議本身不關心有關密碼的細節。

22、稍后，如果有新的公鑰算法引入SSH，只需要替換平安代理的局部。4) Token-based基于令牌現在被廣泛使用的口令認證，比方FTP，效勞器的登陸認證，都可被稱為"single-factor "口令的認證。這是一種簡單易用的方式，同時也會帶來很多平安隱患。比方：在明文傳輸的網絡環境里經常使用但是很少更換的口令，更容易被竊取。RSA公司提出的一種稱為SecurID的解決方案。與"single-factor"不同，它被稱之為"two-factor"雙因素的認證。構成認證的第一個因素是Personnel Identification Nu

23、mber (PIN)，即用戶身份識別碼，這是一串的數字，可由系統管理員訂制。第二個要素是SecurID token，一個小型的數字發生器，這個發生器的時鐘將與網絡環境中提供身份鑒別的效勞器ACE保持同步，并且與ACE上的用戶數據庫保持映射。數字發生器每隔一段時間比方一分鐘產生新的數字，PIN同步時鐘數字就是用戶的登錄代碼。解決方案中也有種被稱為WebID的模塊。在Web效勞器上安裝一個ACE效勞器的代理程序，用來承受SecurID。當第一個需要認證的URL時，WebID會軟件產生并加密一個標識，這個標識被用于其他資源的時候。5) AgentandBroker-basedAgent and Br

24、oker-based，把基于經紀人的解決方案和基于代理的解決方案相結合。基于代理模型的最大優點就是能減少對應用程序的改造，而基于經紀人模型的最大優點就是認證集中，基于以上兩點，Agent and Broker-based模型就兼具了前者集中管理和后者無需修改應用效勞程序的優點，是優點比較突出也是現今用得較多的模型。6) 基于網關網關模型中的客戶端必須使用網關客戶軟件，通過一臺專用網關才能各種應用效勞。在這種方案，所有的響應效勞都需要放在被網關隔離的受信網段里。Client通過網關進展認證后獲得承受效勞的授權。如果網關后的效勞能夠通過IP地址識別，并可在網關上建立一個基于IP的響應規則，而這個規

25、則如果與在網關上的用戶數據庫相結合，網關就可以被用于單點登錄。網關通過記錄Client的身份不再需要冗余的認證請求，授權所需要的效勞。由于網關可以監視并改變應用效勞的數據流，所以在不修改應用效勞的同時，改變認證信息，并提供適宜的控制。7) SAML(平安斷言標記語言)SAML是平安的、跨域的基于*ML的標準，用于在不同的平安域(securitydomain)之間交換認證和授權數據規。目前應用最廣，下面會對其進展專門介紹2.2.2 實現方案評估Cookies可實施性跨域時傳遞Cookies的方法可能在windows中成立，在uni*&linu*中可能會出現問題管理程序部管理平安性基于的協

26、議本身就不平安，很容易受到中間人攻擊方式的攻擊。中間人獲取容，冒充效勞器發送信息Broker-based(基于經紀人)可實施性主要的問題是確定現有哪些應用程序需要被修改，并且對于舊系統的改造工作量較大管理一個中央數據庫易于進展管理平安性代理人假設Client已被信任，而惡意的軟件可以完成與代理人的協議并記錄口令來替代所有其他客戶的應用。任何一種安裝在這計算機環境中的軟件都會比較危險Agent-based(基于代理人)可實施性基于代理人的方式容易移植，但代理程序的軟件供應商需要設計和實現與原有應用程序協議的交互。管理單純的代理方式不能夠幫助管理，甚至使管理更難控制和分配代理軟件的權利。平安性有強

27、密碼技術的保證，代理程序的通信應該是平安的，但對于惡意軟件方面還是存在問題。Token-based基于令牌可實施性程序實現管理需要在系統上增加一些新的組件，增加了管理員管理的負擔。平安性用戶所有的密碼及憑証能夠平安儲存在令牌上，實現增強的平安性、完全的易攜性以及線上和離線模式的流暢運行。AgentandBroker-based可實施性使用基于代理方式，將可以簡化一些代理人方案中的修改。管理應比單純的代理人方案更易于管理平安性代理軟件需要增加平安和本地驗證的功能。基于網關可實施性網關作為一個分開的部件，需要注意它的網絡通信能力，并且根本不會有太多的互操作性，并且應用程序和網關客戶端軟件和需要安放

28、在網關同一側的一臺計算機上。管理比較而言，網關的中央用戶數據庫比一個broker-based代理人的解決方案更易于管理。帶來的問題是，如果假設干網關被使用，則用戶數據庫不能自動地被同步。平安性一個通訊加密效勞器應該是平安，但是也可能被攻擊，可能的攻擊點是其操作系統，而當網關放在防火墻上，則攻擊防火墻。推薦的方式是，用分開的防火墻保護網關。SAML(平安斷言標記語言)可實施性需要一個身份認證系統來生成SAML，并提供助診符。管理程序自動管理平安性SAML依靠一批制定完善的平安標準，包括SSL和*.509，來保護SAML源站點和目標站點之間通信的平安。源站點和目標站點之間的所有通信都經過了加密。為

29、確保參與SAML交互的雙方站點都能驗證對方的身份，還使用了證書從上表中對于各種不同的實現方案，從可實施性、管理、平安性三個方面并且結合我們實現的目標比照分析如下：1. cookies跨域在桌面應用程序中不容易實現，并且平安性不好。2. Broker-based、Agent-based、Agent and Broker-based在易遷移、易改造、平安性上不符合我們的目標。3. Token-based增加了額外的人員工作量，增加工程持續投入量。4. 基于網關對于網絡流量有要求，會增加網絡額外的流量。綜上所述，為實現不影響網絡、減少互操作性、應用無關性、易遷移、易改造即插即用的目標，SAML是最符

30、合我們要求的解決方案。2.3 基于SAML的實現方案2.3.1 SAML的優勢上面介紹了實現SSO的多種方式，其中SAML是目前最常用的。他具有以下特點：跨域以Cookies實現的SSO，在uni*操作系統支持不是很好。但是SAML是基于*ML的，所以不存在兼容性問題。平安由于*ML的純文本的本質，未經保護的*ML在互聯網傳輸過程中很容易被監聽和竊取。為了保障基于*ML的通信平安，我們需要從傳輸層和消息層兩個層面進展保護。通過傳輸平安，可以保證只允許授權用戶可以基于*ML的Web效勞，目前可擴展控制標記語言(E*tensible Access Control Markup Language，*

31、ACML)和Web效勞策略(WS-Policy)是專門用來解決這個問題的兩個標準;通過消息平安，可以保證Web效勞環境換的*ML消息的完整性和性，Web效勞平安(Web Service Security，WSS)和平安聲明標記語言(Security Assertion Markup Language，SAML)則用來解決這方面的問題。開放性標準SAML是OASIS制定的一種平安性斷言標記語言，它用于在復雜的環境下交換用戶的身份識別信息。2.3.2 概念SAMLSecurity Assertion Markup Language是一個*ML框架，也就是一組協議和規，可以用來傳輸企業用戶明，主要是

32、企業外的身份跨域傳遞。比方，公司idp的用戶要SAAS 應用sp，為了保證身份平安，我們可以采用除了加密簽名等措施，還要采用SAML規來傳輸，傳輸的數據以*ML形式，容符合SAML的推薦標準，這樣我們就可以不要求idp和sp采用什么樣的系統，只要求能理解SAML規即可，顯然比傳統的方式更好。SAML 規是一組Schema定義。他的作用就是貫穿整個系統認證與跳轉流程，主要表達在一下3個方面：a) 認證申明。說明用戶是否已經認證。b) 屬性申明。說明*個Subject的屬性。c) 授權申明。說明*個資源的權限。3.3.3 容SAML斷言一個重要的類型被稱為“bearer斷言，它被用于幫助Web瀏覽

33、器的SSO。下面是一個很短活潑周期的bearer斷言，他是由身份提供者發布給效勞提供方的s:/sp.e*ample./SAML2.斷言中包含<saml:AuthnStatement>和<saml:AttributeStatement>,假設該斷言是效勞提供方用來做控制決定的。<saml:Assertion *mlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" *mlns:*s="./2001/*MLSchema" *mlns:*si="./20

34、01/*MLSchema-instance" ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac" Version="2.0" IssueInstant="2004-12-05T09:22:05Z"><saml:Issuer>s:/idp.e*/SAML2</saml:Issuer><ds:Signature *mlns:ds="./2000/09/*mldsig*">.</ds:Signature

35、><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData InRespo

36、nseTo="aaf23196-1773-2113-474a-fe114412ab72" Recipient="s:/sp.e*ample./SAML2/SSO/POST" NotOnOrAfter="2004-12-05T09:27:05Z"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2004-12-05T09:17:05Z" NotOnOrAfter="2004-12

37、-05T09:27:05Z"><saml:AudienceRestriction><saml:Audience>s:/sp.e*ample./SAML2</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2004-12-05T09:22:00Z" SessionInde*="b07b804c-7c29-ea16-7300-4f3d6f7928ac

38、"><saml:AuthnConte*t><saml:AuthnConte*tClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnConte*tClassRef></saml:AuthnConte*t></saml:AuthnStatement><saml:AttributeStatement><saml:Attribute *mlns:*500="urn:oasis:n

39、ames:tc:SAML:2.0:profiles:attribute:*500" *500:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:.4.1.59.1" FriendlyName="eduPersonAffiliation"><saml:AttributeValue *si:type="*s:string&quo

40、t;>member</saml:AttributeValue><saml:AttributeValue *si:type="*s:string">staff</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion>說明：<saml:Assertion>元素包含如下的子元素：<saml:Issuer>元素，包含了身份提供者的唯一身份。<ds:Signature>

41、;元素，包含了在<saml:Assertion>元素中完整保存的數字簽名.<saml:Subject>元素，定義了認證過的主體，但是在該實例中，因為的原因，主體身份被隱藏在透明的transient標識之后。<saml:Conditions>元素，給出了斷言被認為有效的驗證條件。<saml:AuthnStatement>元素，描述了在身份提供者的認證行為。<saml:AttributeStatement>元素，聲明了認證主體相關的多值屬性。3.3.4 認證流程使用到SAML的角色主要有以下3個：a) 信任方(Service Provid

42、er):利用身份信息；具代表性的信任方是Service Provider，由其決定允許何種請求比方應用程序。以下簡稱SP。b) 斷言方(Identity Provider):提供平安信息；SAML稱之為“Identity Provider。以下簡稱IDP。c) 主題(Subject User):與身份信息相關的用戶。認證效勞流程按用戶代理類別區分為Web登錄及客戶端登錄兩種類型，兩種在流程上略有不同。IDP初始化客戶端認證流程：IDP初始化，其實就是用戶登錄到IDP進展選擇系統。第1步：用戶輸入用戶名以及密碼登錄到IDP。第2步：IDP進展身份認證。第3步：生成一個SAML，表示用戶已經經過了

43、認證。第4步: 將SAML返回給用戶，作為通行憑證。完成單點登錄認證。第5步：用戶在IDP中選擇BH系統。第6步：IDP在用戶選擇之后生成一個Artifact，并返回給用戶作為登錄BH的憑據。第7步：用戶翻開BH客戶端。第8步：BH客戶端將Artifact發送給IDP進展驗證。第9步：返回正常登錄。SP初始化客戶端認證用戶可以直接先登錄一個系統，進展單點登錄。第1步：用戶翻開BH客戶端。第2步：BH客戶端獲取到用戶信息。并發送到IDP第3步：身份認證成功。第4步：生成SAML，表示可以登錄到BH。此時的SAML就作為登錄其他系統的憑據。SP初始Web認證第1步：用戶翻開.zlsoft.中聯主頁

44、。第2步：網頁效勞器獲取用戶信息。并發送到IDP第3步：身份認證成功。第4步：生成SAML，網頁登錄成功。如果用戶需要登錄到BH系統，只需要翻開BH客戶端到IDP去獲取Artifact，就可以登錄成功。三、適合公司產品體系的SSO解決方案3.1產品體系及面臨的問題目前公司產品體系根據運行模式和運行環境大致可以分為WindowsC/S產品，代表為ZLHIS、B/S產品，代表為社區的公用衛生平臺系統、移動設備產品，代表為移動醫生工作站；呈現的特點表現在多種運行方式、多種操作系統平臺、多種開發語言，針對目前的這種情況，不僅要解決不同運行模式的差異，還要解決不同運行環境及開發語言的差異的問題；同時站在

45、產品開放性的角度思考，還要設法解決產品與外部系統互聯互通的問題，雖然，目前這個問題還不明顯，但是隨著應用圍的不斷擴大以及應用深度不斷深入，相信這種要求會逐步增多，所以就目前產品體系規模和未來要面對的問題考量，SSO產品的設計和開發必須要將開放性和兼容性作為重要因素去考慮，就前面歸納總結的SSO實現的關鍵技術點和應用場景的分析，平安斷言標記語言作為OASIS標準以及其實現原理更適合現實的需要。3.2解決方案探討SAMLSecurityAssertionMarkupLanguage，平安性斷言標記語言是一種基于*ML的框架，主要用于在各平安系統之間交換認證、授權和屬性信息，它的主要目標之一就是SS

46、O。在SAML框架下，無論用戶使用哪種信任機制，只要滿足SAML的接口、信息交互定義和流程規，相互之間都可以無縫集成。SAML規的完整框架及有關信息交互格式與協議使得現有的各種身份鑒別機制PKI、Kerberos和口令、各種授權機制基于屬性證書的PMI、ACL、Kerberos的控制通過使用統一接口實現跨信任域的互操作，便于分布式應用系統的信任和授權的統一管理。SAML并不是一項新技術。確切地說，它是一種語言，是一種*ML描述，目的是允許不同平安系統產生的信息進展交換。SAML規由以下局部組成:1.斷言與協議:定義*ML格式的斷言的語法語義以及請求和響應協議。SMAL主要有三種斷言:身份認證斷

47、言、屬性斷言和授權斷言。2.綁定與配置文件:從SAML請求和響應消息到底層通信協議如SOAP或SMTP的映射。3.一致性規:一致性規設置了一種根本標準，必須滿足這一SAML標準的實現才能夠稱為一致性實現。這樣有助于提高互操作性和兼容性。4.平安和的問題:SAML體系構造中的平安風險，具體而言就是SAML如何應對這些風險以及無法解決的風險。基于SAML的WEBSSO運行流程如下：1. 用戶嘗試WebApp1。2. WebApp1生成一個SAML身份驗證請求。SAML請求將進展編碼并嵌入到SSO效勞的網址中。包含用戶嘗試的WebApp1應用程序的編碼網址的RelayState參數也會嵌入到SSO網址中。該Relay