2016-08-02 30 views
0

筆者近日瞭解到OIDC如何OAuth的2的頂部提供用戶身份,同時也成功地創造一個OIDC登錄到我的web應用程序。但是,對於授權部分,應用程序應該如何知道請求API的範圍尚不清楚。ID連接範圍/角色發現

例如,某些端點應與「管理」的範圍,以及應當從非管理員用戶隱藏相應的UI元素的保護。執行部分我可以輕鬆實現,但是當用戶登錄時,應用程序需要知道用戶是否是管理員 - 即是否要求「管理員」作用域/顯示與管理員相關的用戶界面部分。

有代表在來自IDP用戶配置文件應用程序特定的細節的任何標準的方式?最讓我感到困擾的是,據我所知,這些信息不能添加到來自Google/Twitter/Facebook的用戶配置文件中,因此需要a)額外的一層(IdentityServer/OpenAM/etc),或b)額外的Web應用程序數據庫中的用戶配置文件數據。

我的第一個想法是通過做a)添加自定義聲明 - 但是當涉及到與現有的IDP集成時,可能無法調整所有用戶配置文件(例如大型企業數據庫),因此我假設應用程序本身應該足夠靈活,可以將現有的用戶配置文件數據轉換爲「admin/not-admin」。

有沒有更好的解決方案?

回答

0

在我看來這不是立足您對您的身份提供者返回的權利授權一個很好的做法。 這個責任應該委託給UMA服務器。他決定或不允許訪問受保護資源的請求。 例如,我們有以下情形的圖像:

語境:一個電子商務企業已內部開發的由他的營銷團隊使用,以獲取關於他最忠實的客戶信息的工具。 該應用程序已在WPF中開發,並與RESTFUL API進行交互以檢索客戶端。 只有屬於該營銷組的此應用程序和用戶纔有權檢索該列表。

問題:應用程序如何訪問受保護的操作?

workflow

解決方案:工作流程是由三個大的步驟:

  • 身份令牌:檢索與隱批式身份令牌。該令牌返回給客戶端的回調參數
  • RPT令牌:身份和訪問令牌(有效期爲範圍uma_authorization & uma_protection)在檢索RPT一個請求中傳遞。 當WPF應用程序接收到該令牌時,會將令牌傳遞給Authorization頭以檢索忠誠的客戶端。這兩個參數都是授權策略所必需的。
  • 檢查RPT令牌:令牌是針對內省檢查端點,該端點由UMA服務器提供。

正如您所看到的,UMA服務器使用內部策略來授予/或不能訪問資源。 授權策略超出了UMA規範的範圍,您必須自己定義它:'(。 我開發了一個產品(開源)來輕鬆管理授權策略。如果您有興趣,可以在此處測試演示: http://lokit.westus.cloudapp.azure.com/Demo

注:如果你不滿意有關外部標識提供者返回的權利要求,隨時可以豐富他們(閱讀用例:「分配角色資源所有者」的文件中)