基于動態角色服務權限控制的物聯網平臺設計

查 瑤，陳 朋

(1.浙江工業大學 信息工程學院，杭州 310023； 2.浙江工業大學 計算機科學與技術學院，杭州 310023)

0 引言

物聯網平臺作為數據驅動業務解決方案在各個領域變得非常流行[1]。平臺是物聯網生態系統的主要部分之一，可實現物聯網設備和端點管理，數據采集和分析。

隨著互聯網技術的飛速發展，簡單的Web服務不足以滿足實際應用需求。技術產品和系統變得越來越復雜，系統之間的資源共享與業務協同的問題也迫切需要解決[2]。以傳統的面向對象方式構建的物聯網平臺，在后期管理的升級和更改中變得越來越困難。并且在設備管理過程中，用戶角色各異，容易引起角色自我定位模糊，無法確切地獲取相應的權限和信息[3]。傳統的物聯網平臺訪問控制的模型應用于完整的Web服務，其中包含許多操作，每個操作都提供某些特殊功能。如果要為用戶提供較少的選定操作的訪問權限，則需要提供與這些操作相對應的單獨的Web服務[4]。

為了解決未知角色的復雜權限定義和平臺后期的擴展性問題，通常使用基于角色的訪問控制方法，因為它為組而不是單個用戶提供訪問控制，并且易于擴展，用戶根據他們在網絡中獲取的角色訪問資源[5]。目前國內、外對角色的訪問控制方法研究主要有對平臺功能模塊化研究和動態角色權限研究。在對平臺的功能模塊化研究上，Magnusson等人[6]將模塊化和產品平臺策略視為實現共性的獨特概念機會。在給定的背景下評估這些概念的適用性。Shamsuzzoha和Helo[7]通過闡述設計指南的基本原理提出了一個概念模型，并且在將各種組件與產品平臺連接以開發具有成本效益的產品變體之前可以實施清單。Halstenberg等人[8]開發了目標導向的模塊化方法，用于相對于所追求的目標定義模塊化產品架構概念。在針對公司的特定情況定制體系結構計劃時，沒有萬能的。特定環境需求下的模塊化產品設計非常重要[9]。

在對動態角色權限研究上，文獻[10]提出了一種訪問控制方法。他們擴展了XACML-RBAC配置文件，將管理員作為角色之一，執行諸如創建/刪除角色，更改角色權限和用戶分配角色等操作。Zhu等人[11]提出了一種訪問基本服務的模型，該模型屬于復合Web服務的其他安全域。在此模型中，基本Web服務的策略文件被組合，并且提供者分析這些文件以構造復合服務的訪問控制策略。此方法不允許自動組合基本Web服務的訪問控制策略文件。李蔚等人[12]提出一個擴展模型，在RBAC模型[13]的基礎上，將權限細化，添加對象、操作、域和分組等4個元素，同時提出域的可繼承性和一種表示域之間的層級關系的方法，該方法可以管理角色下的數據內容和操作，將更細粒度化權限功能。當前基于角色的訪問控制方法或模型[14]都強調要考慮整個Web服務或復合服務中的Web服務分支。如果需要訪問Web服務的某些選定操作，或通過向用戶提供適當的服務訪問特權并向用戶動態授予特權，則不能使用這些方法，同時部分系統操作復雜，難以商業化。

綜上所述，本文針對傳統的用戶權限定義和平臺的擴展性的缺點，擬利用layui框架對物聯網平臺進行研究，提出一種基于動態角色服務權限控制物聯網平臺的擬議系統，解決了未知角色在Web服務中權限管理問題。在物聯網平臺上實現該方法。首先在系統架構上，根據訪問Web服務的用戶的目的和需求，提供基于角色的動態用戶服務，然后在應用訪問控制精確到操作級別上細粒度化，進一步細化訪問控制粒度[15]。最后嵌入到平臺采用的模塊化設計中。

1 平臺總體設計

本文提出的基于動態角色服務權限控制的物聯網平臺設計如圖1所示。

圖1 物聯網平臺設計圖

該平臺設計由功能模塊設計、平臺系統流程圖、RBAC模型和數據庫設計共4部分組成。

第一部分：由于用戶在使用物聯網平臺的整個過程中，每個用戶都帶有不同屬性，衍生出不同的未知角色，對設備整個生命周期中，角色的權限需求進行分析，根據系統需求，將物聯網平臺劃分為6個模塊；第二部分：以角色為中心，建立流程圖，使不同的模塊相串聯；第三部分：根據RBAC的基本模型，建立物聯網平臺的角色模型；第四部分：根據角色的不同權限和功能，對數據庫建表，然后針對部分功能提供更細粒度的訪問控制。

2 功能模塊設計

對于為提供可選服務的用戶定制的各種類型的軟件融合服務的需求不斷增長，設備在使用的過程中，使用者擔當的角色類型各異，每個角色對于權限規劃也不明確。在該環境下，可以根據用戶的目的和需求組合使用服務，建立以角色為中心的一個模型，通過向用戶提供適當的服務訪問特權并向用戶動態授予特權。

根據市場需求，基于動態角色服務權限控制的物聯網平臺包括6個主要功能模塊：數據查詢、權限更新記錄、設備管理、運營管理、用戶管理、角色管理，如圖2所示。其中用戶管理和角色管理模塊屬于動態角色權限的設計，而數據查詢、報警查詢、設備管理、運營管理模塊則是圍繞于角色設計功能性模塊，整個設計反映了RBAC模型中訪問控制的核心思想。

圖2 系統功能框架圖

3 系統流程

3.1 現有系統

在現有物聯網平臺的系統中，整體流程一般是基于身份訪問展開的[16-17]。系統的流程如圖3所示。訪問系統的主體是用戶，用戶類型各異。一旦用戶發送了請求會話，就開始判別用戶類型，檢查與該用戶相關聯的權限集，然后分配給不同等級用戶類別下固定的權限。

圖3 基于身份訪問系統流程圖

現有系統沒有基于用戶的環境條件對權限集細分，使得同一級別下，不同類型的用戶只擁有固有的權限使用權。不足以涵蓋用戶的使用范圍，安全性也無法得到保障。

3.2 擬議系統

在提出的系統中克服了現有物聯網平臺系統的局限性，需要將角色用作中心，以使用戶成為獲得特定權限的角色。擬議物聯網平臺的系統的整體流程如圖4所示。

圖4 基于動態角色訪問系統流程圖

在所提出的系統中，當用戶發送請求時，其會話開始，驗證用戶信息。當約束條件判別為用戶，則擁有系統基本所有的權限，等同于現有系統的一級用戶。以角色代替二級用戶，當不同角色發送請求會話且角色已激活，檢查與角色相關的權限集，權限包含對象表達式，就會對每個對象進行一對一評估。如果對象表達式及其對應條件對某個對象的評估為true，授予角色訪問對象表達式及其相應條件返回true的所有那些對象的權限，完成一個對不同角色權限的過濾與授予。

4 擴展RBAC動態角色控制模型

RBAC的主要思想是對系統操作的各種權限不直接授予具體用戶，而在用戶集合與權限集合之間建立一個角色集合。當角色被創建后，角色再授予訪問權限。也就引入了一種抽象的中介元素 — 角色傳遞授權信息[18]。相應地，權限可以分配給多個角色。每個操作可以應用于多個客體，每個客體可以接受多個操作。

本文擴展模型如圖5所示，以RBAC模型為基礎進行說明，對此擴展模型涉及的部分概念進行定義：

用戶(U)：RBAC模型中的用戶定義為與系統有特定目的交互的人。每個用戶都與一個角色相關聯，并且只有獲得角色，該用戶才能訪問系統中的任何資源。

角色(R)：角色在系統中擔當用戶與權限之間的橋梁，角色既可以看作是多個權限的集合，也可以看作是具有相同身份的用戶的集合。

權限(P)：P=OP(操作集)×OBJ(客體集)，權限是控制對系統資源的訪問的權限。權限定義了RBAC模型中的用戶可以與系統資源進行交互的類型，客體集在本文中為可供操作的模塊資源。

會話(S)：用戶需要先建立會話，在該會話中將每個用戶賦予該會話所需要的角色及相關權限。

用戶與角色：概念與通常的角色、用戶定義無區別。但角色類型可以人為的劃分等級，主要分為兩種類型：角色A、角色B。角色A可以成為一些角色并具有相應的權限，角色B可以在權限上進一步細分等級，角色B可以在自己所擁有的權限下創建角色，繼承相應的權限，因此用戶可以具有多個不同的角色身份。

角色與權限：角色與權限之間的關系是多對多的[19]，一個角色可以擁有多種權限，多個角色可以對應同一個權限，但用戶只能用一種角色進入系統，當對某個角色的定義隨著需求的變更發生改變時，用戶可以實時動態地改變角色的權限，重新定義角色。

圖5 擴展RBAC模型

物聯網平臺在采用擴展RBAC模型為基礎上，增加設備的概念融入關系圖，如圖6所示。同時，一臺設備只可以分配給一個客戶，但可由多個管理類型的角色同時管理。由于當用戶訪問對象時，系統需要根據用戶權限進行檢查和攔截，用戶只可以對自己權限范圍下的所擁有的功能和設備進行操作。角色A為圖6中的客戶組，角色B為圖6中的其他角色組。

圖6 基于RBAC物聯網平臺分層訪問控制模型

5 數據庫設計

根據RBAC模型，數據庫的邏輯結構設計如圖7所示。分為RBAC用戶表，RBAC角色表，RBAC設備表，RBAC資源表，RBAC操作表，RBAC用戶角色分配表，RBAC角色權限表，RBAC權限操作表，RBAC設備用戶表，RBAC設備角色表。

圖7 數據庫設計圖

在整個數據庫模型中，操作和資源通過權限操作表連接。通過角色權限表將權限分配給角色，并通過用戶角色表將角色分配給用戶。同時設備分別通過用戶設備表和角色設備表，交由用戶管理以及用戶分配給角色管理。從而實現了基于動態角色服務權限控制模型。

在操作級別的細粒度級別上，對數據庫的權限操作表進行了細分。根據授權，允許或拒絕授權使用者訪問Web服務的操作。主要體現為對界面的按鈕做顯示設置，區別用戶的操作范圍。

6 實施與測試

6.1 實驗設計

部署在應用程序服務器中的測試應用程序調用Web服務的操作。然后，根據訪問控制策略中定義的角色和相應的權限，允許用戶訪問通過Web服務中的操作實現的所需功能。

本文選用智能數據采集系統作為測試用例。平臺客戶端的運行時環境是Windows 10和帶有V8 JavaScript引擎的Google Chrome Web瀏覽器，服務器端是基于Java的HTTP服務器。

在測試方案中，為用戶定義3個角色，Admin、公司、自定義角色，如表1所示。

表1 測試方案中的角色描述

在RBAC中，權限被分配給角色以授予其對各種資源的訪問權限。如表2所示，列出了物聯網平臺的部分示例權限，包括權限ID和權限的功能描述。

表2 示例權限列表

表2中給出的示例權限已分配給測試方案中不同層次結構的3個角色。{P1, P2, P4, P5, P6}為主模塊權限，P7，P8屬于權限{P4}的子模塊，P9屬于權限{P5}的子模塊，P10屬于權限{P4, P5}的每個子模塊下的部分功能，P11屬于權限{P1}的部分功能權限。R1具有全部權限。R2具有許可{P1, P2, P4, P5, P6}。R3具有許可為空集，可以由權限擁有者從集合中添加至空集。

實驗的流程如下：首先，以admin身份登錄，使用P3權限，完成對公司的創建。再利用P4權限下P7分配設備給公司；然后公司身份登錄，通過權限P6創建自定義角色，分為管理類型角色B和二級用戶角色A。再利用權限P7將設備分配給多個自定義角色B管理，以及該公司下的角色A使用；角色B身份登錄，可以在權限允許下使用{P1, P2, P4, P5, P6}，子模塊功能{P7, P8, P9}，操作權限{P10}。角色A身份登錄，只擁有權限{P1, P2}。

6.2 測試結果及對比分析

本實驗從R1、R2、R3中隨機地選取7個實例作為測試集，角色類型1、角色類型2分別屬于R1和R2，R3中又細分了5種典型角色，比較能全面的代表使用者的不同身份。角色類型3為公司管理型角色，角色類型4為公司客戶角色，角色類型5則代表了在使用過程中，遇到未知的角色形象，可開放性分配權限功能。讓每個用戶按照三種情況進行查詢操作，分別對應查詢所有有權訪問的數據，可讀取到的權限結果反饋如表3所示。

表3 權限測試結果

為了驗證擬議系統在細粒度權限管理設計優勢和角色權限動態化的靈活性，將現有系統和擬議系統進行了比較。如表4、表5所示。

表4 角色權限動態性比較結果

如表4所述，不同類型的R3級用戶在現有系統和擬議系統中對權限的動態可操作性，擬議系統可以人為地對R3級用戶權限實施動態進行調整，增加了角色的多樣性。

表5 角色權限細粒度比較結果

如表5所述，擬議系統在客戶組中可以通自定義角色對客戶設定自定義客戶類型，增加頁面局部操作權限{P10}，符合本文定義的細粒度權限管理要求。

7 結束語

針對現有基于身份的訪問控制系統無法滿足用戶定制的各種軟件組合服務的需求，提出了一種基于動態角色服務權限控制的物聯網平臺。

相比傳統的角色的權限定義，角色動態自定義法可以根據各種用戶的需求，對角色的權限動態化管理，為每個用戶提供適當的服務以提供定制的基于Web的軟件。首先，在物聯網平臺設計中，本文提出將平臺功能模塊化，獲得多個不同功能模塊。然后，經過對現有系統流程中引入角色化概念，結合自定義權限的設定，得到了擬議系統流程圖。使用RBAC模型為基礎，設計動態權限控制模型并用數據庫實現。最后，選取一組完整且具有代表性的數據作為擬議系統的測試集，分析已被授予角色的用戶的訪問權限；選取一組現有系統二級用戶數據作為對比集，與測試集在權限細粒度、角色動態性方面展開分析。由實驗可以得出：基于動態角色服務權限控制的擬議系統，在角色動態定義和設置有很大的靈活性，滿足用戶定制的各種軟件組合服務的需求，并支持后期的模塊動態擴展。在權限細粒度中，可以根據訪問請求者獲得權限的條件，將訪問的范圍精確到模塊界面的操作級別。

本文提出的基于動態角色服務權限控制的物聯網平臺，通過授予用戶動態角色特權來管理系統，由分析表明動態權限控制模型有效地為平臺提供了細粒度、簡單實用的動態訪問控制，在實際工程應用中具有重要的指導意義。