OAuth2用戶和基於角色的訪問控制

Question

我有一個Rails應用程序作爲一個OAuth 2.0提供者（使用oauth2-provider寶石）。它存儲所有與用戶有關的信息（賬戶，個人信息和角色）。有2個客戶端應用程序都通過這個應用程序進行身份驗證。客戶端應用程序可以使用client_credentials授權類型通過電子郵件查找用戶，並執行其他不需要授權代碼的事情。用戶還可以使用密碼授權類型登錄到客戶端應用程序。

現在我們面臨的問題是用戶的角色是在資源主機上全局定義的。因此，如果在資源主機上爲用戶分配admin角色，則該用戶在兩個客戶端上都是admin。我的問題是：我們應該做些什麼來實現更細粒度的訪問控制？即用戶可以是editor的app1，但不是app2。

我想最簡單的方式來做到這一點是改變像這樣的角色名：app1-admin，app2-admin，app1-editor，app2-editor等更大的問題是：我們是否正確執行這一整個系統;也就是說，我們應該在資源主機上存儲如此多的信息，還是應該將數據非規範化到客戶端應用程序上？

非規範化架構如下所示：資源主機上的所有用戶數據，每個客戶端主機上的本地化用戶數據。因此user@example.com將在資源主機上擁有他的個人信息，並將其editor角色存儲在客戶端app1上。如果他從不使用它，app2可能完全不知道他的存在。

非規範化模型的缺點是會有大量數據（帳戶ID，角色）和代碼（每個客戶端上的User和Role模型，單獨的管理界面等）的重複數據。

保持數據分離有什麼缺點嗎？客戶端應用程序都非常值得信賴 - 我們都是這樣做的 - 但我們很可能會添加額外的客戶端應用程序，這些應用程序將來不在我們的控制範圍之內。

Answer 1

到使用OAuth和其它類似的外部授權方法，因爲我看到的最正確的方法，是嚴格的身份驗證。所有業務/授權邏輯應始終在服務器部分進行處理，並且應始終保留用戶的中心記錄，並按外部類型的身份驗證服務鏈接到外部信息。

具有多/多組訪問的，也是必須的，如果你希望你的設置是可擴展的，面向未來的。這是一種與任何授權邏輯分開的標準設計，並且始終與業務規則直接相關。

Stackoverflow做了這樣的事情，要求您在之後使用外部方法登錄後在網站上創建實際帳戶。

更新：如果這些網站非常相似，您可以將此設計的子集分配給每個應用程序的對象，以保持應用程序特定的訪問規則。該對象還必須從具有全局規則的全局對象繼承（因此您可以例如在應用程序範圍或企業範圍內實施禁止）。

我會去包含接取設置/可涉及到兩個應用程序級別設置和全局設置的情況下，僅用於自動壓縮訪問的分配對象和角色。

其實你可以使用這個設計，即使它們不是太相似。這將幫助您避免重複設置和無意義（商業）角色。您可以純粹通過職位/目的來確定角色，然後通過鏈接到適當的訪問設置設置來強制您的限制。