指派與授權

在本研究中，將針對此智慧型實驗室設計一套方針，讓每位使用者的權限皆 受到這一套方針的限制，在本架構中，權限並非一一分配給使用者，而是指派給 角色，如此可以減少許多管理上的麻煩，並且在組織或人事變動的時候，也能更 方便的更改存取控制規則，除了將權限分配給角色，本架構還將會參考使用者以 及周遭實體的情境，用來協助此模型的授權控管系統，作為系統指派角色予使用

33

者以及授權角色對相關物件的存取權限時的判斷依據，讓系統能夠更貼近現實的 情況做出指派與授權。

本研究所訂定的方針主要包含了使用者與角色之間的指派，是依據使用者以 及周遭實體的情境來做指派的動作；以及角色與物件之間的授權關係，是根據當 時週遭環境的情境以及物件的情境，將對物件的權限授權給角色。另外還有關於 情境衝突的設定，以下將逐一敘述：

方針定義 1. uUSERS, cCONTEXTS, rROLES

   rRole（u） and cRContext（r） => URAC（u, r）

在方針定義 1 裡，u 為使用者；c 為情境組合，可能為一個到多個的情境組 合而成；r 則為此環境下的角色集合內的一個角色；Role（u）為使用者 u 可擔任 的角色集合；RContext（r）為擔任角色 r 所需要的情境；URAC（u, r）為指派角 色 r 給使用者 u。

方針定義 1 是說明當角色 r 屬於使用者 u 可擔任的角色集合中的一個，並且 當時的使用者情境以及環境情境滿足欲擔任此角色 r 所需要的情境組合 c 時，則 可以指派此角色 r 給此使用者 u。

而情境組合在具情境感知的授權控管系統上可能為各種不同的組合，系統可 以依照各種不同的角色，設定不同的情境組合作為取得這些角色的條件，讓系統 可以依這些情境不同的組合，而授予使用者不同的角色。

在此舉一個簡單的例子來對此方針作更詳細的描述，假設方針庫中包含了下 述兩個方針：

方針 1：（m222_LabMember）  Role（Alex） and （location: m222, time: 0000, 2400）  RContext（m222_LabMember） → URAC （Alex, m222_LabMember）

方針 2：（MIS_ Assistant）  Role（Alex） and （location: m222, time: 0800, 1800）

 RContext（MIS_ Assistant） → URAC （Alex, MIS_ Assistant）

34

由上述之方針 1 與方針 2，可以得知使用者 Alex 可以擔任的角色有 m222 實 驗室成員（m222_LabMember）與 MIS 助教（MIS_Assistant）。此外，由方針 1 可得知欲擔任 m222 實驗室成員（m222_LabMember）這個角色的情境限制為「位 置在 m222（location: m222）、時間為 00 時 00 分至 24 時 00 分（time: 0000, 2400）」； 由方針 2 可得知欲擔任 MIS 助教（MIS_ Assistant）這個角色的情境限制為「位 置在 m222（location: m222）、時間為 08 時 00 分至 18 時 00 分（time: 0800, 1800）」。

當 Alex 這位使用者持行動裝置進入 m222 時，系統已經透過無線網路與此 行動裝置取得聯繫，並且取得此行動裝置的持有人資訊，得知該行動裝置的登記 人為 Alex，由方針庫中可以得知 Alex 可以擔任的角色有 m222 實驗室成員以及 MIS 助教，此外由感測器取得使用者 Alex 正在 m222 這個位置，時間為上午 7 點，情境資訊符合 m222_LabMember 這個角色所需要的情境，而不符合 MIS 助 教這個角色的情境，因此即分配 m222_LabMember 這個角色給 Alex，使得 Alex 擁有此角色。

如果此時 Alex 進入另外一個地點，如 m223 實驗室，則因為 Alex 不具備可 擔任 m223_LabMember 這個角色，則系統會根據方針庫裡的其他方針規則來重 新分派角色給 Alex，如訪客（guest）或是其他實驗室的成員（lab member），而 此角色在 m223 可能無法使用在此實驗室裡大部分的物件。

方針定義 2. rROLES, c_i, c_jCONTEXTS, objOBJECTS,

pPERMISSIONS

r  OPRole（obj） and ci OPContext（obj, p） and c_j OContext（obj）→ ROP（r, obj, p）

在方針定義 2 裡，r 為此環境下的角色集合內的一個角色；c_i，c_j為情境集 合；obj 為此環境下的某個物件；p 為對物件可操作的權限；OPRole（obj）為對

35

obj 此物件可操作的角色集合；OPContext（obj, p）為對 obj 此物件進行操作權限 p 時所需要的情境；OContext（obj）為物件 obj 當時的情境；ROP（r, obj, p）為 角色 r 對物件 obj 有著 p 的權限。

方針定義 2 即是說明角色 r 為對 obj 此物件有操作權限的角色，權限 p 為對 obj 此物件可操作的權限，且當時的情境組合 c_i為對此物件 obj 進行操作 p 時所 需要的情境，並且當時物件 obj 的情境組合為 c_j，則此角色 r 對物件 obj 有著 p 的權限。

在此我們舉個例子來說明，假設 m222 有一台公用印表機（m222Printer），

可供給所有 m222 的實驗室成員（m222_LabMember）使用，但是僅限於時間為 上午 8 點至下午 6 點，則方針為：

m222_LabMember  OPRole（m222Printer） and （location: m222, time: 0800, 1800 ）  OPContext （ m222Printer, print ） and （ standby ） OContext

（m222Printer） → ROP（m222_LabMember, m222Printer, print）

即是說當使用者在位置 m222（location: m222）時，以及當時的時間為 08 時 00 分至 18 時 00 分（time: 0800, 1800）之間，並且此使用者所指派到的角色 為 m222 的實驗室成員（m222_LabMember），且當時的印表機狀態為準備中（stand by），那麼使用者即可以 m222 實驗室成員這個角色來對此公用印表機做列印的 動作。

方針定義 3. rROLES, objOBJECTS, pPERMISSIONS,

c_i, c_jCONTEXTS where c_i, c_jare the same type

I. c_iRContext（r） and Conflict（c_i, c_j） => c_jRContext（r）.

II. c_i OPContext（obj, p） and Conflict（c_i, c_j） =>

36 c_j OPContext（obj, p）.

在設計擔任一個角色所需要的情境組合時，或是執行某一個物件所需要的情 境組合時，情境組合中的多個情境有可能存在著衝突的情形，例如：當一個物件 被設定為某段時間可以被某些角色存取，卻也同時存在著此段時間內不能作任何 的存取動作，則會發生衝突的狀況。所以在設定情境組合時，必頇要清楚的瞭解 各情境之間的關係，避免情境衝突的發生。

方針定義 3 裡，r 為此環境下的角色集合內的一個角色；obj 為此環境下的某 個物件；p 為對物件可操作的權限；c_i, c_j為情境，且 c_i, c_j為同一個類型的情境；

Conflict（c_i, c_j）表示此二同類型的情境為衝突的情境。

在方針定義 3 中的第一個式子是說明 c_i為擔任角色 r 所需要的情境，並且

c_i, c_j此二情境為互相衝突的情境，所以在設定情境組合時，不能將 c_j也設定為 擔任此角色 r 所需要的情境，即是說不能將此二情境設定在同一個角色的情境組 合中，以避免發生衝突的情形。第二個式子是說明對物件 obj 進行操作 p 時所需 要的情境為 c_i，並且 c_i, c_j此二情境為互相衝突的情境，所以在設定情境組合

時，亦不能將 c_j也設定為對物件 obj 進行操作 p 時所需要的情境。透過方針 3 的檢查，可確保我們在方針庫（Policy Database）中的限制沒有衝突的情境組合，

而導致部份情境組合的角色無法正常的獲得，或是某些物件的權限無法取得。舉 例來說：

（time: 0000, 2400）RContext（r） and Conflict（（time: 0000, 2400）, （time:

0800, 1800））=> （time: 0800, 1800）RContext（r）

此例子是表示時間情境為上午 00 時 00 分到 24 時 00 分（time: 0000, 2400）

是擔任角色 r 所需要的權限，而該情境與另一個時間情境 08 時 00 分到 18 時 00 分（time: 0800, 1800）是衝突的情境條件，則不能將時間情境（time: 0800, 1800）

37

也設定為擔任角色 r 所需要的權限。雖然在感覺上時間情境（time: 0800, 1800）

是包含在時間情境（time: 0000, 2400），分別來看也都是正常的情境，但是在設 計情境組合時，這兩個情境是不能夠設定為同一組。若是在上午 8 點到下午 6 點 這段時間內，因為同時符合兩個情境條件，則在指派角色給使用者以及授予權限 給角色時將不會有問題，但是若是在上午 8 點到下午 6 點以外的時間，就會發生 與（time: 0000, 2400）符合情境，卻與（time: 0800, 1800）不符合的情形，因此 而發生衝突。所以，要避免能將這兩個情境同時設定在同一個角色所需要情境條 件組合中，以避免在角色指派時無法正確的將角色指派給使用者。

再舉另一個設定取得物件操作權限時避免情境衝突的例子：（location: m222）

 OPContext（obj, p） and Conflict（location: m222, location: m223） => （location:

m223） OPContext（obj, p）。此例子是表示位置情境為實驗室 m222（location:

m222）是對物件 obj 進行操作 p 時所需要的權限，並且與位置情境實驗室 m223

（location: m223）是衝突的情境條件，則不能將位置情境（location: m223）也設 定為對物件 obj 進行操作 p 時所需要的權限。雖然將（location: m222）與（location:

m223）分別來看也都是正常的情境，但是在設計情境組合時，這兩個情境是不 能夠設定為同一組，因為若是位置在實驗室 m222，就會發生與（location: m222）

符合情境，與（location: m223）則不符合的情形，而發生衝突，因此要避免能將 這兩個情境同時設定在取得物件操作權限時所需要的情境條件組合中。