ユーザーが投稿を読み書きできる非常に単純な架空のアプリケーションを考えてみましょう。
記事を読み書きできるユーザーもいれば、読むことしかできないユーザーもいます。Spring Security (3.2.1) では、2 つのロールを持つことでこれをモデル化しました。
- ROLE_WRITE: この役割は、投稿を書くためのアクセス権をユーザーに付与します。
- ROLE_READ: このロールは、投稿を読むためのアクセス権をユーザーに付与します。
これをSpringセキュリティで実装するのはかなり簡単です...
ここで、 Spring Security OAuth (バージョン 2.0.0.M3 ATM)を使用して OAuth2 プロバイダーを実装することにより、サードパーティ アプリがユーザーに代わって投稿を読み書きできるようにしたいと考えています。
承認ステップで、アプリはユーザーに代わって投稿を読み書きする権限を付与するかどうかを尋ねます。ここのユーザーは、ここでスコープを付与しています (ロールではありません)。
次に、OAuth2 コンシューマーが REST API を呼び出すと、Spring Sec OAuth は付与されたトークンを承認し、すべてのロールと付与されたスコープのみを持つユーザーを含む認証を作成します。
問題 (および問題) は、API が通常認証されたユーザーによって呼び出されるか (ロールを確認するだけ)、または OAuth2 を介して呼び出されるか (ロール + スコープを確認する) に応じて、異なるセキュリティ ロジックを記述する必要があることです。
Spring Security OAuth2 のロールとスコープの概念を「マージ」して、承認ステップ中にユーザーがアプリにロールのサブセットを付与することは可能ですか (OAuth2 認証では、付与された権限でのみこれらを報告します) ? そのようにして、サードパーティのアプリが API 呼び出しを行うと、認証の役割が付与されますか? そうすれば、OAuth2 固有のセキュリティ ロジックを記述する必要がなくなります。