最近在研究微軟的企業庫（
entlib
）時，對它的認證和授權模組很感興趣，經過仔細研究，更進一步了解了它的機制，並把它們經過修改應用到了三層的架構上，這裡不敢獨享這種優秀的解決方案，把一些最簡單的原理寫出來給大家分享，也許經過您的努力，可以輕易把它移植到別的平台上。如果您想深入了解它的實現方法，可以參考微軟的企業庫程式，不過它只提供了配置檔案的實現方式，基於資料庫的可以參考
gotdot***
上的相關實現，基於三層的實現可以和我一塊**，下面是我對於這種解決方案的一點認識。
在通常的軟體開發中，特別是關於企業資訊化這一部分，認證和授權一般都是很重要的部分。在傳統的解決方案裡，大都是這樣來實現的：
1．先設計好各種許可權
2．建立各種角色，給每乙個角色繫結各種許可權
3．對每乙個使用者繫結乙個或多個角色
4．授權時，根據使用者的角色判斷他是否具有某個許可權
這種方法歷史悠久，簡單易懂，能解決絕大部分企業的應用，但隨著企業業務複雜度的提高，它的侷限性也越來越明顯了，最重要的是，角色並不能很好的與實際的業務對應起來。為了解決這種問題，最近流行起來的一種全新的授權機制是基於規則的授權機制。它的實現是這樣的：
1．建立各種角色
2．根據具體的許可權定義規則
3．對每乙個使用者繫結乙個或多個角色
4．授權時判斷使用者的角色是否滿足該許可權的規則。
這樣聽起來似乎有些模糊，不很明白究竟是怎麼回事，我先舉乙個最簡單的例子來作為說明：
假設我們定義了這樣幾個角色：
sales
（售貨員），
salemanager
（銷售經理），
excellenceemp
（優秀員工），
generalmanager
（總經理）
如果我們要為打折許可權定義這樣一種規則：
只有銷售經理和總經理可以打折，可以定義如下：
name
：rebate
（規則名稱）
expression：r
：salemanager or r
：generalmanager
（規則表示式）
這樣，當具有銷售經理或總經理角色的使用者登陸後，就可以擁有打折的許可權，因為他們可以通過規則表示式的驗證。
當然，如果業務邏輯不同，還可以修改許可權驗證規則，例如：
如果我們要為打折許可權定義這樣一種規則：
只有銷售經理和總經理以及售貨員中的優秀員工可以打折，可以定義如下：
name
：rebate
（規則名稱）
expression：r
：salemanager or r
：generalmanager or（r
：sales and r
：excellenceemp
）（規則表示式）
如果我們要為打折許可權定義這樣一種規則：
只有銷售經理和總經理以及售貨員中除了名稱叫
xiaoming
的優秀員工可以打折，可以定義如下：
name
：rebate
（規則名稱）
expression：r
：salemanager or r
：generalmanager or（r
：sales and r
：excellenceemp and
（not i
：xiaoming
））（規則表示式）
這些表示式也許你不容易看懂，只要你了解了授權規則的幾個要素，就很容易明白了：
i：（身份）
l特定人員（例如：
xiaoming）l
匿名使用者（？）
l任何人（*）
r：（角色）
l特定角色（例如：
salemanager）l
任何角色（*）
關係運算子
landlor
lnotl()
使用這些規則定義要素，可以定義出非常複雜的規則表示式來，應該能滿足更大範圍內的業務需求。
如果我們把這些角色和規則都儲存在資料庫中，我們就可以隨時修改使用者的角色和授權規則，這樣就可以更大程度上滿足使用者自定義規則的要求，使其更符合企業實際業務的要求。
當然，上面這些都是關於授權的，授權一般有乙個前提，就是通過了認證（其實沒有認證也是一種認證，標明你是匿名使用者），認證一般較簡單，沒有什麼特殊的地方，有一點較重要，就是可以把認證後的資訊快取起來，不用每次授權都重新認證，也可以把認證資訊儲存到本地，這在開發離線程式時很有用。
OAuth 授權機制
有乙個 雲沖印 的 可以將使用者儲存在google的 沖印出來。使用者為了使用該服務，必須讓 雲沖印 讀取自己儲存在google上的 問題是只有得到使用者的授權，google才會同意 雲沖印 讀取這些 那麼，雲沖印 怎樣獲得使用者的授權呢？傳統方法是，使用者將自己的google使用者名稱和密碼，告訴...
簡單的 React 授權機制
大多數的應用都需要身份驗證機制和授權機制，當驗證機制確認某些實體是合法使用者時，授權機制將根據使用者的角色和許可權去決定使用者是否被允許去執行這些操作 在大多數情況下，我們通常不需要特殊的模組或者庫來處理授權，大多數的工具函式已經足夠了。由你提供的應用內的驗證或者授權解決方法是可以變化的。你可能會決...
iOS簽名授權機制
幾個重要的概念 1.非對稱加密 非對稱加密演算法需要兩個金鑰 公開金鑰 publickey 和私有金鑰 privatekey 公開金鑰與私有金鑰是一對，如果用公開金鑰對資料進行加密，只有用對應的私有金鑰才能解密 如果用私有金鑰對資料進行加密，那麼只有用對應的公開金鑰才能解密。私鑰是要保密的，公鑰可以...