。
[0036]這樣，通過在網(wǎng)絡層設置反向代理服務器，來對網(wǎng)絡層上的所有應用服務進行靈活的訪問權限控制管理，不需要高配置的服務器，并可以采用免費的開源軟件，具有成本低、高可用性、維護方便等優(yōu)點。
[0037]在一種可能的實現(xiàn)方式中，根據(jù)本實施例的訪問權限控制方法在步驟SllO之前，還可以包括:預先設置用戶的用戶標識與用戶所歸屬的用戶組之間的第一對應關系，其中，一個用戶可以與至少一個用戶組相對應。在這種實現(xiàn)方式中，步驟S120具體可以為，根據(jù)預設的第一對應關系將與用戶標識相對應的用戶組確定為用戶所在的用戶組。
[0038]在一種可能的實現(xiàn)方式中，根據(jù)本實施例的訪問權限控制方法在步驟SllO之前，還可以包括:預先設置所述資源與其所歸屬的資源組之間的第二對應關系，其中，一個資源可以與一個資源組相對應。在這種實現(xiàn)方式中，步驟S140具體可以為，根據(jù)預設的第二對應關系將與所述資源相對應的資源組確定為所述待訪問資源組。
[0039]在一種可能的實現(xiàn)方式中，根據(jù)本實施例的訪問權限控制方法在步驟SllO之前，還可以包括:預先設置用戶組與其能夠訪問的資源組之間的第三對應關系，其中，一個用戶組與至少一個資源組相對應。在這種實現(xiàn)方式中，步驟S130具體可以為，根據(jù)預設第三對應關系將與所述用戶組相對應的資源組確定為所述可訪問資源組。
[0040]需要說明的是，盡管以步驟SllO之后依次執(zhí)行步驟S120、S130和S140作為示例介紹了本發(fā)明的訪問權限控制方法如上，但本領域技術人員能夠理解，本發(fā)明應不限于此。事實上，用戶完全可根據(jù)個人喜好和/或?qū)嶋H應用場景靈活設定步驟S120至步驟S140的執(zhí)行順序，另外，這三個步驟的執(zhí)行順序也可以不分先后，可以并行執(zhí)行。
[0041]這樣，通過預先設置用戶與其所屬用戶組之間的對應關系，資源與其所屬資源組之間的對應關系，用戶組與可訪問資源組之間的對應關系，根據(jù)本發(fā)明上述實施例的訪問權限控制方法能夠?qū)τ脩舻馁Y源訪問請求做出快速、正確的響應。
[0042]實施例2
[OO43 ]根據(jù)本實施例的訪問權限控制方法基于角色訪問控制(英文:Ro I e -Bas e d Ac c e s sControl，縮寫:RBAC)和Nginx(enginex)反向代理服務配置策略來實現(xiàn)對網(wǎng)絡資源訪問的權限控制。下面對角色訪問控制和Nginx反向代理服務進行詳細說明。
[0044]訪問控制是指按照預先設置的權限規(guī)則，系統(tǒng)的使用者能且只能對自己權限范圍內(nèi)的資源進行權限內(nèi)的操作。傳統(tǒng)的權限控制管理中資源的權限有一個全局的管理員進行分配，通過將系統(tǒng)中的資源分密級和類進行管理，以保證每個用戶只能訪問到那些被標明可以由他訪問的資源。這種方式統(tǒng)籌管理系統(tǒng)資源的分配，但是當系統(tǒng)用戶和資源量都非常多時，管理將會變得非常復雜而且難以維護。
[0045]而本實施例則基于角色訪問控制來配置權限，即將資源以及資源的操作構(gòu)成的權限授予給角色，將組織機構(gòu)或具體人員用戶分配給角色對象完成資源權限的授權過程。角色對象和資源操作權限所授予的對象做一對多的關聯(lián)，滿足了資源訪問權限授予給多種角色對象的需求。
[0046]為了達到用戶與資源的有效授權匹配，本申請發(fā)明人設計采取用戶組與資源組的概念進行管理。圖2示出了根據(jù)本實施例所采用的角色訪問控制模型。如圖2所示，用戶組是對網(wǎng)站用戶的一個分類，例如可以根據(jù)用戶密級和職位來劃分用戶組，其中，一個用戶可以包括在多個用戶組中，例如圖2所示地，用戶I包括在用戶組A和用戶組C中。資源組是對網(wǎng)絡系統(tǒng)資源進行的分類，同時定義對資源訪問操作的權限，其中，資源與資源組是一對一的關系，即一個資源只包括在一個資源組中。另外，還將用戶組與資源組進行綁定，其中，用戶組與資源組設定為一對多關系，即一個用戶組可以訪問多個資源組中的資源，例如圖2所示地，用戶組B可以訪問資源組A和資源組B中的資源。某一用戶組下的用戶對其所在用戶組綁定的資源組下的資源按照綁定資源組分配的權限進行訪問操作。
[0047]Nginx反向代理服務即在網(wǎng)絡站群系統(tǒng)中，站群中的站點在展示上可能是上下級關系，但在開發(fā)時各站點是相互獨立的、又是相互聯(lián)系且共享的，部署也是平級的。就使得站群系統(tǒng)的站點管理既具有分開部署的特點，也具有集成部署的要求。利用Nginx實現(xiàn)的站點管理就可以實現(xiàn)各站點之間彼此獨立，還能有機整合成一個資源共享、信息互動以及責任分明的站群平臺。Nginx作為反向代理服務器時，一臺Nginx在前端作為反向代理服務器，后端放置多臺Web服務器。Nginx作為用戶的訪問入口，當客戶端向Nginx反向代理服務器發(fā)送資源訪問請求時，Nginx利用它的Handles處理模塊為其服務，服務器根據(jù)配置好的訪問控制策略進行權限判斷，符合權限的請求向后端Web服務器轉(zhuǎn)交。后端Web服務器接收到請求后，將請求內(nèi)容返回給反向代理服務器，最后返回給客戶端實現(xiàn)訪問。不符合權限的請求由Nginx代理跳轉(zhuǎn)至警告頁面。
[0048]圖3示出根據(jù)本發(fā)明另一實施例的訪問權限控制方法的流程示意圖。根據(jù)本實施例的權限訪問控制的過程如下:
[0049]a.系統(tǒng)根據(jù)登錄用戶獲取其所在用戶組信息；
[0050]b.根據(jù)當前用戶組獲取該用戶組綁定的資源組信息；
[0051 ] c.用戶在系統(tǒng)內(nèi)對某一條資源進行訪問時，獲取到該條資源對應的資源組信息；
[0052]d.將當前獲取的資源組的信息與權限配置表中的資源組操作權限進行比對判斷是否有操作權限；
[0053]e.經(jīng)判斷權限為“是”，則用戶正常訪問；權限為“否”，則系統(tǒng)跳轉(zhuǎn)至警告頁。
[0054]在一種可能的實現(xiàn)方式中，使用Nginx做反向代理的網(wǎng)絡架構(gòu)可以如圖4所示。使用Nginx做反向代理處理，將Nginx部署在防火墻?；饏^(qū)外，網(wǎng)站部署在防火墻?；饏^(qū)內(nèi)，互聯(lián)網(wǎng)用戶通過Nginx代理來訪問門戶網(wǎng)站，確保了內(nèi)部IP和信息全部經(jīng)過代理以后才能出去。將所有基于網(wǎng)絡的應用服務訪問URL作為資源，在Nginx配置文件中建立資源訪問請求的處理策略，配合基于角色訪問控制模型中的權限關系，對訪問請求做出正確的響應。將在下面的實施例中詳述本發(fā)明的用于控制用戶訪問應用服務器中資源的權限的。
[0055]實施例3
[0056]圖5示出了根據(jù)本發(fā)明一實施例的反向代理服務器的框圖示意圖。根據(jù)本實施例的反向代理服務器300設置在網(wǎng)絡層，可以經(jīng)由因特網(wǎng)200與用戶終端100連接，并與向用戶終端100提供應用資源的應用服務器集群400，被配置為控制用戶訪問應用服務器集群400中的資源的權限。
[0057]根據(jù)本實施例的反向代理服務器300可以包括:接收模塊310、第一確定模塊320、第二確定模塊330、第三確定模塊340和判斷模塊350。
[0058]具體地，接收模塊310可以被配置為接收用戶發(fā)出的資源訪問請求，其中，資源訪問請求可以包括用戶要訪問的資源信息和用戶的用戶標識;第一確定模塊320與接收模塊310連接，可以被配置為根據(jù)用戶標識確定用戶所歸屬的用戶組;第二確定模塊330與接收模塊310和第一確定模塊320連接，可以被配置為確定用戶組能夠訪問的至少一個可訪問資源組;第三確定模塊340與接收模塊310和第一確定模塊320連接，可以被配置為根據(jù)資源信息，確定用戶要訪問的資源所歸屬的待訪問資源組;判斷模塊350與第二確定模塊330和第三確定模塊340連接，被配置為判斷各所述可訪問資源組是否包括所述待訪問資源組，并在各所述可訪問資源組包括所述待訪問資源組的情況下，判斷為所述用戶具有訪問所述資源的權限。
[0059]在一種可能的實現(xiàn)方式中，在各所述可訪問資源組不包括所述待訪問資源組的情況下，判斷模塊350判斷為用戶不具有訪問所述資源的權限。接收模塊310、第一確定模塊320、第二確定模塊330、第三確定模塊340和判斷模塊350的具體實現(xiàn)可以參考實施例1中對步驟SI 10至步驟S160的描述。
[0060]在一種可能的實現(xiàn)方式中，如圖5所示，根據(jù)本實施例的反向代理服務器300還可以包括:第一預設模塊360。其中，第一預設模塊360與第一確定模塊320連接，可以