web-dev-qa-db-ja.com

OAuthでリソースごとの（きめの細かい）アクセス許可を処理するにはどうすればよいですか？

OAuth 2.0を使用してアプリアーキテクチャを設計しています。別のResource ServerとAuthorization Server。後者は、ユーザーとユーザーが利用できるスコープのデータベースを保持します。

今、私の質問は：リソースごとのきめ細かいアクセス許可をどのようにどこに保存/モデル化するのですか？

私はファイル共有アプリで発生するのと同様のシナリオについて話しています。たとえば、Dropboxの場合、ユーザーは他のユーザーと共有するファイルを選択できます 。 OAuthのコンテキストでこれをモデル化する方法は？

特に、私の場合、一部のユーザーがAuthorization Serverデータベースに完全に存在する可能性があります（Resource Serverは、すべて）。それらを「読み取り専用ユーザー」と呼びましょう。 [〜＃〜] as [〜＃〜]では、read_files_shared_to_meのスコープにアクセスできます。したがって、そのスコープは、特定のリソースを要求するときにmyClient AppがResource Serverに表示する許可/トークンです（ファイル）。 OAuth（2.0）のフレームワークで、どのファイルがどのユーザーに共有されているかを追跡するにはどうすればよいですか？

  • それがResource Serverの責任である場合、「許可」のリストをどのように格納する必要がありますかユーザー（ユーザーがAuthorization Serverにのみ存在する場合）？ [〜＃〜] rs [〜＃〜]が "token introspection endpoint" of[〜＃〜] as [〜＃〜]特定のユーザーが要求している内容をドリルダウンし、リソースごとの「許可ユーザー」のリスト（「ACL」）を保存しますか？
  • それがAuthorization Serverの責任である場合、「利用可能なリソースこのユーザー」から[〜＃〜] rs [〜＃〜]？私が理解しているところによると、「スコープ」はかなり一般的であり、具体的な細かいリソースではなく「役割/グループ」に対応しているため、リソースIDのリストをAuthorization Grant/Access Tokenの「scope」フィールドに入れても、大丈夫？

1さらに調査した後、 2011スレッドで[oauth-wg]メーリングリスト で同様の質問を見つけました。そこにいくつかの答えは「UMA」を見ることを示唆しています。残念ながら、リンクは少し腐っているか、あいまいすぎているようです。 UMA の見かけのメインページは、巨大であり、まだ不明瞭です。また、それが2018年にまだ関連性があり、最新であるかどうかははっきりしません。UMAでさらにグーグル検索すると、役立つ結果を見つけることができませんでした。 「UMAを使用する」が回答として書きたい場合は、それをどのように適用すべきかについてもう少し説明してみてください。また、この目的のためにUMAを使用する具体的なサービスを知っていますか？

oauth2oauth
10
akavel

ええ、自分の質問に答えます... UMAについてもう少しフォローアップしましたが、確かにある種の可能な解決策のようです：

[〜＃〜] uma [〜＃〜] は、OAuth = 2.0、「きめの細かい」、M：Nリソースの共有のサポートを追加します。簡単に言えば、次のようなシナリオが可能になります。

「アリスは猫の写真のフォルダをボブと共有しています。」

MA spec 自体は、この世界の仕様がそうであるように、うーん...言葉の多いホルマールのバケットロードのようなものです。でも、絞ってジュースになると、いきなり実はかなり親しみやすい感じになってくると思います。私が言う「トリック」の根底にあるコアは、次のような考えにあります。

"ASの責任である必要があります（アクセスを保護し、個々の権限を管理するため）が、不透明で機能しますRSによって提供されるリソースポインタ（したがって、特定のリソースのセマンティクスについて知る必要はありません）。

アイデアをもう少し拡張すると、可能な実装の「高レベル」アーキテクチャスケッチは次のようになります。

  • Authorization Serverは、1つの追加の永続テーブル「resource_sets」を格納する必要があります。各行は、「RS内のいくつかの具体的なリソースへの不透明なポインタ」を表します。 [たとえば、行は次の名前のアリスのフォルダを表すことができます： "Rly funny CATS !!! 1！1"]列は多かれ少なかれ必要があります：
    • id —[〜＃〜] as [〜＃〜]内の一意の行ID
    • owner —リソースのResource Owner[e.g. "alice"]
    • rs_id —Resource Serverによって提供されるID（「不透明なポインタ」）
    • name —[〜＃〜] rs [〜＃〜][例： "Rly funny CATS!!!1!1"]
    • max_scopes —[〜＃〜] rs [〜＃〜][例： "view"、または"view add delete"]
    • のリスト (user, scopes)ペア、Resource Ownerによって[〜＃〜] as [〜＃〜]のUIを介して動的に管理（これは、必要に応じて、実装の詳細を別のテーブルに保持できます。）[例： ("bob", "view")]
  • [〜＃〜] as [〜＃〜]は、REST APIを介してResource Serverを介して公開する必要もあります。 resource_setsエントリを作成、編集、削除できます（UMA仕様の詳細）。
  • [〜＃〜] ro [〜＃〜]がユーザーと権限を追加/削除できるUI、つまり(user, scopes)ペア、所有しているresource_sets（または少なくともいくつかのRESTエンドポイント。実装者がそれらにUIを構築できるようにするため）。
  • Resource Serverは次のマッピングを保持する必要があります：resource→rs_id;
  • 一部のClientがresourceを[〜＃〜] rs [〜＃〜]、[〜＃〜] rs [〜＃〜]はrs_idを見つけて、[〜＃〜] as [〜＃〜]何が許可されているかscopesthisrs_id、Access Tokensなどを使用した精巧なダンスを通して.

詳細については、明らかに完全な仕様を参照してください。

OAuth 2.0）のユーザー管理アクセス（UMA）プロファイル[html]

EDIT：HTML形式のUMA仕様の2.0バージョンがここにあるようです、IIUC：

ser-Managed Access（UMA）2.0 Grant for OAuth 2.0 Authorization[html]

しかし、それが実際に関連しているかどうかを確認するために、まだ調べていません。

4
akavel