專利名稱：單一簽名安全服務(wù)訪問的制作方法
介紹一般來講，本發(fā)明涉及驗證、授權(quán)和訪問控制，更具體來講，涉及允許用戶只有一個電子ID用于對所有服務(wù)的安全訪問、一般基于PKI(公鑰基礎(chǔ)結(jié)構(gòu))的驗證的方法和系統(tǒng)。
背景驗證、授權(quán)和訪問控制對大多數(shù)(通信)服務(wù)提供商來說是不可缺少的三個領(lǐng)域。唯一的例外是完全開放的服務(wù)和匿名按使用付費服務(wù)。這個規(guī)范涵蓋了其中指定的用戶經(jīng)授權(quán)可使用特定服務(wù)的正常情況。在成功驗證之后，用戶被授予對這些服務(wù)的訪問權(quán)，然后經(jīng)過訪問控制過程。
當(dāng)今針對ISP(因特網(wǎng)服務(wù)提供商)或其它基于IP(因特網(wǎng)協(xié)議)的通信基礎(chǔ)設(shè)施的提供商的驗證解決方案主要是基于用戶名和密碼。RADIUS(遠(yuǎn)程驗證撥號服務(wù))協(xié)議(以及其它協(xié)議、如TACACS+(終端接入控制器訪問控制系統(tǒng)))提供對服務(wù)的訪問，這些服務(wù)提供對驗證信息以及分配到(已驗證)用戶名的授權(quán)的集中管理和確認(rèn)。對于下一代這類協(xié)議，IETF(因特網(wǎng)工程特別任務(wù)組)的工作正在通過Diameter工作組進行。
通常要求用戶對每個服務(wù)有獨立的密碼。隨著提供越來越多的服務(wù)、尤其是當(dāng)各服務(wù)通常要求獨立的密碼驗證時，基于密碼的驗證變得復(fù)雜。為了管理這種復(fù)雜性，用戶通常選擇易于記憶的密碼，并且反復(fù)使用同樣的(用戶名和)密碼。
隨著通過因特網(wǎng)提供越來越多的增值服務(wù)，重要的是為用戶提供基于開放PKI(公鑰基礎(chǔ)結(jié)構(gòu))的用戶驗證來代替基于密碼的驗證的復(fù)雜度和缺陷，防止用戶的服務(wù)被盜用，以及簡化登錄過程(一個電子ID用于對所有服務(wù)的訪問)。還要求強有力的驗證來保護客戶和服務(wù)提供商免受欺詐。
PKI領(lǐng)域的發(fā)展水平尚未達到這種普遍性水平。目前，用戶反而經(jīng)常面對把不同的PKI解決方案(而不是不同的用戶名和密碼)用于對不同服務(wù)的訪問的情況。而且，目前沒有太多服務(wù)是“PKI啟用”的，雖然這種功能性對于SSL/TLS(安全套接層/傳輸層安全性)客戶驗證過程形式的許多服務(wù)可能是潛在的。所述系統(tǒng)通過提供一般基于PKI的驗證，改進現(xiàn)有技術(shù)水平。通過向其它服務(wù)提供商提供確認(rèn)、可能還有授權(quán)服務(wù)，系統(tǒng)可提供用于一般基于PKI的驗證的基礎(chǔ)設(shè)施。
這個規(guī)范描述了通過使用證書和PKI技術(shù)、以及實現(xiàn)通過計算機網(wǎng)絡(luò)提供的支付服務(wù)的機制、用于驗證、授權(quán)和訪問控制的改進方案。PKI解決方案的主要優(yōu)點是普遍性、可縮放性和增加的功能性(加密的密鑰管理、數(shù)字簽名)。將來，用戶會有一個密鑰容器(例如智能卡)，其中包含構(gòu)成用戶的電子ID的私鑰和證書。電子ID通常包括用于不同用途的兩個或三個不同的私鑰/證書對。大部分解決方案采用兩對，一對用于加密(允許僅對這個特定私鑰備份)，另一對用于所有其它目的。常常建議把數(shù)字簽名功能歸于獨立的第三對，但這仍未在產(chǎn)品或服務(wù)中得到廣泛支持。
用戶應(yīng)該能夠自由選擇電子ID的頒發(fā)者(證書服務(wù)提供商)。用戶希望訪問的服務(wù)應(yīng)該不要求使用特定的證書頒發(fā)者。用戶必須能夠自由獲取所需數(shù)量的電子ID。
目前，采用用戶的基于PKI的驗證的服務(wù)提供商通常只能接受來自一個或少數(shù)幾個證書頒發(fā)者的證書。由于證書服務(wù)是不同的，因此服務(wù)提供商必須針對所有頒發(fā)者在某種程度上分別整合。當(dāng)要接受來自不止少數(shù)幾個頒發(fā)者的證書時，這迅速變得過于復(fù)雜而不可用。
同時，全球至少有數(shù)百個公共證書服務(wù)提供商，而且還有更多將要出現(xiàn)。服務(wù)提供商可能也希望接受來自各種各樣公司內(nèi)部證書服務(wù)的證書(這對于內(nèi)聯(lián)網(wǎng)使用是很常見的)。
所述體系結(jié)構(gòu)把針對大量證書頒發(fā)者的整合的復(fù)雜度分到專用組件，從而從服務(wù)本身消除這種復(fù)雜度。用戶必須注冊其想使用的電子ID(即證書)。證書中的名稱及其它特性、如其質(zhì)量等級被鏈接到用戶的服務(wù)簡檔。
在單個位置維護服務(wù)簡檔。某些服務(wù)可能要求優(yōu)質(zhì)電子ID來允許訪問。
證書中的名稱不需要是用戶的真實姓名。根據(jù)策略，這可以是假名、作用名、機構(gòu)識別碼、預(yù)訂名稱等等。
采用電子ID，用戶隨后可登錄網(wǎng)絡(luò)，并獲得對用戶預(yù)訂的所有服務(wù)的訪問權(quán)。所述系統(tǒng)可提供針對為此而準(zhǔn)備的服務(wù)的單一簽名。對于要求其自身驗證的服務(wù)，該系統(tǒng)的優(yōu)點在于，用戶的電子ID可以被再用，而不是必須為每種服務(wù)保持不同的密碼。用戶必須驗證若干次，但始終使用同一方法。這依靠所述確認(rèn)服務(wù)的可用性，以及在某種程度上還依靠授權(quán)服務(wù)。
這種系統(tǒng)的靈活性還允許用戶自由選擇操作系統(tǒng)。用于電子ID方案的軟件常常是平臺相關(guān)的。通過開放式PKI解決方案，用戶可選擇可由選定的操作系統(tǒng)支持的電子ID。
信用卡公司對于通過因特網(wǎng)的支付開始要求用戶驗證，而密碼驗證僅在短期內(nèi)是可接受的。建立一般PKI將允許信用卡公司接受用戶已經(jīng)擁有的電子ID(只要它是合格的)，而不需要頒發(fā)獨立的電子ID用于進行支付。
所述系統(tǒng)將提供一種用于增值服務(wù)、如視頻點播(VOD)的安全驗證、授權(quán)和訪問控制的方式，以及提供一種用于保證支付安全的方式。
發(fā)明概述一般來講，本發(fā)明涉及驗證、授權(quán)和訪問控制，更具體來講，涉及允許用戶只有一個電子ID用于對所有服務(wù)的安全訪問、基于一般公鑰基礎(chǔ)結(jié)構(gòu)的驗證的方法和系統(tǒng)。所述系統(tǒng)通過提供一般基于PKI的驗證，改進現(xiàn)有技術(shù)水平。通過向其它服務(wù)提供商提供確認(rèn)、可能還有授權(quán)服務(wù)，系統(tǒng)可提供用于一般基于PKI的驗證的基礎(chǔ)設(shè)施。
本發(fā)明涉及如所附獨立權(quán)利要求1所述的系統(tǒng)。此外，本發(fā)明涉及如所附獨立權(quán)利要求11所述的用途。本發(fā)明還涉及如所附獨立權(quán)利要求13所述的方法。在從屬權(quán)利要求中描述了本發(fā)明的有利實施例。
參照附圖的說明現(xiàn)在將參照附圖來描述本發(fā)明，其中

圖1表示驗證和授權(quán)體系結(jié)構(gòu)概況；圖2表示用于檢驗用戶證書的有效性的備選方法；圖3表示驗證、授權(quán)檢查和服務(wù)訪問過程的流程圖；圖4表示對增值服務(wù)的訪問，以及圖5表示確認(rèn)服務(wù)概況。
圖1表示根據(jù)本發(fā)明的系統(tǒng)體系結(jié)構(gòu)。用戶通常通過SSL/TLS客戶機驗證來進行驗證，并且在訪問服務(wù)器上通過關(guān)于所預(yù)訂的一組服務(wù)的菜單得到對萬維網(wǎng)接口的訪問權(quán)。客戶機與訪問服務(wù)器之間的通信必須受到密碼保護。SSL/TLS是優(yōu)選的選擇，因為這是保護萬維網(wǎng)(HTTP)通信的常用方式，并且可結(jié)合用戶驗證。基于雙方之間的IPSec/VPN(因特網(wǎng)協(xié)議安全性/虛擬專用網(wǎng))的一種解決方案可以是備選方案。
所應(yīng)用的驗證協(xié)議(例如具有客戶機和服務(wù)器驗證的SSL/TLS)按照作為協(xié)議的一部分傳遞給訪問服務(wù)器的用戶證書中的名稱暗中識別用戶。用戶還必須使用相應(yīng)的私鑰來簽署證明擁有私鑰的競爭/響應(yīng)序列。
若給定用戶的證書和簽名，訪問服務(wù)器可完成用戶驗證過程。但是，當(dāng)采用撤銷檢查且以允許來自不同證書頒發(fā)者的不同證書的方式適當(dāng)進行時，證書確認(rèn)是在各訪問服務(wù)器上運行的過于沉重的過程。在該體系結(jié)構(gòu)中，獨立組件、即確認(rèn)服務(wù)被引入，以承擔(dān)證書處理(的一部分)的責(zé)任(和負(fù)荷)?？筛鶕?jù)需要重復(fù)確認(rèn)服務(wù)。最后，訪問服務(wù)器可以僅提取用戶的證書，并將它傳送到確認(rèn)服務(wù)。返回的是對證書有效性的“是/否”回答、其質(zhì)量等級(就可準(zhǔn)許的授權(quán)而言可能是相關(guān)的)、從用戶證書中的名稱得到的用戶名以及必要時可能更多的信息。但是，也可按照不同方式在訪問服務(wù)器與確認(rèn)服務(wù)之間分開負(fù)荷，例如通過在訪問服務(wù)器上本地執(zhí)行大部分證書處理，并且主要把撤銷檢查的任務(wù)(一般非常消耗資源)留給確認(rèn)服務(wù)。
用戶的簡檔應(yīng)該保存在一個位置、即授權(quán)服務(wù)中。從用戶的證書名稱到相應(yīng)用戶名的映射是簡檔的組成部分，因此確認(rèn)服務(wù)調(diào)用授權(quán)服務(wù)，以便在從證書提取名稱之后獲得這個映射。或者，確認(rèn)服務(wù)可把證書名稱返回到訪問服務(wù)器，訪問服務(wù)器則可通過對授權(quán)服務(wù)的獨立調(diào)用來執(zhí)行名稱映射。在這種情況下，在確認(rèn)服務(wù)與授權(quán)服務(wù)之間沒有接口。
圖2表示驗證、授權(quán)檢查和服務(wù)訪問過程的流程圖。若干協(xié)議可用于確認(rèn)服務(wù)。如果確認(rèn)服務(wù)要作為獨立服務(wù)提供給服務(wù)提供商，則該協(xié)議必須是標(biāo)準(zhǔn)類型的。OCSPv1(在線證書狀態(tài)協(xié)議，版本1)是一種備選方案，它使得能夠檢驗證書的撤銷狀態(tài)，并返回某個附加信息、如用戶名。但是，僅使用非指定的“擴展名”，無法以標(biāo)準(zhǔn)化方式向確認(rèn)服務(wù)傳遞完整證書。OCSPv2屬于高級草案RFC，并將提供發(fā)送完整證書的可能性。SCVP(簡單證書確認(rèn)協(xié)議)具有與OCSPv2同樣的狀態(tài)，并提供相同的功能性。XKMS(XML密鑰管理服務(wù))是另一個備選方案，如其它基于XML的機制一樣，例如采用SOAP(簡單對象訪問協(xié)議)。
若給定已驗證的用戶身份，訪問服務(wù)器則查詢授權(quán)服務(wù)關(guān)于指定的用戶應(yīng)該被準(zhǔn)許的訪問權(quán)限。查詢可通過例如用戶的驗證過程的質(zhì)量等附加信息以及例如用戶的當(dāng)前位置、時刻等上下文信息來擴充。對授權(quán)服務(wù)的訪問應(yīng)該基于標(biāo)準(zhǔn)協(xié)議，這些協(xié)議可以是LDAP(輕型目錄訪問協(xié)議)、RADIUS、它的有計劃的后續(xù)者DIAMETER或其它某種協(xié)議。
還能夠把向授權(quán)服務(wù)的查找委托給確認(rèn)服務(wù)。在這種情況下，訪問服務(wù)器僅執(zhí)行對確認(rèn)服務(wù)的調(diào)用，并找回用戶名以及與上述驗證過程有關(guān)的其它信息和用戶將被準(zhǔn)許的授權(quán)。
在這個過程之后，將為用戶提供正確的服務(wù)菜單。服務(wù)選擇是下一個步驟，如以下所述。
圖2的流程圖表示在驗證、授權(quán)檢查和服務(wù)訪問過程中采取的步驟。
下面將描述典型連接建立以及對服務(wù)的訪問。用戶設(shè)備或家庭網(wǎng)絡(luò)經(jīng)由某種接入點連接到網(wǎng)絡(luò)運營商提供的基礎(chǔ)設(shè)施，接入點通常提供在數(shù)據(jù)鏈路或接入層以及網(wǎng)絡(luò)層的協(xié)議，即IP協(xié)議。接入點沒有在圖1中示出，因為它對于從用戶到訪問服務(wù)器的萬維網(wǎng)接入只是作為路由器。接入點可以分為兩個組件一個在數(shù)據(jù)鏈路/接入層提供服務(wù)，另一個為IP路由器。
當(dāng)用戶設(shè)備連接到網(wǎng)絡(luò)基礎(chǔ)設(shè)施時，通常為它提供了對所允許通信路徑的缺省最小集合的訪問權(quán)。在所示體系結(jié)構(gòu)中，到訪問服務(wù)器的路由必須被啟用，域名服務(wù)(DNS)也將被啟用。其它服務(wù)/路徑可被添加到這個最小配置中。
當(dāng)用戶在用戶設(shè)備上打開瀏覽器時，這必須被定向在訪問服務(wù)器處的URL，以便用戶獲得對服務(wù)的訪問權(quán)。然后用戶必須通過驗證過程和授權(quán)檢查，并被給予對服務(wù)菜單的訪問權(quán)。
基本上有三種服務(wù)可用通信服務(wù)，基于萬維網(wǎng)的服務(wù)，以及包括多媒體的媒體服務(wù)。第三類可描述為另外兩類的組合。下面描述對這些分類中的每一種所采取的動作。
通信服務(wù)當(dāng)用戶選擇通信服務(wù)時，這個請求需要傳遞到用戶的接入點，以便啟用到所選目的地的路由。路由可在IP層被啟用，為從用戶的IP地址(的范圍)到某個(某些)目的地(的范圍)的業(yè)務(wù)開通。路由還可在數(shù)據(jù)鏈路層例如通過建立ATM(異步轉(zhuǎn)移模式)虛電路來啟用。
通信服務(wù)的一個實例可以是通過ISP的一般因特網(wǎng)訪問。選擇服務(wù)菜單中的因特網(wǎng)訪問將啟用從用戶到ISP的接入節(jié)點(邊界路由器)的路由，從ISP的接入節(jié)點可繼續(xù)接入。
訪問服務(wù)器需要把正確的命令傳遞到用戶的接入點，以便啟用所請求的通信服務(wù)。若干協(xié)議可用于這個目的，其中RADIUS作為最常用的備選方案。DIAMETER是RADIUS的有計劃后續(xù)者。
對于在訪問服務(wù)器上從服務(wù)菜單對基于萬維網(wǎng)的服務(wù)的用戶訪問，存在三種不同的情況。
在第一種情況中，訪問服務(wù)器通過向服務(wù)傳遞單一簽名令牌，以單一簽名方式傳遞對服務(wù)的直接訪問。在最簡單形式中，這是在HTTPPost操作中用于服務(wù)的用戶名和密碼，從而使用戶透明地登錄到該服務(wù)。然后，用戶被重新定向到該服務(wù)，或者訪問服務(wù)器繼續(xù)作為HTTP代理媒介來工作。對于單一簽名，有若干產(chǎn)品和技術(shù)可用，以及可使用來自這類技術(shù)的令牌。訪問服務(wù)器也可能把cookie寫入用戶的瀏覽器，它在用戶直接訪問該服務(wù)時將作為單一簽名令牌被識別和接受。該服務(wù)可有權(quán)訪問授權(quán)服務(wù)，例如以便檢查與服務(wù)使用有關(guān)的更詳細(xì)特權(quán)。
在第二種情況中，服務(wù)是在所述系統(tǒng)的域內(nèi)提供的，但要求獨立驗證。用戶的電子ID(私鑰和證書)被用于服務(wù)，即用戶具有單一機制。服務(wù)有權(quán)訪問確認(rèn)服務(wù)，并且還可使用授權(quán)服務(wù)。
在第三種情況中，服務(wù)是在所述系統(tǒng)的域之外提供的。如果對于這種驗證啟用了服務(wù)，則使用該用戶的電子ID(私鑰和證書)，即用戶具有單一機制。服務(wù)有權(quán)訪問確認(rèn)服務(wù)，但由于它不在系統(tǒng)的域中，因此不是經(jīng)常有訪問授權(quán)服務(wù)的權(quán)限。
確認(rèn)服務(wù)是通用的服務(wù)，它可被提供給系統(tǒng)的域之內(nèi)以及之外的合作方。確認(rèn)服務(wù)可配置成根據(jù)調(diào)用它的服務(wù)返回不同的信息(例如不同的用戶名)。這是基于PKI驗證的一般性的直接結(jié)果。對于基于密碼的驗證，不能允許這種訪問，因為密碼會泄露給外部各方。
但是，授權(quán)服務(wù)通常只應(yīng)該在系統(tǒng)的域內(nèi)可訪問。允許外部各方訪問域內(nèi)授權(quán)信息或者甚至通過相同服務(wù)管理授權(quán)信息，這在大多數(shù)情況下不是可接受的。
媒體/多媒體服務(wù)如上所述，(多)媒體服務(wù)可視為通信服務(wù)和基于萬維網(wǎng)的服務(wù)的組合。某些媒體服務(wù)可完全實現(xiàn)為基于萬維網(wǎng)或者通信，但通常的情況是提供用于服務(wù)建立的基于萬維網(wǎng)的接口的服務(wù)以及依靠網(wǎng)絡(luò)中功能性的服務(wù)實現(xiàn)。
如果訪問服務(wù)器用作用戶與媒體服務(wù)之間的代理，則可能截取通信并執(zhí)行支持動作、例如發(fā)起它們之間的VPN或者向多播成員系統(tǒng)提供信息。
圖3表示檢驗用戶證書的有效性的備選方法。不是把用戶的證書名稱發(fā)送到授權(quán)服務(wù)，而是把它發(fā)送到訪問服務(wù)器，訪問服務(wù)器再從授權(quán)服務(wù)接收指定的用戶身份。
圖4表示對增值服務(wù)、如視頻點播(VOD)的驗證、授權(quán)和訪問以及安全支付(根據(jù)按使用付費)的一個實例。
采用圖1所示的驗證體系結(jié)構(gòu)對用戶進行驗證。內(nèi)容在會話的整個持續(xù)時間中受到加密保護，以及根據(jù)按使用付費來保證支付。內(nèi)容可采用電子ID所提供的用戶密鑰來加密。用戶可選擇支付方法、例如發(fā)票或信用卡，并采用用于驗證的電子ID來簽署交易?；蛘?，用戶可選擇用于支付以及用于保證交易安全性的外部機制。
現(xiàn)在參照圖2更詳細(xì)地描述本發(fā)明。訪問服務(wù)器通過驗證用戶以及為其提供適當(dāng)?shù)姆?wù)菜單，用作用戶的服務(wù)接入點。為了在系統(tǒng)中執(zhí)行其任務(wù)，訪問服務(wù)器必須-支持HTTPS(基于SSL/TLS的HTTP)或者能夠提供安全通信信道的其它方法；-能夠向客戶機/用戶驗證其自身，最好通過使用PKI技術(shù)(例如SSL/TLS服務(wù)器驗證)；-支持與確認(rèn)服務(wù)和授權(quán)服務(wù)進行通信所需的協(xié)議；-支持用于基于PKI的客戶機/用戶驗證的一個或多個協(xié)議，通常為具有客戶機驗證的SSL/TLS；-實現(xiàn)向用戶顯示必要信息(如服務(wù)菜單)以及處理用戶輸入所需的功能性；-能夠用作用戶與服務(wù)之間的代理，即在它們之間透明地傳遞信息。
用戶必須把瀏覽器定向到訪問服務(wù)器提供的萬維網(wǎng)接口，以便訪問服務(wù)。通常，如上所述，將通過具有客戶機驗證的SSL/TLS來直接驗證用戶。
有兩種備選方法如果采用另一種基于PKI的驗證方法，則SSL/TLS會話可以僅通過服務(wù)器驗證來建立，以及用戶驗證協(xié)議則可在該安全信道上運行。如果對于驗證方法存在若干備選者，則用戶可能面對用于選擇方法的明文(即純HTTP)頁面。選擇之后，驗證例如通過建立具有客戶機驗證的SSL/TLS會話來繼續(xù)進行。
如上所述，訪問服務(wù)器依靠從用戶獲得用戶的證書。還可實現(xiàn)用于獲得證書的其它方法、如目錄查找。
如以下部分所述，關(guān)于確認(rèn)服務(wù)，盡可能多的本地證書處理應(yīng)該在訪問服務(wù)器中禁用，并留給確認(rèn)服務(wù)來處理。訪問服務(wù)器必須通過確認(rèn)服務(wù)來確認(rèn)用戶的證書，檢驗用戶對驗證協(xié)議的競爭部分的簽名，并根據(jù)這個驗證的成功或失敗進行動作。競爭的創(chuàng)建以及對競爭上簽名的檢驗可在訪問服務(wù)器外部進行。由于訪問服務(wù)器易受到來自用戶的攻擊，因此可能希望采用受到更多保護的計算機用于這些安全性關(guān)鍵操作。
緊接用戶驗證的第一動作通常是從授權(quán)服務(wù)取出用戶的服務(wù)列表，除非這已經(jīng)從確認(rèn)服務(wù)中獲得。稍后，訪問服務(wù)器按照用戶輸入、根據(jù)現(xiàn)行策略以及與用于要求針對用戶簡檔檢查的動作的授權(quán)服務(wù)配合進行動作。如圖1所示，可實現(xiàn)單一簽名機制。
對于證書處理優(yōu)化了確認(rèn)服務(wù)。它接收證書或者證書的標(biāo)識及其頒發(fā)者，以及-讀取頒發(fā)者的名稱。
-從“好”密鑰的預(yù)先評估列表中取出頒發(fā)者的公鑰。所有交叉驗證體系或?qū)哟味冀?jīng)過預(yù)處理，以及所有頒發(fā)者公鑰是直接可信的，即不需要對證書鏈的處理。
-最好是通過對于由正規(guī)預(yù)取CRL(證書撤銷列表)所得到的預(yù)處理撤銷信息的本地調(diào)用來執(zhí)行撤銷檢查。
-如果已收到完整證書，則分析證書，檢查簽名和有效性時期以及導(dǎo)出內(nèi)容。這對于不同的證書簡檔需要分別處理。
-導(dǎo)出從證書信息映射的信息，例如從證書中的名稱導(dǎo)出的用戶名、質(zhì)量等級(根據(jù)所述證書策略的分析來預(yù)先確定)等等。信息可以是通用的或者專門針對需要證書驗證的實體。
這些操作可以在確認(rèn)服務(wù)中被優(yōu)化，提供必要的快速響應(yīng)時間。具體來講，對證書鏈的處理和撤銷檢查通常對服務(wù)器強加重負(fù)荷。為此，適當(dāng)?shù)某蜂N檢查在當(dāng)今的PKI啟用服務(wù)中常常被抑制。確認(rèn)服務(wù)器依靠對撤銷信息的預(yù)處理以便加速該過程。
若干協(xié)議可用于確認(rèn)服務(wù)。OCSP(在線證書狀態(tài)協(xié)議)版本1是目前可用的，但沒有傳送完整證書的標(biāo)準(zhǔn)方法。作為因特網(wǎng)草案正在開發(fā)中的OCSP版本2增加了這種可能性?？裳a充或取代OCSP的備選協(xié)議是作為因特網(wǎng)草案協(xié)議的SCVP(簡單證書確認(rèn)協(xié)議)以及XKMS(XML密鑰管理體系)。協(xié)議也可基于SOAP(簡單對象訪問協(xié)議，實質(zhì)上為基于HTTP的XML)或類似技術(shù)，或者可設(shè)計某種專有協(xié)議。所有這些協(xié)議提供了向調(diào)用者返回附加信息以及對驗證請求本身的“是/否/未知”回答的可能性。
OCSP主要目標(biāo)是作為對來自一個認(rèn)證機構(gòu)的CRL頒發(fā)的替代。取代CRL或者作為對它的補充，證書頒發(fā)者提供OCSP接口，它僅回答關(guān)于這個認(rèn)證機構(gòu)頒發(fā)的證書的有效性的請求。在我們的上下文中，確認(rèn)服務(wù)將對所支持的所有認(rèn)證機構(gòu)提供一個OCSP服務(wù)。
OCSPv1把撤銷檢查描述為OCSP服務(wù)的唯一功能性。這太窄，因此建議對它進行增強。首先，確認(rèn)服務(wù)應(yīng)該不僅檢查證書是否已經(jīng)被撤銷，而且還檢查它是否在其有效期之內(nèi)以及頒發(fā)者在證書上的簽名是否正確。此外，確認(rèn)服務(wù)還應(yīng)該分析證書，并通過確定質(zhì)量等級和用戶名以及可能還有更多的信息對內(nèi)容起作用。
OCSP通過讓調(diào)用者以數(shù)字方式簽署請求(的部分)的可能性來提供對請求的客戶機驗證和完整性保護。確認(rèn)服務(wù)器可相應(yīng)地簽署響應(yīng)。這也可對其它協(xié)議備選者來實現(xiàn)。簽署的響應(yīng)可能極為重要，因為偽造或假造的響應(yīng)可能構(gòu)成重大威脅。簽署的請求可以是必要的，以便返回調(diào)用者相關(guān)信息，除非以其它方式對調(diào)用者進行驗證。
但是，由于簽名處理(通常還意味著證書處理)相當(dāng)費時間，因此可能更好的是確保對確認(rèn)服務(wù)的調(diào)用是通過安全信道、例如通過VPN解決方案來進行。對于訪問服務(wù)器與確認(rèn)服務(wù)器之間的信道、也可能是從其它域內(nèi)服務(wù)到確認(rèn)服務(wù)的信道，這無疑應(yīng)該是這樣。如果向外部各方提供確認(rèn)服務(wù)，則必須實現(xiàn)對于簽署的請求和應(yīng)答的規(guī)定，因為可能無法對所有這些外部各方要求VPN之類。
下面涵蓋對采用確認(rèn)服務(wù)的服務(wù)器的要求。具體來講，這是訪問服務(wù)器。
值得注意的是，這種服務(wù)駐留在訪問服務(wù)器中。為了使用確認(rèn)服務(wù)，(部分)證書處理在這些服務(wù)中應(yīng)該是“短路的”。下面描述服務(wù)器中的處理的一些情況-SSL客戶機驗證服務(wù)器處的SSL處理必須提取客戶機的證書，并且不進一步處理就把它轉(zhuǎn)發(fā)到確認(rèn)服務(wù)，或者在轉(zhuǎn)發(fā)完整證書或從其中導(dǎo)出的信息之前本地執(zhí)行一些處理。根據(jù)應(yīng)答，SSL建立或者繼續(xù)或者中止。
-數(shù)字簽署消息的接收客戶機(發(fā)送方)的證書可從消息中提取(或者通過其它方式獲得)并被發(fā)送到確認(rèn)服務(wù)?；蛘?，一些證書處理可在證書或從其中導(dǎo)出的信息被發(fā)送到確認(rèn)服務(wù)之前被本地執(zhí)行。在成功確認(rèn)之后，可本地檢驗在消息本身上的簽名。確認(rèn)服務(wù)也可被增強到在系統(tǒng)中處理對消息和證書的所有簽名處理。
-隨后將被用于到給定對應(yīng)方的消息或信道的加密(的密鑰管理)的證書的確認(rèn)處理類似于數(shù)字簽署消息中證書的接收。
-VPN的建立處理與SSL客戶機驗證情況大致相同。
-其它基于PKI的驗證協(xié)議服務(wù)器必須獲得客戶機的證書，然后按照上述情況所述來調(diào)用確認(rèn)服務(wù)。證書處理可完全留給確認(rèn)服務(wù)來處理，或者可進行部分本地處理。
為了實現(xiàn)對確認(rèn)服務(wù)的調(diào)用(以上列出的協(xié)議備選者)，對服務(wù)器軟件的修改是必要的。可被“短路”的本地處理量取決于對特定服務(wù)器平臺可能的修改。為得到最佳性能，對確認(rèn)服務(wù)的調(diào)用應(yīng)該與服務(wù)器中其它處理交替進行，部分或完全取代在大多數(shù)服務(wù)器平臺中已經(jīng)到位的功能性(本地證書處理)。這類修改通常相當(dāng)復(fù)雜，取決于平臺的開放性。此備選方案是額外功能性在可用的開放接口之上的添加，其中本地證書處理僅被短路到按照配置參數(shù)可能的程度。
還能夠為用戶(客戶機)提供到確認(rèn)服務(wù)的接口。在這種情況下，用戶的瀏覽器(通常也可能是用戶設(shè)備中的其它軟件)中的證書處理完全或部分通過對確認(rèn)服務(wù)的調(diào)用、而不是本地證書處理來代替。這類似于服務(wù)器的情況。這種接口的主要用途是對SSL服務(wù)器證書的處理，但還存在與VPN建立、數(shù)字簽署消息的接收以及用于到對應(yīng)方的消息/業(yè)務(wù)量的加密的證書確認(rèn)等有關(guān)的用途。在這種情況下，來自確認(rèn)服務(wù)的應(yīng)答可被簽署，以及來自用戶的請求可被簽署。如果確認(rèn)服務(wù)代表用戶檢驗證書的簽名，則在標(biāo)準(zhǔn)瀏覽器中(例如在較新版本的Microsoft OS中)預(yù)先配置的(目前大約150個)證書頒發(fā)者公鑰的列表可從用戶設(shè)備中刪除。用戶對這類頒發(fā)者公鑰的管理(信任)是PKI使用的主要障礙。
關(guān)于對不同證書頒發(fā)者的支持，在確認(rèn)服務(wù)的引入背后存在兩個基本概念-效率，通過針對證書處理優(yōu)化此服務(wù)，尤其是通過避免對證書鏈的處理以及通過根據(jù)本地數(shù)據(jù)庫查找而不是CRL處理來檢查撤銷。
-提供希望從一個以上證書頒發(fā)者接收證書的服務(wù)的單一整合點。
目前，采用基于PKI的驗證的服務(wù)必須針對希望從其接受證書的各證書頒發(fā)者分別進行整合。具體來講，整合復(fù)雜度與不同的證書格式、不同的命名方案、撤銷信息的不同接入點以及頒發(fā)者公鑰的管理有關(guān)。因此，服務(wù)只能與少數(shù)幾個所選證書頒發(fā)者直接整合。確認(rèn)服務(wù)從服務(wù)中消除了這種復(fù)雜度。
但是，當(dāng)要支持許多證書頒發(fā)者時，甚至確認(rèn)服務(wù)也面臨復(fù)雜度問題。主要復(fù)雜度是確定質(zhì)量等級，如下一節(jié)所述。頒發(fā)者公鑰的管理必須是可靠的，且連續(xù)監(jiān)測有關(guān)撤銷和其它更新情況。來自不同頒發(fā)者的證書格式必須通過特定分析器來解釋(雖然標(biāo)準(zhǔn)化簡檔在某種程度上有助于此任務(wù)，但需要確定所述簡檔)。從技術(shù)觀點來看，確認(rèn)服務(wù)不太復(fù)雜，但此服務(wù)的管理需要資源。但是，在許多上下文中，最好是使這種復(fù)雜度集中，而不是必須單獨對每一個服務(wù)來應(yīng)付它。
這針對希望通過此服務(wù)支持多少以及哪些證書頒發(fā)者的問題。全球存在數(shù)百個公開證書頒發(fā)者服務(wù)，還有更多將要出現(xiàn)。另外，人們將越來越多地發(fā)現(xiàn)公司(內(nèi)聯(lián)網(wǎng))系統(tǒng)，它們可能基于來自例如Microsoft或IBM/Lotus的、允許任何人建立證書頒發(fā)服務(wù)的標(biāo)準(zhǔn)產(chǎn)品。雖然這些服務(wù)中的大部分將取得極差的質(zhì)量和信任等級(例如未受到任何策略支持的頒發(fā))，并且在公司內(nèi)聯(lián)網(wǎng)之外實際上是無用的，但可能出現(xiàn)希望能夠接受來自合作公司或公司客戶的證書的情況。
對這個問題的決定更多地屬于管理而不是技術(shù)性的，只要確認(rèn)服務(wù)實現(xiàn)的縮放屬性是足夠的。
一個極重要的要求在于，證書必須直接或間接地提供進一步處理所需的信息，尤其是可用于訪問控制和記帳的名稱。
對于證書和質(zhì)量等級的分類，證書頒發(fā)服務(wù)由以下組件來定義-法律體制和協(xié)議；-證書策略，它提供對服務(wù)相關(guān)的程序的要求，并且通常涵蓋法律體制和協(xié)議的多個方面(但是常常必須使之明確，從而保證獨立點)；-證書實施說明，它說明這個特定證書頒發(fā)服務(wù)如何滿足策略的要求-可表示內(nèi)部程序文檔；-證書格式，特別是命名慣例；-針對其它參與者的信任模型，尤其是針對分層結(jié)構(gòu)和交叉驗證體系的看法；-證書、撤銷信息、策略信息和其它相關(guān)信息的信息/目錄服務(wù)。
證書服務(wù)的質(zhì)量方面主要從證書策略中導(dǎo)出。策略概述了用戶必須完成以便獲取證書的登記過程的要求(例如電子申請對具有物理驗證的個人外貌)、頒發(fā)者同意在出錯情況下承擔(dān)的責(zé)任、強加到服務(wù)的操作上的安全性要求等等。幸好有幾個用于編寫策略的標(biāo)準(zhǔn)框架，并且大多數(shù)證書頒發(fā)者遵守其中之一。因此，證書策略可精確地進行比較。
但是，證書策略的分類是要求某種專門知識的主要人工任務(wù)。需要用于分類的分類標(biāo)準(zhǔn)和方法基礎(chǔ)。哪種標(biāo)準(zhǔn)必須被滿足以便達到某種質(zhì)量等級？增加其它復(fù)雜度、例如以外語編寫的策略以及引用外國的法律和法規(guī)。除非有人提出用于策略的分類/分級的獨立服務(wù)，否則不得不對所有頒發(fā)者獨立完成評估過程。
這意味著必須從少數(shù)重要頒發(fā)者開始，以后再根據(jù)需要擴充。
必須進行針對所支持策略的連續(xù)監(jiān)測。但是，策略通常描述變化過程，而且許多頒發(fā)者將在策略大量變化的情況下支持其它各方的主動通知。
質(zhì)量分類可以只是簡單的數(shù)值，例如1-4，其中1作為頂層以及4作為差質(zhì)量等級。沒有對這些等級的標(biāo)準(zhǔn)化作太多工作。在EU內(nèi)，“合格證書”等級(或多或少)已經(jīng)作為優(yōu)質(zhì)指示符建立，以便支持正式數(shù)字簽名。在美國，“聯(lián)邦橋認(rèn)證機構(gòu)”定義了一些質(zhì)量等級。向聯(lián)邦部門提供服務(wù)的證書頒發(fā)者應(yīng)該通過指出其本身策略與橋所定義的適當(dāng)質(zhì)量等級之間策略映射的橋進行交叉驗證。ETSI目前正在進行“非合格策略框架”的工作，它將定義對于策略的分類應(yīng)該考慮的一些指示符。
質(zhì)量分類也可以比等級指示符細(xì)致得多。根據(jù)策略框架和ETSI的當(dāng)前工作，一些參數(shù)可從策略中導(dǎo)出到可返回給調(diào)用者的結(jié)構(gòu)中。例如，證書頒發(fā)者愿意承擔(dān)的責(zé)任可能對可由驗證根據(jù)來自頒發(fā)者的證書所支持的交易的值產(chǎn)生影響。策略所指出的權(quán)限是另一個重要參數(shù)。
注意，另一個問題在于，質(zhì)量等級(策略及相關(guān)實施)只是證書頒發(fā)者所要求的，還是要求由第三方證明來支持。許多證書策略要求對服務(wù)的第三方審計，以便確保實際操作依據(jù)策略、實施說明和內(nèi)部程序。這種審計報告可能意味著更高的質(zhì)量等級，或者至少是關(guān)于等級的更大確定性。在這里，ISO9000或者ISO17799等證書也包括在內(nèi)。
最后，注意，服務(wù)質(zhì)量不一定意味著可信。(虛)“Mafia CA”可能實現(xiàn)高質(zhì)量等級，但仍然不清楚其證書應(yīng)被接受。
除了證書策略和質(zhì)量等級之外，證書頒發(fā)服務(wù)的其它方面也必須被考慮。具體來講，可能對證書格式提出要求，例如必須存在或者不應(yīng)該存在的某些字段、屬性或擴展名。命名是獨立的問題，對于當(dāng)今定義的系統(tǒng)，必須能夠從證書中的名稱轉(zhuǎn)換成有效的用戶名。在某些情況下可能出現(xiàn)的另一個要求是，名稱必須是“真實的”，而不是假名。
圖5表示確認(rèn)服務(wù)的所建議體系結(jié)構(gòu)。
它由以下部分構(gòu)成-OCSP服務(wù)器，處理與此協(xié)議相關(guān)的語法和語義。其它協(xié)議的其它前端可在稍后添加，如虛線所示。
-確認(rèn)引擎，處理證書、檢查有效性以及導(dǎo)出信息。
-從確認(rèn)服務(wù)管理的所有認(rèn)證機構(gòu)中預(yù)取及處理CRL的獨立過程。
-可能需要OCSP客戶機訪問來自不支持CRL的證書頒發(fā)者的撤銷信息。
-保存關(guān)于證書頒發(fā)者、其公鑰、策略及相關(guān)質(zhì)量等級的信息、通過上述過程更新的撤銷信息以及可從證書中導(dǎo)出的附加信息的數(shù)據(jù)庫。
-針對授權(quán)服務(wù)的接口(可能為LDAP)，以便得出從證書中的名稱到系統(tǒng)域的有效用戶名以及可能其它域的其它名稱形式的轉(zhuǎn)換。如上所述，這個接口可以來自訪問服務(wù)器而不是確認(rèn)服務(wù)。
-服務(wù)幾乎肯定需要加密硬件(圖5中未示出)。
關(guān)于操作、請求和應(yīng)答，OCSP服務(wù)器和其它前端執(zhí)行與確認(rèn)服務(wù)有關(guān)的協(xié)議相關(guān)處理。這包括確認(rèn)和產(chǎn)生對數(shù)字簽署請求及應(yīng)答的簽名。
前端具有到確認(rèn)引擎的API。確認(rèn)引擎必須在包含證書時對它分析，或者以其它方式對所提交的證書信息起作用。
然后再對證書進行確認(rèn)檢查簽名“正確”，證書格式“正確”，在有效期內(nèi)，沒有被撤銷或掛起。這些檢查的一部分依靠完整證書，并且在僅提交證書摘要時無法進行。根據(jù)證書中所指明的策略來取出質(zhì)量等級(或者在頒發(fā)者沒有在其證書中包括所建議的策略標(biāo)識符擴展名的異常情況下從預(yù)先配置的知識中提取)。然后，從數(shù)據(jù)庫中取出所導(dǎo)出的信息，并且將它們都通過API、以API所指定的形式返回給OCSP服務(wù)器(或其它前端)。
撤銷檢查通常只是本地數(shù)據(jù)庫查找，因為CRL預(yù)取組件將收集必要信息(如以下所述)。但是，如果證書頒發(fā)者只對撤銷檢查提供OCSP接口，并且沒有CRL頒發(fā)服務(wù)，則確認(rèn)引擎實際上必須調(diào)用頒發(fā)者的OCSP服務(wù)。
也可想象確認(rèn)服務(wù)可能被鏈接、并且調(diào)用是采用遠(yuǎn)程確認(rèn)服務(wù)的前端所支持的協(xié)議(不一定為OCSP)來進行的情況。
據(jù)我們所知，當(dāng)今大部分認(rèn)證機構(gòu)采用簽署的CRL來通知證書的撤銷和掛起。CRL通常被定期頒發(fā)，其中每個CRL包括下一版本的頒發(fā)的計劃時間。但是，CRL可在必要時提前頒發(fā)。完整CRL是通常情況，即CRL包含所有撤銷的證書的序列號。當(dāng)下一個CRL的頒發(fā)時間是在證書的正常到期時間之后時，從將來的CRL中刪除證書?？刹捎忙?CRL、又稱作增量CRL，其中CRL僅包含自前一個CRL以來的新條目。通過Δ-CRL，完整CRL被定期頒發(fā)，但比僅采用完整CRL的情況的次數(shù)少得多。
因此，CRL預(yù)取組件的正常情況是對所支持的各證書頒發(fā)者運行守護(deamon)進程，以及在計劃頒發(fā)時間之后的極短時間提取并處理頒發(fā)者的完整CRL。處理結(jié)果存儲在數(shù)據(jù)庫中。但是，有一些需要支持的變量，以及確認(rèn)服務(wù)需要知道不同證書頒發(fā)者的CRL策略，如其策略中所說明的那樣。確認(rèn)服務(wù)當(dāng)然還需要知道CRL的分布點，以及需要有權(quán)訪問這些點。CRL應(yīng)該是公開可用的，但某些頒發(fā)者可能希望對提取收費，在該情況中，費用必須被傳遞給調(diào)用者或者以其它某種方式來記帳。
如果頒發(fā)者支持Δ-CRL，則這應(yīng)該由CRL預(yù)取組件來使用，因為需要對每個取操作下載的數(shù)據(jù)量遠(yuǎn)小于對完整CRL所需的量。
如果頒發(fā)者已經(jīng)指定CRL之間的長間隔，則這還可能意味著“在需要時頒發(fā)CRL”策略。在這種情況下，CRL預(yù)取組件應(yīng)該定期輪詢新的CRL，而不是等待下一個計劃頒發(fā)。確認(rèn)服務(wù)在CRL之間愿意接受的間隔是調(diào)諧參數(shù)，它影響確認(rèn)服務(wù)的質(zhì)量。這個間隔應(yīng)該等于輪詢時間，以及具有高于此間隔的CRL頻率的所有頒發(fā)者都應(yīng)該被輪詢。
對于大規(guī)模的國際運營，一個可能從所有頒發(fā)者中取極大CRL的集中化安裝顯然是低效的。在挪威，每小時需要從全球數(shù)百個頒發(fā)者處取許多兆字節(jié)信息的安裝可以工作，但它將是低效的，并且撤銷信息的傳播將會很慢。因此，分布式體系結(jié)構(gòu)更適合CRL預(yù)取組件，但對它的進一步描述則超出本文的范圍。
可能最終有一些頒發(fā)者根本不使用CRL，但對于撤銷檢查只依靠OCSP接口。在這種情況下，CRL預(yù)取組件無計可施，以及確認(rèn)引擎必須在需要時調(diào)用適當(dāng)?shù)腛CSP接口(或者另一個確認(rèn)服務(wù)，如上所述)。
CRL預(yù)取組件所用的策略必須更詳細(xì)地調(diào)整，因為比上述參數(shù)更多的參數(shù)將影響這些結(jié)果。主要要求是對于撤銷信息的傳播容許引入的延遲量。它一定是CRL的頒發(fā)與該CRL已經(jīng)由CRL預(yù)取組件處理的時間之間的“間隙”。在這個間隙中到達確認(rèn)服務(wù)的請求必須接收延遲響應(yīng)-如果確認(rèn)服務(wù)等待CRL預(yù)取組件完成其工作-或者在確認(rèn)服務(wù)根據(jù)舊撤銷信息立即應(yīng)答時有錯誤回答的風(fēng)險。
還存在每次頒發(fā)計劃CRL時、頒發(fā)者的CRL分發(fā)服務(wù)因請求引起過載的風(fēng)險，因為許多方同時嘗試把新的CRL下載到本地高速緩存中。為了應(yīng)付這種情況，一些頒發(fā)者實現(xiàn)“過頒發(fā)”策略。CRL比策略所述更頻繁地被頒發(fā)。CRL預(yù)取組件必須考慮這類情況。
數(shù)據(jù)庫存儲關(guān)于各證書頒發(fā)者及其策略的信息以及撤銷信息。還可能存儲用戶相關(guān)的信息，但在所述系統(tǒng)上下文中最好是把用戶信息的存儲和管理留給授權(quán)服務(wù)來處理。
頒發(fā)者信息將包括頒發(fā)者名稱(在證書的“頒發(fā)者名稱”字段中指定)、所述策略的標(biāo)識(策略的OID(對象標(biāo)識符)(幾乎)總是包含在證書中)、必須用于確認(rèn)證書的公鑰或公鑰列表(具有有效性間隔和密鑰標(biāo)識符/散列值)、以及與策略和頒發(fā)者有關(guān)的質(zhì)量屬性，如前面所述。
頒發(fā)者公鑰的管理在當(dāng)今是麻煩的，因為這始終為信任證書頒發(fā)者及其密鑰的本地列表的形式，通常為自簽署證書的形式(它提供完整性保護，但沒有驗證)。在所述系統(tǒng)中，頒發(fā)者密鑰管理最好是集中于確認(rèn)服務(wù)中。如果完整證書被傳遞到確認(rèn)服務(wù)，以及頒發(fā)者對證書的簽名的本地檢查可在調(diào)用系統(tǒng)上被短路，這才是可行的。
頒發(fā)者密鑰在部分手動(用于質(zhì)量保證)以及部分自動的過程中被驗證，并存儲在數(shù)據(jù)庫中。頒發(fā)者密鑰的撤銷是極罕見的事件，但這也是極為嚴(yán)重的事件。信息信道必須被監(jiān)測，以便確保捕捉到這類撤銷。在某些情況下，撤銷將在分層結(jié)構(gòu)的高層從頒發(fā)者通過CRL進行。在其它情況下，所述證書頒發(fā)者不是任何可信結(jié)構(gòu)的成員，并且必須獨立安排撤銷。但是，撤銷通知始終在策略中進行描述。
部分頒發(fā)者始終只有一個密鑰對在使用，只是頒發(fā)者的密鑰滾動通常意味著重疊，其中，舊公鑰對于證書確認(rèn)仍然有效，而私鑰對于簽署新證書無效。其它頒發(fā)者可能對頻繁的密鑰變化采用一種策略，在這種情況下，許多密鑰可能同時有效(至少對于證書確認(rèn))?？赡苄枰謩舆^程使頒發(fā)者公鑰的數(shù)據(jù)庫保持更新。
撤銷信息的管理由CRL預(yù)取組件來進行。撤銷檢查通過數(shù)據(jù)庫搜索本地進行，以便檢查所述證書的序列號是否被列為已撤銷。撤銷信息必須加時標(biāo)當(dāng)前信息的取操作的時間，以及下一次取的計劃時間。
授權(quán)服務(wù)的主要動機是單一位置中的用戶相關(guān)信息的管理和保護。對于每個服務(wù)或者至少對于各服務(wù)平臺，具有單獨的驗證和授權(quán)系統(tǒng)是當(dāng)今的慣例。因此，預(yù)訂/用戶信息的管理-輸入新信息、變更或刪除信息-變得麻煩且易于出錯。
授權(quán)服務(wù)把有關(guān)各用戶的信息保存在一個數(shù)據(jù)庫中。服務(wù)和數(shù)據(jù)庫可以被復(fù)制?！坝脩簟蓖ǔ閭€人，但它也可以是訂戶身份、組名或其它某個指定實體。信息與驗證和授權(quán)相關(guān)。記帳信息可方便地添加到系統(tǒng)中，但在本文中沒有描述。該信息對保密性和完整性敏感，以及授權(quán)服務(wù)和數(shù)據(jù)庫必須得到充分保護。
目前，兩個標(biāo)準(zhǔn)協(xié)議應(yīng)該得到授權(quán)服務(wù)的支持LDAP和RADIUS。當(dāng)規(guī)范準(zhǔn)備就緒時，DIAMETER協(xié)議應(yīng)該被支持?？芍С制渌鼌f(xié)議。由于授權(quán)服務(wù)處理敏感信息，因此必須在信息被返回之前針對調(diào)用它的實體執(zhí)行驗證和訪問控制。這可以是所用協(xié)議的一部分，基于基礎(chǔ)協(xié)議(如SSL、TLS、IPSec或其它VPN技術(shù))，或者依靠到對方的專用通信信道(物理的或邏輯的)。由于使用不同的協(xié)議，因此需要協(xié)議特定的前端，其方式與對于確認(rèn)服務(wù)所述相同。
授權(quán)服務(wù)執(zhí)行驗證和服務(wù)訪問的名稱映射。所使用的基于PKI的驗證協(xié)議將驗證證書中的名稱。這個名稱可傳遞到授權(quán)服務(wù)，授權(quán)服務(wù)將返回相應(yīng)的用戶名。需要用戶名的服務(wù)的名稱應(yīng)該是調(diào)用的參數(shù)，因為用戶可能具有針對不同服務(wù)的不同用戶名。在需要以及被請求時，密碼可與用戶名一起被返回。
在會話的稍后階段，可調(diào)用授權(quán)服務(wù)，以便在需要時獲得更多用戶名?？上蚴跈?quán)服務(wù)傳遞用戶名/服務(wù)對，并要求它將此轉(zhuǎn)換成另一個用戶名/服務(wù)對，用于訪問另一個服務(wù)。授權(quán)服務(wù)必須記錄上次用于指定用戶的驗證機制的強度，并在通過返回或不返回信息來允許或拒絕對服務(wù)的訪問時相應(yīng)地動作。
系統(tǒng)中授權(quán)的第一層是這樣用于對服務(wù)的訪問。授權(quán)可鏈接到某些條件，例如足夠質(zhì)量的驗證機制的使用、所允許的位置、只使用某種設(shè)備、時刻等等。另一個條件是記帳和保證支付，它到這時一直是獨立服務(wù)，但可在以后被添加到授權(quán)服務(wù)中。所有這些條件必須被滿足，以便允許進行訪問。
另外，服務(wù)相關(guān)授權(quán)可存儲在數(shù)據(jù)庫中。在這種情況下，授權(quán)服務(wù)可在對特定對象(如某段內(nèi)容)的訪問嘗試時從服務(wù)本身被調(diào)用，從而決定是否應(yīng)該允許訪問請求。
對授權(quán)服務(wù)的其它擴展是-頒發(fā)密碼保護的“令牌”，作為授權(quán)的證明。這可基于簽署特權(quán)(屬性)證書、Kerberos憑單或類似的技術(shù)。
-處理授權(quán)從一個用戶/參與者到另一個的委派。
-從用于訪問決定的若干用戶/參與者組成授權(quán)。
-在本文中不再描述這些問題。
所述系統(tǒng)使驗證基于市場上可找到的(或非商業(yè)的)證書服務(wù)。所有證書管理、如登記、命名、頒發(fā)和撤銷將由證書服務(wù)提供商維護。
授權(quán)服務(wù)需要維護用戶名及相關(guān)特權(quán)的數(shù)據(jù)庫。
證書中的名稱在此上下文中不是直接可用的。因此，需要在用戶名與用戶希望用來驗證的證書中名稱之間建立映射。這可通過針對其它服務(wù)的更多用戶名、以及可能還通過密碼或其它驗證信息來進一步擴展，以便使訪問服務(wù)器能夠讓用戶透明地登錄到僅支持用戶名/密碼作為驗證機制的服務(wù)。除證書之外，該系統(tǒng)可擴展到適合其它驗證機制、如用戶名/密碼。
可能存在特定證書頒發(fā)者采用的命名格式可以被自動地轉(zhuǎn)換成用戶名的情況。但是，在大部分情況下，從證書名稱到用戶名的映射必須在數(shù)據(jù)庫中明確地配置。為了避免管理開銷，這對主要部分來講應(yīng)該作為用戶的自助接口來實現(xiàn)。但是，還需要具有對數(shù)據(jù)庫的擴展訪問權(quán)的運營者的管理接口和定義。
用戶必須有權(quán)訪問自助接口，其中他們可提交證書及其預(yù)訂的詳細(xì)情況，以便使證書名稱登記并鏈接到用戶名。兩個名稱形式之間的鏈接無疑必須以安全方式建立。一種可能性是，為新用戶提供兩種備選方案第一個是為帳戶簽約，同時從系統(tǒng)所有者的優(yōu)選伙伴處或者從備選證書頒發(fā)者的列表中預(yù)訂電子ID。根據(jù)證書頒發(fā)者的策略，電子ID可以是可立即使用的，或者可能需要在稍后階段被激活(例如，如果用戶需要獲取智能卡)。但是，對于授權(quán)服務(wù)，重要的信息是將出現(xiàn)在證書中的名稱。
第二個是為帳戶簽約，以及指定用于驗證用戶的現(xiàn)有證書。證書的適用性必須針對(安全性)要求來檢查，以及必須檢驗該證書的確屬于新用戶。它將足以登記一個證書，并且讓用戶稍后添加更多證書。
必須允許現(xiàn)有的用戶登記附加證書或者替換已經(jīng)登記的證書。這可以是作為基于萬維網(wǎng)的服務(wù)可用的自行管理過程。注意，需要與將登記的新方法(新證書)相關(guān)的可接受的驗證方法的規(guī)則。例如，不能首先引入低質(zhì)量證書，然后再用它來登記高質(zhì)量證書作為新驗證方法。在這種情況下，高質(zhì)量證書將有效地提供與根據(jù)低質(zhì)量證書的驗證相同的安全性，但給定配置對于低質(zhì)量方法可能限制訪問，而對于(在本例中好像)高質(zhì)量驗證允許訪問。因此，驗證方法僅可用來在相同或更低的安全性等級上引入新方法。
為了升級到更強的驗證方法，必須應(yīng)用沿著對于新用戶所遵循的線路的過程。某個自行管理是可行的，但可能剛好是在某種程度上必須涉及手動過程的情況。
必須允許管理員添加、刪除或改變其它用戶的信息?？稍谶\行授權(quán)服務(wù)的機構(gòu)內(nèi)部、相對可經(jīng)由該系統(tǒng)到達的服務(wù)(的提供商)或者相對例如需要管理若干用戶的預(yù)訂的公司客戶來定義管理員。管理員可使用與普通用戶同樣的接口或者在更適合的情況下采用另一種接口。批處理信息、例如在一個操作中添加關(guān)于許多用戶的信息的可能性是必要的。
在大部分情況下，讓預(yù)訂的管理(即對服務(wù)的授權(quán))留給各用戶處理，是節(jié)省成本的。因此，對于驗證信息的管理所述的自助服務(wù)還必須包括關(guān)于用戶的其它信息(實際上，這種使用對于驗證信息的管理可能是普遍的)。
授權(quán)的第一層將以這種方式提供服務(wù)-預(yù)訂服務(wù)或終止預(yù)訂。在更細(xì)分層，如果從各個服務(wù)委派到授權(quán)服務(wù)，則可管理與各個服務(wù)的特性有關(guān)的授權(quán)。一個實例可能是通信服務(wù)的預(yù)訂帶寬的變化。
當(dāng)用戶執(zhí)行這類管理過程時，必須服從授權(quán)和其它限制。例如，用戶無法預(yù)訂要求強驗證過程的服務(wù)，除非已經(jīng)為該用戶登記了足夠質(zhì)量的證書。另一個實例涉及服務(wù)中的內(nèi)容預(yù)訂，它可被限制到某個年齡以上的人員。
還需要管理員以便管理授權(quán)。例如，策略可規(guī)定，只有所定義的人員才可管理對公司用戶的某些服務(wù)的訪問權(quán)限。面向批處理的接口是必要的，以便在單一操作中管理關(guān)于許多用戶的信息。
權(quán)利要求
1.用于為用戶提供對來自服務(wù)提供商的至少一個服務(wù)的安全服務(wù)訪問的系統(tǒng)，其中所述用戶和所述服務(wù)提供商配備了用于連接到公共計算機網(wǎng)絡(luò)的裝置，所述系統(tǒng)包括-一個或多個確認(rèn)服務(wù)單元，設(shè)置成用于執(zhí)行以下步驟從訪問服務(wù)器接收用戶證書中的名稱，控制所述用戶證書的有效性，如果所述用戶的證書是有效的，則或者把所述用戶的證書名稱發(fā)送到授權(quán)服務(wù)單元以便轉(zhuǎn)換為用戶名，并且把從所述授權(quán)服務(wù)單元返回的所述用戶名傳遞到所述訪問服務(wù)器，或者把所述用戶的證書名稱傳遞到所述訪問服務(wù)器，如果所述用戶的證書不是有效的，則拒絕所述用戶對所述服務(wù)的訪問；-一個或多個授權(quán)服務(wù)單元，設(shè)置成用于執(zhí)行以下步驟從確認(rèn)服務(wù)單元或訪問服務(wù)器接收用戶的證書名稱，把所述用戶的證書名稱發(fā)送到數(shù)據(jù)庫，從所述數(shù)據(jù)庫接收用戶名和簡檔，把所述指定用戶身份碼傳遞到所述確認(rèn)服務(wù)單元或所述訪問服務(wù)器，從訪問服務(wù)器接收對訪問權(quán)限的查詢，從所述數(shù)據(jù)庫查詢預(yù)訂信息，從所述數(shù)據(jù)庫接收預(yù)訂信息，根據(jù)所述預(yù)訂信息確定訪問權(quán)限，把訪問權(quán)限傳遞到所述訪問服務(wù)器；以及-一個或多個授權(quán)功能單元和相連的數(shù)據(jù)庫，設(shè)置成用于執(zhí)行以下步驟從授權(quán)服務(wù)單元接收用戶的證書，在所述數(shù)據(jù)庫中定位所述用戶的名稱和簡檔，把用戶的名稱和簡檔發(fā)送到所述授權(quán)服務(wù)單元，從授權(quán)服務(wù)單元接收對預(yù)定信息的查詢，把預(yù)定信息發(fā)送到所述授權(quán)服務(wù)單元。
2.如權(quán)利要求1所述的系統(tǒng)，其特征在于還包括至少一個訪問服務(wù)器，設(shè)置成用于執(zhí)行以下步驟從所述用戶接收請求，對用戶進行驗證并要求客戶機授權(quán)，執(zhí)行競爭/響應(yīng)序列，向所述用戶請求證書和擁有私鑰的證明，把所述證書中的名稱傳遞到確認(rèn)服務(wù)單元，若是有效的用戶證書，則從授權(quán)服務(wù)單元接收指定用戶身份碼，就訪問權(quán)限查詢授權(quán)服務(wù)單元，從所述授權(quán)服務(wù)單元接收訪問權(quán)限，定位適當(dāng)?shù)姆?wù)菜單，向所述用戶提供所述服務(wù)菜單，以及在所述用戶與所述服務(wù)提供商之間傳遞信息。
3.如權(quán)利要求1或2所述的系統(tǒng)，其特征在于，所述訪問服務(wù)器包括用于以下步驟的裝置支持HTTPS，或者用于保護通信信道安全的其它裝置，向客戶機/用戶驗證所述訪問服務(wù)器，最好通過使用PKI技術(shù)來進行，支持與所述確認(rèn)服務(wù)和所述授權(quán)服務(wù)單元進行通信所需的協(xié)議，支持用于基于PKI的客戶機/用戶驗證的一個或多個協(xié)議，實現(xiàn)向所述用戶顯示信息以及處理用戶輸入所需的功能性，用作所述用戶與服務(wù)之間的代理服務(wù)器。
4.如權(quán)利要求1或2所述的系統(tǒng)，其特征在于，向所述用戶請求證書和私鑰可通過利用目錄查找來執(zhí)行。
5.如權(quán)利要求1或2所述的系統(tǒng)，其特征在于，所述訪問服務(wù)器適合以單一簽名方式傳遞對所述服務(wù)的直接訪問。
6.如權(quán)利要求1或2所述的系統(tǒng)，其特征在于，存儲所述用戶名和簡檔的所述數(shù)據(jù)庫還存儲其它用戶相關(guān)信息。
7.如權(quán)利要求3所述的系統(tǒng)，其特征在于，所述訪問服務(wù)器在使用保護所述通信信道安全的其它裝置時，建立僅與所述服務(wù)器驗證的SLL/TLS會話，以及在所述建立的安全信道上運行所述用戶驗證協(xié)議。
8.如權(quán)利要求3所述的系統(tǒng)，其特征在于，若驗證方法有若干備選者，則為所述用戶提供選擇，以及所述訪問服務(wù)器建立與所選的客戶機驗證方法的SSL/TLS會話。
9.如權(quán)利要求5所述的系統(tǒng)，其特征在于，所述服務(wù)提供商包含在所述系統(tǒng)中，以及適合訪問信息并與所述授權(quán)服務(wù)單元交換信息。
10.如權(quán)利要求1-9其中之一所述的系統(tǒng)，其特征在于，所述確認(rèn)服務(wù)單元、所述授權(quán)服務(wù)單元以及所述授權(quán)功能單元是計算機實現(xiàn)的。
11.如權(quán)利要求1或2所述的系統(tǒng)的用途，用于提供對增值服務(wù)、如視頻點播的驗證、授權(quán)和訪問。
12.如權(quán)利要求10所述的用途，其特征在于，所述信息通過加密來保護。
13.用于為用戶提供對來自服務(wù)提供商的至少一個服務(wù)的安全服務(wù)訪問的方法，其中所述客戶和所述服務(wù)提供商配備了用于連接到公共計算機網(wǎng)絡(luò)的裝置，所述方法包括以下步驟借助于一個或多個確認(rèn)服務(wù)單元；從訪問服務(wù)器接收用戶證書中的名稱，控制所述用戶證書的有效性，如果用戶的證書是有效的，則或者把所述用戶的證書名稱發(fā)送到授權(quán)服務(wù)單元以便轉(zhuǎn)換為用戶名，并且把從所述授權(quán)服務(wù)單元返回的所述用戶名傳遞到所述訪問服務(wù)器，或者把所述用戶的證書名稱傳遞到所述訪問服務(wù)器，以及如果所述用戶的證書不是有效的，則拒絕所述用戶對所述服務(wù)的訪問；-借助于一個或多個授權(quán)服務(wù)單元從確認(rèn)服務(wù)單元或訪問服務(wù)器接收用戶的證書名稱，把所述用戶的證書名稱發(fā)送到數(shù)據(jù)庫，從所述數(shù)據(jù)庫接收用戶名和簡檔，把所述指定用戶身份碼傳遞到所述確認(rèn)服務(wù)單元或所述訪問服務(wù)器，從訪問服務(wù)器接收對訪問權(quán)限的查詢，從所述數(shù)據(jù)庫查詢預(yù)訂信息，從所述數(shù)據(jù)庫接收預(yù)訂信息，根據(jù)所述預(yù)訂信息確定訪問權(quán)限，以及把訪問權(quán)限傳遞到所述訪問服務(wù)器；以及-借助于一個或多個授權(quán)功能單元及相連的數(shù)據(jù)庫從授權(quán)服務(wù)單元接收用戶的證書，在所述數(shù)據(jù)庫中定位所述用戶的名稱和簡檔，把用戶的名稱和簡檔發(fā)送到所述授權(quán)服務(wù)單元，從授權(quán)服務(wù)單元接收對預(yù)定信息的查詢，把預(yù)定信息發(fā)送到所述授權(quán)服務(wù)單元。
14.如權(quán)利要求13所述的方法，其特征在于還包括由至少一個訪問服務(wù)器執(zhí)行的以下步驟從所述用戶接收請求，對用戶進行驗證以及要求客戶機授權(quán)，執(zhí)行競爭/響應(yīng)序列，向所述用戶請求證書和擁有私鑰的證明，把所述證書中的名稱傳遞到確認(rèn)服務(wù)單元，若是有效的用戶證書，則從授權(quán)服務(wù)單元接收指定用戶身份碼，就訪問權(quán)限查詢授權(quán)服務(wù)單元，從所述授權(quán)服務(wù)單元接收訪問權(quán)限，定位適當(dāng)?shù)姆?wù)菜單，向所述用戶提供所述服務(wù)菜單，以及在所述用戶與所述服務(wù)提供商之間傳遞信息。
全文摘要
一般來講，本發(fā)明涉及驗證、授權(quán)和訪問控制，更具體來講，涉及允許用戶只有一個電子ID用于對所有服務(wù)的安全訪問、一般基于公鑰基礎(chǔ)結(jié)構(gòu)的驗證的方法和系統(tǒng)。所述系統(tǒng)通過提供一般基于PKI的驗證改進現(xiàn)有技術(shù)水平。通過向其它服務(wù)提供商提供確認(rèn)、可能還有授權(quán)服務(wù)，系統(tǒng)可提供用于一般基于PKI的驗證的基礎(chǔ)設(shè)施，處理來自基本上任何這類頒發(fā)者的電子ID。
文檔編號G06F21/41GK1745356SQ03810810
公開日2006年3月8日 申請日期2003年3月18日 優(yōu)先權(quán)日2002年3月18日
發(fā)明者J·羅塞博, J·奧爾內(nèi)斯 申請人:特倫諾有限公司