委任認証での範囲の管理
アプリケーションによるユーザーアカウントへのアクセスを制限するには、委任認証で範囲を使用します。範囲は、OAuth アクセストークンによって公開される可能性のあるリソースサーバー内のデータに対して追加のアクセス保護レイヤーを提供する文字列値です。
範囲名 (文字列値) をリソースサーバー内のデータとペアにしてから、中央認証サーバーとサービスプロバイダに範囲を登録します。サービスプロバイダは、リソースサーバーからのデータをリクエストするとき、有効なアクセストークンを提示し、リソースサーバー内のデータに関連付けられている範囲に対する承認を受けていなければなりません。
次のプロセスは、範囲がどのように機能するかを示しています。
1. ユーザーがサービスプロバイダにログインすると、ユーザーが IdP で認証されたときに、中央認証サーバーがユーザーログインセッションを認証します
2. 次に、中央認証サーバーがユーザーに対して権限承認ページを表示します。
権限承認ページには、サービスプロバイダで使用可能な範囲に関連付けられているリソースがリストされます。
3. ユーザーは、サービスプロバイダがリソースサーバー内の一部のデータにアクセスできるか、すべてのデータにアクセスできるかを決定します。
4. 承認された場合、中央認証サーバーはサービスプロバイダにアクセストークンを提供し、適切な範囲に対する権限承認を記録します。
5. サービスプロバイダは、リソースサーバーに対して呼び出しを行い、保護されているデータをリクエストするとき、アクセストークンを送信します。
6. リソースサーバーは、中央認証サーバーでアクセストークンを検証します。それが有効である場合に、保護されているリソースとペアになっている範囲に対するサービスプロバイダの承認をユーザーが付与したことを認証サーバーが確認すると、リソースサーバーがデータへのアクセスを付与します。
SSO フレームワーク内の少なくとも 3 つのアプリケーションに範囲を登録しなければなりません。その順序は次のとおりです。
1. 2 つのアプリケーション間の信頼関係を管理する中央認証サーバー (PingFederate)
中央認証サーバー管理者は、中央認証サーバーに登録されている範囲を確認し、リソースサーバーおよびサービスプロバイダアプリケーションの管理者と範囲の登録を調整しなければなりません。
PingFederate での範囲の登録については、PingFederate ドキュメンテーションを参照してください。
2. データが存在するリソースサーバー
リソースサーバーに範囲を作成する製品管理者と調整しなければなりません。
3. データをリクエストするサービスプロバイダ
必要に応じて、中央認証サーバーとリソースサーバーに登録されている範囲のサブセットの登録を選択できます。製品管理者またはアプリケーション開発者と連携して、使用可能にする必要のある範囲をサービスプロバイダに登録します。
 |
アプリケーションに登録されている範囲名は、中央認証サーバーに登録されている範囲と一致していなければなりません。一致していない場合、アプリケーションが中央認証サーバーを介して認証をルーティングすると、管理者アカウントを含むユーザーのロックアウトが発生する可能性があります。アプリケーション内の範囲にスペルミスがある場合 (これには大文字と小文字の区別が含まれる)、またはこれが中央認証サーバーに登録されていない場合、管理者がサインインを試みるときに中央認証サーバーによって認証されない可能性があります。サービスプロバイダに登録されている範囲が認証サーバーに存在しない場合、ユーザーはログインできず、これには管理者アカウントも含まれます。
この問題を解決するには、サービスプロバイダ管理者がログインできるように、スペルミスまたは追加の範囲を認証サーバーに追加します。次に、問題のある範囲をサービスプロバイダから除去し、認証サーバーから範囲を削除します。
|
最良事例とセキュリティに関する考慮事項
◦ SSO 展開内の範囲に対して使用ポリシーを確立する際、組織のセキュリティ担当者に相談してください。交換されるデータのセキュリティを向上させるために、範囲が登録または設定されている展開内の各アプリケーションで実行できる手順がいくつかあります。たとえば、リソースサーバー内では、複数の範囲を指定して、個別のデータセットを管理し、より正確な制御を行うことができます。
◦ 範囲を管理するための高度なセキュリティコンフィギュレーションについては、PingFederate 製品ドキュメントを参照してください。たとえば、範囲が個別のアクセストークンに関連付けられるように設定します。
◦ 範囲のセキュリティ保護については、OAuth 業界の最良事例を参照してください。詳細については、「OAuth 2.0 の脅威モデルとセキュリティ考慮事項」を参照してください。