將這兩天關於許可權的討論歸檔在這裡
許可權系統幹了什麼?
給出一套方法,將系統中的所有功能標識出來,組織起來,託管起來,將所有的資料組織起來標識出來託管起來,然後提供一個簡單的唯一的介面,這個介面的一端是應用系統一端是許可權引擎。
許可權引擎所回答的只是:誰是否對某資源具有實施某個動作(運動、計算)的許可權。返回的結果只有:有、沒有、許可權引擎異常了。
這個介面大概像這個樣子:
http://git.oschina.net/anycmd/anycmd/blob/master/src/Anycmd/ISecurityService.cs
====
@[author]Fan丶[/author]
引用
我想問你下。頁面上的按鈕許可權怎麼來控制顯示隱藏。
1。 動態生成的?
2。js批次隱藏控制?
3。你是怎麼做的呀。
許可權引擎負責判斷給定的使用者是否有對給定的資源實施給定的“操作”的許可權,許可權引擎只負責告知有還是沒有。而這個“操作”對應的是什麼按鈕,什麼選單,或者什麼頁面許可權引擎是不關心這些的,這是業務系統展示層的邏輯。許可權引擎告訴業務系統給定的使用者沒有對給定的資源實施給定的操作的許可權,然後展示層不展示對應的按鈕或頁面或選單就可以了。
許可權引擎可以告訴呼叫者給定的使用者是否有對給定的具體某條記錄的具體屬性甚至這個屬性取值的具體範圍有實施給定動作的許可權,甚至可以如果現在不是2014年9月1日就沒有許可權,許可權引擎為呼叫者返回“true、false、我異常了”,然後業務系統的展示層自己決定是否要展示和如何展示資料
====
@[author]Fan丶[/author]
我們反覆提到了許可權引擎,這是一個概念,是個抽象事物,它的規格已經被界定了,而這件事物的具體實現在https://git.oschina.net/anycmd/anycmd 中,而這件事物是執行在哪裡的?可以在一個獨立的程式也可以在和業務系統同一個程式,然後我們才需要許可權資料交換。這個抽象的事物anycmd可以實現,任何人都可以實現,突破anycmd的人可能正在大學裡讀書,也可能是剛入職的新手,但恐怕不是我們這一代了。
====
有些概念我們不一致:
什麼是組?組是沒有層級概念的。
簡單組。
一個組是一個地圖,整個森林中的樹木是一個集合,樹木型別的一個組則是一張記錄樹木位置的座標圖,圖上的樹木是整個森林的一個子集。
使用者繪製一張記錄樹木的位置的座標圖,然後可以把這張圖交給某個工人,從而工人按圖索驥去伐木。
不在圖上的樹木可能是不允許砍伐的。Group跟手工倉庫的區別是一個Group裡的資源的型別都是一樣的,而手工倉庫裡的資源可以不是同一型別的
(手工倉庫中的一條資源記錄需要ObjectType+ObjectID兩個欄位來標識而組只需一個欄位)。
手工倉庫也是“組”,手工倉庫是複雜組。
什麼是分類?我們人類幾萬年來無數人所維護出來的知識是被組織成一棵樹的結構的。所謂樹就是有偏移 = 層級 = 繼承。每一個節點所表示的都是一個資源集合(葉子節點都是暫時的,隨著我們的開拓,葉子節點下面將來可能會分出新枝,同樣根節點是虛擬的,根節點也是暫時的,這棵樹的組織結構一直都在相對穩定的調整著 或修剪 或發新枝 或合併),每一個節點的所有直接子節點稱作這個節點所表示的資源集合的“分類”。分類是沒有層級的。當我們的分類被有組織有紀律有偏移的進行的時候這時換個名字命名這種分類的“子類”,這種分類稱作“組織結構”,組織結構是樹形。關於‘圖’我暫時不懂。
角色模型上記錄父角色標識不合適:
角色與組織結構的差別可以從這個角度來說明,一個組織結構節點指代了一個資源集合,而一個角色同樣是指代了一個資源集合的,兩者的區別是組織結構是從“組織、管理”的角度對資源進行分類的,而角色是從‘使用’的角度對‘職能’進行分類的,職能是跨越組織結構的,職能是與組織結構無關的。
角色的層級分兩種:受限角色層次和通用角色層次。受限角色層次就是單繼承,而通用角色層次就是多繼承。通用角色層次是比受限角色層次更加良好的,通用角色層次的實現是不能透過角色模型上的ParentID來實現的。
說道這裡還沒說完:一個組織結構節點指代一個資源集合,這個資源集合是會繼續分類的,一個資源集合並不是指一“種”資源的集合。比如將我的系統視作我公司的眾多系統中的一個(我的公司是一個生產力組織單元,人類對資源建立起的組織結構是十分複雜的,從各種角度/屬性觀察有各種組織結構,這些組織結構相互交叉嗎?不交叉,如果交叉的話就說明違反了組織結構原則了。)這裡不考慮我們們的計算機系統之外的組織結構,那麼:
系統中一般有三次分類,三次分類從整體上看就是一種組織結構。
三次分類是:
1 劃分資源型別,此為第一次分類,一個資源型別實體對應的是一種資源的全部資料集;
2 劃分資源元素,此為第二次分類,這次分類是區分資源的屬性,每一個屬性對應定義一個值域。
3 劃分資源元素的值域單元,此為第三次分類,本次分類是對整個屬性值域進行單元劃分,終極的單元是不劃分,即每一個取值就是一個分類節點(在計算機世界中只有“離散”不存在“連續性”這個概念)。
由於基本上所有的值都是可以比較大小的,從而第三次分類往往會基於算數運算劃分單元。
對與系統內部來說三次分類基本足夠了
單純的一次分類稱作分類,把多次分類從整體上看的話如果這些分類具有偏移量則就是組織結構。
組織結構上不封頂下不封底!
整套人類的知識就是一個組織結構,而這個組織結構上的每一個節點就是一次分類。
所有的問題最終劃歸為:
1 如何組織資料;
2 如何表現資料的運動。
模型 = 資料 + 運動。
使用組織結構和分類法來分析下面幾個常見的概念:
只要用勁理解了“組織結構”則部門、崗位這兩個概念就弄明白了,機構的本質就是組織結構,而崗位是具有組織結構屬性的工作組。
機構:毫無疑問它是組織結構節點;
崗位:崗位是繫結到組織結構的工作組;
工作組:工作組是跨越組織結構的資源集,這個資源組中“具有主體”這種型別的資源元素,具有組織結構屬性的工作組的意思是該組中的資源被約束為只能來自本組織結構和它的下級組織結構。
組:資源集,這個資源集中不一定只有一種型別的資源。
簡單組:單一型別的資源集;
職位:補是組織結構。職位屬於分類或字典,職位不是繫結到組織結構的,職位沒有組織結構屬性。不同組織結構的人員可能擁有相同的職位。
我的畢生所學都會融入anycmd中去http://git.oschina.net/anycmd/anycmd
anycmd不為同代人構建,而是為下代人構建:
如果你比原作者小5歲或5歲以上,所有開源協議在anycmd這裡作廢(原作者1984年生)
=====
需要一個良好的標準,需要一些良好的概念,需要一層良好的抽象。需要一個良好的形式。安全管理需要凌駕於具體的業務引擎之上,具體的業務引擎具只是安全“策略執行點”,執行安全策略是業務系統的義務,這個義務執行起來不難,任何一個業務系統都是沒有分別的。
像xacml這種東西既有結構又有運算,它在表達安全策略方面是功能完備的。當然沒有必要使用xacml把xacml當作C#這種語言來在CLR中書寫我們的所有業務邏輯,xacml提供的是一個書寫安全策略的規範。規範很重要,有了這層抽象才能做到將安全管理跨越具體的業務系統。
=====
哪些是許可權,哪些是業務,它們是沒有清晰的分界線的。使用一個良好的許可權引擎提供的語言是可以書寫出任何業務邏輯的,但是我們應該用它來做它擅長的事情而不是用來書寫業務邏輯。
所有的業務邏輯都可以使用許可權語言來書寫一份等效的程式碼。問題是這份程式碼需要策略執行點去解釋,而像CLR這種是用來解釋C# VB.net CLI這種語言的不是專門用來解釋許可權語言的,那些邏輯應該使用許可權語言書寫哪些應該使用C#書寫是需要你我根據具體的業務需求和業務的發展變化規律來權衡的。
=====
@滷鴿
引用
認真研讀了下,首先拜謝樓主分享設計
有問題想請教樓主,
1、Actions和Paths樓主設計的初衷是什麼,我總感覺可以將兩者合併起來
只需一個Paths表,然後附加上Url?
2、針對公司組織架構層級比較複雜的許可權,你這裡直接將使用者組實現成組織架構圖型別,不知理解有誤?
3、對資料怎麼控制許可權,看了評論說用Restriction,不解。。
發表一下看法,我不太理解Path是個什麼概念?是不是Url?如果是Url的話那麼它的特點就是它有層級。它是分層的,它是屬於組織結構概念範疇的。使用Url來作為系統內部的資源標識恐怕不妥,我們可以使用使用Url來引用我們的系統之外的資源但不應該使用Url這種層級結構來沖淡我們系統內部的標識。為什麼這麼說呢?我們的系統存在的意義是什麼?就是對我們的系統內部的資源進行分類、組織、管理啊,我們的系統內部已經根據資源型別做了第一次分類,根據實體屬性做了第二次分類,並且甚至面向屬性的值域做了第三次分類。並且甚至我們還為資源附加上了組織結構屬性用來對具體型別下的所有該型別的資源記錄集合中的元素進行了單元劃分。這麼多次有組織有偏移有紀律的分類從整體上看就是“組織結構”就是“樹”就是“層級”啊。既然這樣為什麼還要在系統內部使用層級性的Url,為什麼不直接使用非層級的簡單標識然後依賴於系統內部對資源的具有層級性的分類來索引記錄而還去使用Url然後從Url中解析出層級結構呢?
====
請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
====
有一個問題我一直很糾結,就是:
程式導向 => 物件導向 => 面向物理
物理化到一定程度 駭客帝國就出現了。網路空間和人類生活的空間早晚被物理化打通,一旦打通則網路空間的主體將會有機會控制我們的空間。不要說人類造不出勝過人類的智慧體,這只是早晚的事。如果我們的網路中出現了邪惡的主體怎麼辦?
比如這個邪惡的主體故意把一些不該運動到妻子主體系統中的資訊運動到妻子主體系統中去,他/她故意讓妻子看到丈夫的出軌記錄。這給我們人類空間中的丈夫和妻子帶來了痛苦,安全系統要防止這種事情發生!
如果一旦這種事情已經發生了,丈夫的出軌記錄已經運動到妻子中去了,該怎麼辦呢?我想到了一個辦法,控制人類:透過人類工程消除妻子和丈夫腦中的這部分資料,讓這對夫妻恢復到出軌之前的狀態。但是,但是控制人類是邪惡的!anycmd的目的是防止邪惡的主體控制人類,但是為了防止修復已經造成的傷害我們自己又不得不去幹邪惡的事情去控制人類。
這如何是好?
====
@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
稍微看了一下你的框架,和我的思想有很大的不同。不知道你的許可權系統對這種需求是怎麼實現的?
公司有IT部門和銷售部門,IT部門下面有C組, Java組,C組裡面有張三和李四。能夠說一下你是怎麼控制許可權(選單,資源和操作)?
這裡我可能需要按照anycmd定義的一些穩定的概念才能回答好這個問題:
1,部門是“組織結構”節點。“組”一旦被繫結到組織結構意思就是說接受“組織結構”的約束,你這裡的IT部門下的C組和Java組它們都是“組”只不過這些組被繫結到了具體的組織結構節點,從而接受組織結構的限制,組織結構限制這些組中組合的資源必須來自於本組織結構節點和自己的後代節點。
補充:就像你這裡的Java組和C組,它們組合的是哪些資源呢?你這個屬於“工作組”,工作組也是組,工作組屬於組的子類,工作組的特點是它組合的資源中必定有“主體”型別的資源。主體是什麼呢?主體通常是我們人類。工作組中組織的資源有“角色型別的資源”也有“人類型別的資源”,還可以有“計算機型別的資源”(因為C組的工作開展需要計算機需要網路需要辦公桌椅),組中也可以有“操作型別的資源”但組中已經有角色型別的資源了,如果角色分類的合理的話僅透過組合角色應該是可以組合出滿足需求的許可權集的。
2,選單隻和操作(或叫功能、或叫動作、或叫運動)有關,跟組織結構和組和角色都沒有關係,一個選單是否展示只在於當前使用者是否有實施選單關聯的操作(或叫功能、或叫動作、或叫運動)的許可權。
3,Role、Group、Organization等都是用來組織資源、操作、主體用的。許可權的控制最終只認Resource、Action、Subject這幾個基本概念,其他概念一概不認的。
====
@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
稍微看了一下你的框架,和我的思想有很大的不同。不知道你的許可權系統對這種需求是怎麼實現的?
公司有IT部門和銷售部門,IT部門下面有C組, Java組,C組裡面有張三和李四。能夠說一下你是怎麼控制許可權(選單,資源和操作)?
這裡我...
上級當然是可以拒絕請求的,這種情況是通常的正常情況。上級做的是宏觀管理,上級不需要去詳細瞭解自己管轄的資源的具體每一個單元。比如一個訊息到來了,這個訊息請求解僱某個公司的某個組織結構節點下的某個員工,那麼這個請求不一定是會被執行的。訊息來到我們的系統,這條訊息上必定帶有這個員工的組織結構屬性值,我們的系統首先索引這個組織結構的根組織結構節點的配置資訊去判斷這個根組織結構下的員工是否可以解僱,然而根節點往往說“我不知道,請詢問下級節點”,於是許可權引擎繼續往下級詢問,知道明確的得知是“允許還是不允許”不可能詢問到葉子節點還不知道是允許還是不允許,因為系統全域性會配置“末級隱式允許意為什麼允許還是不允許?”。組織結構是棵樹,遇到組織結構要爬樹,爬上去再下來,上級節點的“顯式允許和顯式”都會重寫任何子節點,只有上級節點不知道允許還是不允許的時候會繼續往下級詢問。
====
@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
稍微看了一下你的框架,和我的思想有很大的不同。不知道你的許可權系統對這種需求是怎麼實現的?
公司有IT部門和銷售部門,IT部門下面有C組, Java組,C組裡面有張三和李四。能夠說一下你...
考慮一下現在我們是不是想要把許可權細化到實體級?如果是的話:
實體級的許可權是什麼?實體級的許可權要和實體記錄儲存在一起,要始終儘量遵循一個原則——每一級的安全策略都要和自己本級實體儲存在一起。那麼實體級的安全控制其實沒有任何特別的,實體資源記錄上會附加一個“安全欄位”,這個安全資源裡儲存的是這個實體的安全策略,這個實體的安全策略只有在訪問到這個實體的時候才會需要這也是為什麼安全策略要和實體一起儲存在相同的物理位置。如果只是部分實體記錄需要實體級的安全控制而其它部分不需要實體級的安全控制這個時候考慮根據從是否需要實體級安全控制的角度建立分類附加到實體資源記錄上去,甚至還可以考慮將分類提升為組織結構從而將需要實體級安全控制的和不需要實體級安全控制的資源組織到分別組織到不同的安全控制組織結構節點去,組織結構是什麼?組織結構就累死域,比如我訪問騰訊的伺服器是不會為百度的伺服器帶來任何壓力的,因為它們在路由器上就已經分開了。
無論哪一級的安全策略,都是面向相同的主體,本級的資源,相同的動作列表來書寫的。不同級的安全策略只有執行順序不同沒有結構上的任何不同。
給出一套方法,將系統中的所有功能標識出來,組織起來,託管起來,將所有的資料組織起來標識出來託管起來,然後提供一個簡單的唯一的介面,這個介面的一端是應用系統一端是許可權引擎。
許可權引擎所回答的只是:誰是否對某資源具有實施某個動作(運動、計算)的許可權。返回的結果只有:有、沒有、許可權引擎異常了。
這個介面大概像這個樣子:
http://git.oschina.net/anycmd/anycmd/blob/master/src/Anycmd/ISecurityService.cs
====
@[author]Fan丶[/author]
引用
我想問你下。頁面上的按鈕許可權怎麼來控制顯示隱藏。
1。 動態生成的?
2。js批次隱藏控制?
3。你是怎麼做的呀。
許可權引擎負責判斷給定的使用者是否有對給定的資源實施給定的“操作”的許可權,許可權引擎只負責告知有還是沒有。而這個“操作”對應的是什麼按鈕,什麼選單,或者什麼頁面許可權引擎是不關心這些的,這是業務系統展示層的邏輯。許可權引擎告訴業務系統給定的使用者沒有對給定的資源實施給定的操作的許可權,然後展示層不展示對應的按鈕或頁面或選單就可以了。
許可權引擎可以告訴呼叫者給定的使用者是否有對給定的具體某條記錄的具體屬性甚至這個屬性取值的具體範圍有實施給定動作的許可權,甚至可以如果現在不是2014年9月1日就沒有許可權,許可權引擎為呼叫者返回“true、false、我異常了”,然後業務系統的展示層自己決定是否要展示和如何展示資料
====
@[author]Fan丶[/author]
我們反覆提到了許可權引擎,這是一個概念,是個抽象事物,它的規格已經被界定了,而這件事物的具體實現在https://git.oschina.net/anycmd/anycmd 中,而這件事物是執行在哪裡的?可以在一個獨立的程式也可以在和業務系統同一個程式,然後我們才需要許可權資料交換。這個抽象的事物anycmd可以實現,任何人都可以實現,突破anycmd的人可能正在大學裡讀書,也可能是剛入職的新手,但恐怕不是我們這一代了。
====
有些概念我們不一致:
什麼是組?組是沒有層級概念的。
簡單組。
一個組是一個地圖,整個森林中的樹木是一個集合,樹木型別的一個組則是一張記錄樹木位置的座標圖,圖上的樹木是整個森林的一個子集。
使用者繪製一張記錄樹木的位置的座標圖,然後可以把這張圖交給某個工人,從而工人按圖索驥去伐木。
不在圖上的樹木可能是不允許砍伐的。Group跟手工倉庫的區別是一個Group裡的資源的型別都是一樣的,而手工倉庫裡的資源可以不是同一型別的
(手工倉庫中的一條資源記錄需要ObjectType+ObjectID兩個欄位來標識而組只需一個欄位)。
手工倉庫也是“組”,手工倉庫是複雜組。
什麼是分類?我們人類幾萬年來無數人所維護出來的知識是被組織成一棵樹的結構的。所謂樹就是有偏移 = 層級 = 繼承。每一個節點所表示的都是一個資源集合(葉子節點都是暫時的,隨著我們的開拓,葉子節點下面將來可能會分出新枝,同樣根節點是虛擬的,根節點也是暫時的,這棵樹的組織結構一直都在相對穩定的調整著 或修剪 或發新枝 或合併),每一個節點的所有直接子節點稱作這個節點所表示的資源集合的“分類”。分類是沒有層級的。當我們的分類被有組織有紀律有偏移的進行的時候這時換個名字命名這種分類的“子類”,這種分類稱作“組織結構”,組織結構是樹形。關於‘圖’我暫時不懂。
角色模型上記錄父角色標識不合適:
角色與組織結構的差別可以從這個角度來說明,一個組織結構節點指代了一個資源集合,而一個角色同樣是指代了一個資源集合的,兩者的區別是組織結構是從“組織、管理”的角度對資源進行分類的,而角色是從‘使用’的角度對‘職能’進行分類的,職能是跨越組織結構的,職能是與組織結構無關的。
角色的層級分兩種:受限角色層次和通用角色層次。受限角色層次就是單繼承,而通用角色層次就是多繼承。通用角色層次是比受限角色層次更加良好的,通用角色層次的實現是不能透過角色模型上的ParentID來實現的。
說道這裡還沒說完:一個組織結構節點指代一個資源集合,這個資源集合是會繼續分類的,一個資源集合並不是指一“種”資源的集合。比如將我的系統視作我公司的眾多系統中的一個(我的公司是一個生產力組織單元,人類對資源建立起的組織結構是十分複雜的,從各種角度/屬性觀察有各種組織結構,這些組織結構相互交叉嗎?不交叉,如果交叉的話就說明違反了組織結構原則了。)這裡不考慮我們們的計算機系統之外的組織結構,那麼:
系統中一般有三次分類,三次分類從整體上看就是一種組織結構。
三次分類是:
1 劃分資源型別,此為第一次分類,一個資源型別實體對應的是一種資源的全部資料集;
2 劃分資源元素,此為第二次分類,這次分類是區分資源的屬性,每一個屬性對應定義一個值域。
3 劃分資源元素的值域單元,此為第三次分類,本次分類是對整個屬性值域進行單元劃分,終極的單元是不劃分,即每一個取值就是一個分類節點(在計算機世界中只有“離散”不存在“連續性”這個概念)。
由於基本上所有的值都是可以比較大小的,從而第三次分類往往會基於算數運算劃分單元。
對與系統內部來說三次分類基本足夠了
單純的一次分類稱作分類,把多次分類從整體上看的話如果這些分類具有偏移量則就是組織結構。
組織結構上不封頂下不封底!
整套人類的知識就是一個組織結構,而這個組織結構上的每一個節點就是一次分類。
所有的問題最終劃歸為:
1 如何組織資料;
2 如何表現資料的運動。
模型 = 資料 + 運動。
使用組織結構和分類法來分析下面幾個常見的概念:
只要用勁理解了“組織結構”則部門、崗位這兩個概念就弄明白了,機構的本質就是組織結構,而崗位是具有組織結構屬性的工作組。
機構:毫無疑問它是組織結構節點;
崗位:崗位是繫結到組織結構的工作組;
工作組:工作組是跨越組織結構的資源集,這個資源組中“具有主體”這種型別的資源元素,具有組織結構屬性的工作組的意思是該組中的資源被約束為只能來自本組織結構和它的下級組織結構。
組:資源集,這個資源集中不一定只有一種型別的資源。
簡單組:單一型別的資源集;
職位:補是組織結構。職位屬於分類或字典,職位不是繫結到組織結構的,職位沒有組織結構屬性。不同組織結構的人員可能擁有相同的職位。
我的畢生所學都會融入anycmd中去http://git.oschina.net/anycmd/anycmd
anycmd不為同代人構建,而是為下代人構建:
如果你比原作者小5歲或5歲以上,所有開源協議在anycmd這裡作廢(原作者1984年生)
=====
需要一個良好的標準,需要一些良好的概念,需要一層良好的抽象。需要一個良好的形式。安全管理需要凌駕於具體的業務引擎之上,具體的業務引擎具只是安全“策略執行點”,執行安全策略是業務系統的義務,這個義務執行起來不難,任何一個業務系統都是沒有分別的。
像xacml這種東西既有結構又有運算,它在表達安全策略方面是功能完備的。當然沒有必要使用xacml把xacml當作C#這種語言來在CLR中書寫我們的所有業務邏輯,xacml提供的是一個書寫安全策略的規範。規範很重要,有了這層抽象才能做到將安全管理跨越具體的業務系統。
=====
哪些是許可權,哪些是業務,它們是沒有清晰的分界線的。使用一個良好的許可權引擎提供的語言是可以書寫出任何業務邏輯的,但是我們應該用它來做它擅長的事情而不是用來書寫業務邏輯。
所有的業務邏輯都可以使用許可權語言來書寫一份等效的程式碼。問題是這份程式碼需要策略執行點去解釋,而像CLR這種是用來解釋C# VB.net CLI這種語言的不是專門用來解釋許可權語言的,那些邏輯應該使用許可權語言書寫哪些應該使用C#書寫是需要你我根據具體的業務需求和業務的發展變化規律來權衡的。
=====
@滷鴿
引用
認真研讀了下,首先拜謝樓主分享設計
有問題想請教樓主,
1、Actions和Paths樓主設計的初衷是什麼,我總感覺可以將兩者合併起來
只需一個Paths表,然後附加上Url?
2、針對公司組織架構層級比較複雜的許可權,你這裡直接將使用者組實現成組織架構圖型別,不知理解有誤?
3、對資料怎麼控制許可權,看了評論說用Restriction,不解。。
發表一下看法,我不太理解Path是個什麼概念?是不是Url?如果是Url的話那麼它的特點就是它有層級。它是分層的,它是屬於組織結構概念範疇的。使用Url來作為系統內部的資源標識恐怕不妥,我們可以使用使用Url來引用我們的系統之外的資源但不應該使用Url這種層級結構來沖淡我們系統內部的標識。為什麼這麼說呢?我們的系統存在的意義是什麼?就是對我們的系統內部的資源進行分類、組織、管理啊,我們的系統內部已經根據資源型別做了第一次分類,根據實體屬性做了第二次分類,並且甚至面向屬性的值域做了第三次分類。並且甚至我們還為資源附加上了組織結構屬性用來對具體型別下的所有該型別的資源記錄集合中的元素進行了單元劃分。這麼多次有組織有偏移有紀律的分類從整體上看就是“組織結構”就是“樹”就是“層級”啊。既然這樣為什麼還要在系統內部使用層級性的Url,為什麼不直接使用非層級的簡單標識然後依賴於系統內部對資源的具有層級性的分類來索引記錄而還去使用Url然後從Url中解析出層級結構呢?
====
請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
====
有一個問題我一直很糾結,就是:
程式導向 => 物件導向 => 面向物理
物理化到一定程度 駭客帝國就出現了。網路空間和人類生活的空間早晚被物理化打通,一旦打通則網路空間的主體將會有機會控制我們的空間。不要說人類造不出勝過人類的智慧體,這只是早晚的事。如果我們的網路中出現了邪惡的主體怎麼辦?
比如這個邪惡的主體故意把一些不該運動到妻子主體系統中的資訊運動到妻子主體系統中去,他/她故意讓妻子看到丈夫的出軌記錄。這給我們人類空間中的丈夫和妻子帶來了痛苦,安全系統要防止這種事情發生!
如果一旦這種事情已經發生了,丈夫的出軌記錄已經運動到妻子中去了,該怎麼辦呢?我想到了一個辦法,控制人類:透過人類工程消除妻子和丈夫腦中的這部分資料,讓這對夫妻恢復到出軌之前的狀態。但是,但是控制人類是邪惡的!anycmd的目的是防止邪惡的主體控制人類,但是為了防止修復已經造成的傷害我們自己又不得不去幹邪惡的事情去控制人類。
這如何是好?
====
@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
稍微看了一下你的框架,和我的思想有很大的不同。不知道你的許可權系統對這種需求是怎麼實現的?
公司有IT部門和銷售部門,IT部門下面有C組, Java組,C組裡面有張三和李四。能夠說一下你是怎麼控制許可權(選單,資源和操作)?
這裡我可能需要按照anycmd定義的一些穩定的概念才能回答好這個問題:
1,部門是“組織結構”節點。“組”一旦被繫結到組織結構意思就是說接受“組織結構”的約束,你這裡的IT部門下的C組和Java組它們都是“組”只不過這些組被繫結到了具體的組織結構節點,從而接受組織結構的限制,組織結構限制這些組中組合的資源必須來自於本組織結構節點和自己的後代節點。
補充:就像你這裡的Java組和C組,它們組合的是哪些資源呢?你這個屬於“工作組”,工作組也是組,工作組屬於組的子類,工作組的特點是它組合的資源中必定有“主體”型別的資源。主體是什麼呢?主體通常是我們人類。工作組中組織的資源有“角色型別的資源”也有“人類型別的資源”,還可以有“計算機型別的資源”(因為C組的工作開展需要計算機需要網路需要辦公桌椅),組中也可以有“操作型別的資源”但組中已經有角色型別的資源了,如果角色分類的合理的話僅透過組合角色應該是可以組合出滿足需求的許可權集的。
2,選單隻和操作(或叫功能、或叫動作、或叫運動)有關,跟組織結構和組和角色都沒有關係,一個選單是否展示只在於當前使用者是否有實施選單關聯的操作(或叫功能、或叫動作、或叫運動)的許可權。
3,Role、Group、Organization等都是用來組織資源、操作、主體用的。許可權的控制最終只認Resource、Action、Subject這幾個基本概念,其他概念一概不認的。
====
@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
稍微看了一下你的框架,和我的思想有很大的不同。不知道你的許可權系統對這種需求是怎麼實現的?
公司有IT部門和銷售部門,IT部門下面有C組, Java組,C組裡面有張三和李四。能夠說一下你是怎麼控制許可權(選單,資源和操作)?
這裡我...
上級當然是可以拒絕請求的,這種情況是通常的正常情況。上級做的是宏觀管理,上級不需要去詳細瞭解自己管轄的資源的具體每一個單元。比如一個訊息到來了,這個訊息請求解僱某個公司的某個組織結構節點下的某個員工,那麼這個請求不一定是會被執行的。訊息來到我們的系統,這條訊息上必定帶有這個員工的組織結構屬性值,我們的系統首先索引這個組織結構的根組織結構節點的配置資訊去判斷這個根組織結構下的員工是否可以解僱,然而根節點往往說“我不知道,請詢問下級節點”,於是許可權引擎繼續往下級詢問,知道明確的得知是“允許還是不允許”不可能詢問到葉子節點還不知道是允許還是不允許,因為系統全域性會配置“末級隱式允許意為什麼允許還是不允許?”。組織結構是棵樹,遇到組織結構要爬樹,爬上去再下來,上級節點的“顯式允許和顯式”都會重寫任何子節點,只有上級節點不知道允許還是不允許的時候會繼續往下級詢問。
====
@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]聖殿騎士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用請考慮大家的許可權系統能否做到如下描述的需求:
任何虛擬主體在任何虛擬空間、虛擬時間對任何虛擬客體發引發何運動的許可權,引發運動的輸入、運動的結果,運動次數都是受控的。
這是anycmd努力致力於實現的
http://git.oschina.net/anycmd/anycmd
稍微看了一下你的框架,和我的思想有很大的不同。不知道你的許可權系統對這種需求是怎麼實現的?
公司有IT部門和銷售部門,IT部門下面有C組, Java組,C組裡面有張三和李四。能夠說一下你...
考慮一下現在我們是不是想要把許可權細化到實體級?如果是的話:
實體級的許可權是什麼?實體級的許可權要和實體記錄儲存在一起,要始終儘量遵循一個原則——每一級的安全策略都要和自己本級實體儲存在一起。那麼實體級的安全控制其實沒有任何特別的,實體資源記錄上會附加一個“安全欄位”,這個安全資源裡儲存的是這個實體的安全策略,這個實體的安全策略只有在訪問到這個實體的時候才會需要這也是為什麼安全策略要和實體一起儲存在相同的物理位置。如果只是部分實體記錄需要實體級的安全控制而其它部分不需要實體級的安全控制這個時候考慮根據從是否需要實體級安全控制的角度建立分類附加到實體資源記錄上去,甚至還可以考慮將分類提升為組織結構從而將需要實體級安全控制的和不需要實體級安全控制的資源組織到分別組織到不同的安全控制組織結構節點去,組織結構是什麼?組織結構就累死域,比如我訪問騰訊的伺服器是不會為百度的伺服器帶來任何壓力的,因為它們在路由器上就已經分開了。
無論哪一級的安全策略,都是面向相同的主體,本級的資源,相同的動作列表來書寫的。不同級的安全策略只有執行順序不同沒有結構上的任何不同。
相關文章
- 關於jdon裡許可權系統的問題
- 關於oracle檔案許可權的問題Oracle
- 兩個關於許可權設定的問題思考
- RBAC的許可權關係很難嗎?純手操作,看這裡就明白了
- [提問交流]關於onethink模型這塊的討論模型
- 我們無法從這裡到達那裡——關於《平面宇宙》的閱讀、討論和思考
- 關於動態許可權
- 【轉】關於MySQL許可權MySql
- 關於mysql許可權管理MySql
- [技術討論]資料許可權中的理論和實際
- 深入討論通用許可權元件的理論和設計實現。元件
- postgresql關於許可權的總結SQL
- 關於 Laravel 日誌許可權Laravel
- 第十一篇:Linux中許可權的再討論( 下 )Linux
- 關於許可權系統的設計
- linux 檔案許可權 s 許可權和 t 許可權解析Linux
- 第十篇:Linux中許可權的再討論( 上 )Linux
- 關於在 Angular 應用裡重複呼叫 RouterModule.forRoot(ROUTES) 的討論Angular
- 關於公司程式碼許可權的問題
- 關於許可權管理的實用指令碼指令碼
- 續:關於許可權系統的設計
- 檢視角色裡包含的系統許可權、物件許可權和角色物件
- 關於機器學習的知識點,全在這篇文章裡了機器學習
- 關於檔案寫入的原子性討論
- 修改檔案的許可權
- java反射——關於許可權和異常Java反射
- Linux的檔案存取許可權和0644許可權Linux
- 【LIUNX】目錄或檔案許可權,許可權授予
- 資料許可權就該這麼設計,yyyds!
- postgresql關於訪問檢視需要的許可權SQL
- mongodb關於使用者許可權的總結MongoDB
- 關於系統許可權的設計-位操作
- 關於under any table/view 許可權的解釋View
- 關於許可權系統的一些思考
- Oracle的物件許可權、角色許可權、系統許可權Oracle物件
- pg許可權相關
- 關於oracle SCN 的討論Oracle
- Atitit godaddy 檔案許可權 root許可權設定Go