要求対応の Web アプリケーションおよびサービスにおける承認
更新日: 2015 年 6 月 19 日
適用先:Azure
適用対象
Microsoft Azure Active Directory アクセス制御 (アクセス制御サービスまたは ACS)
Windows® Identity Foundation (WIF)
ASP.NET
Windows Communication Foundation (WCF)
まとめ
証明書利用者アプリケーションでは、承認によって、認証済み ID がアクセスできるリソースと、そのリソースで実行できる操作が決まります。 承認が不適切だったり弱かったりすると、それは情報漏えいとデータの改ざんにつながります。 このトピックでは、ACS と WIF を使用して要求対応 ASP.NET Web アプリケーションとサービスの承認を実装するために使用できる方法について説明します。
目標
要求を使用する承認方法をリストする。
方法ごとにデザインの概要を示す。
各方法の利点と欠点を示す。
概要
.NET Framework は、最初のバージョンから柔軟な承認実装機構を提供してきました。 このメカニズムは、IPrincipal および IIentity という 2 つの単純なインターフェイスに基づいています。 IIentity の具体的な実装は認証済みユーザーを表します。 たとえば、 WindowsIdentity 実装は Active Directory によって認証されたユーザーを表し、 GenericIdentity はカスタム認証によって認証されたユーザーを表します。 IPrincipal の具体的な実装は、ロール ストアに応じて、ロールを使用して権限を確認する場合に役立ちます。 たとえば、WindowsPrincipal は、WindowsIdentity で、Active Directory グループのメンバーシップがないかどうかをチェックします。 この確認は、IPrincipal インターフェイスで IsInRole メソッドを呼び出すことで実行されます。 ロールに基づいたアクセス チェックは、ロール ベースのアクセス制御 (RBAC) と呼ばれます。 RBAC については、このトピックの「ロールベースのアクセス制御」セクションで説明します。 ロールに関する情報をクレームに含めると、使い慣れたロール ベースの承認機構をサポートできます。
また、要求は、ロールより豊富な認証決定を可能にするために使用できます。 要求は、年齢、郵便番号、靴のサイズなど、ほとんどすべてのものをベースにすることができます。 任意の要求に基づくアクセス確認のことを、要求ベースのアクセス制御 (CBAC) または要求ベースの承認といいます。 要求ベースの承認については、このトピックの「要求ベースのアクセス制御」セクションで説明します。
承認チェックは、ACS 側ではなくアプリケーション側で実行されます。 ACS は、アプリケーションにクレームを送信するトークンを発行するセキュリティ トークン サービス (STS) として機能します。 トークンは、ID プロバイダーによる要求と、必要に応じて ACS 自体によって、そのルール エンジンを使用して強化されます。 アプリケーションは要求を含むトークンを受け取ると、トークンを解析して、関連要求を抽出し、RBAC または要求ベースの方法を使用して承認を決定できます。 WIF はトークンを解析し、それを使いやすいアプリケーション プログラミング インターフェイス (API) を介した承認決定で使用できるようにするために使用されます。 WIF の詳細については、 WIF SDK (https://go.microsoft.com/fwlink/?LinkID=187481) を参照してください。 要求対応のアプリケーションとサービスでの承認について検討する際には、以下の図を考慮してください。 認証に成功すると、ID プロバイダーがトークン (図の IdP トークン) を生成することに注意してください。 IdP トークンは、ACS ルール エンジンによって変換できます。 ACS は、ID プロバイダーが発行するトークンに含まれる要求を追加、削除、または変更できます。 最後に、ACS によって発行されたトークンがアプリケーションに送信され、WIF によって処理されます。 アクセス確認は、RBAC または CBAC 方法を使用して、WIF で行われます。
.gif "ACS v2 WIF Authorization")
ロールベースのアクセス制御
RBAC による承認では、ユーザーのアクセス許可は、ユーザー ロールに基づいてアプリケーションによって管理および適用されます。 アクションの実行に必要なロールがユーザーにある場合、アクセスは許可され、それ以外の場合は拒否されます。
IPrincipal.IsInRole メソッド
要求対応のアプリケーションで RBAC 方法を実装する場合は、要求非対応のアプリケーションの場合と同じように、IPrinicpal インターフェイスの IsInRole() メソッドを使用します。 以下のように、IsInRole() メソッドを使用する方法はいくつかあります。
IPrincipal.IsInRole(“Administrator”) を明示的に呼び出す。 この場合、結果はブール値になります。 これを条件付きステートメントで使用します。 これはコード内のすべての場所で任意に使用できます。
セキュリティ要求 PrincipalPermission.Demand() を使用する。 この場合、要求が満たされないと、結果は例外になります。 これは例外処理の方針に適合している必要があります。 パフォーマンスを考えると、ブール値の削除の場合よりも例外のスローの場合の方がはるかに高くなります。 これはコード内の任意の場所で使用できます。
宣言型属性 [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)] を使用する。 この方法は、メソッドの修飾に使用されるため宣言と呼ばれます。 メソッドの実装内のコード ブロックで使用することはできません。 要求が満たされない場合、結果は例外になります。 これが例外処理の方針に適合していることを確認する必要があります。
URL 承認を使用し、web.configの <authorization> セクションを使用します。この方法は、URL レベルで承認を管理する場合に適しています。 これは、前に説明した方法の中では最も大雑把です。 この方法の利点は、構成ファイルに変更が行われるため、コードをコンパイルしなくても変更を利用できるということです。
クレームとしてのロールの表現
IsInRole() メソッドを呼び出すと、現在のユーザーにそのロールがあるかどうかが確認されます。 クレーム対応アプリケーションでは、ロールは、トークンで使用できるロール クレームの種類によって表されます。 ロール クレームの種類は、次の URI を使用して表されます。
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
ロール クレームの種類でトークンを強化する方法は複数あります。
ACS ルール エンジンの使用— この場合は、ACS 管理ポータルまたは ACS 管理サービスを使用して規則を作成し、特定のロールタイプのクレームを生成する要求変換ルールを作成します。 ルールとトークン変換の詳細については、「 ルール グループとルール」および 「 方法: ルールを使用してトークン変換ロジックを実装する」を参照してください。
ClaimsAuthenticationManager を使用して、任意の要求をロールの種類の要求に変換する — ClaimsAuthenticationManager は WIF の一部として提供されるコンポーネントです。 このコンポーネントは、トークンを調べ、クレームを追加、変更、または削除することでそれを変換し、アプリケーションの起動時に要求を受け取れるようにします。 ClaimsAuthenticationManager を使用して要求を変換する方法の詳細については、「方法: WIF と ACS を使用してクレーム対応 ASP.NET アプリケーションにロール ベースのAccess Control (RBAC) を実装する」を参照してください。
samlSecurityTokenRequirement 構成セクションを使用して、任意の要求をロールの種類にマップする — 要求変換が構成のみを使用して行われ、コーディングが必要ではない場合の宣言型方法。
要求ベースのアクセス制御
CBAC は、アクセスを許可または拒否する承認決定が、決定を行うために要求で使用可能なデータを使用する任意のロジックに基づく場合の承認方法です。 RBAC の場合は、使用される唯一のクレームがロール タイプのクレームでした。 ロール タイプのクレームは、ユーザーが特定のロールに所属するかどうかを確認するときに使用されます。 クレーム ベースの承認を使用した承認決定のプロセスを説明するために、次の手順について考えてみましょう。
アプリケーションは要求を受け取ります。
アプリケーションは着信要求を抽出します。
アプリケーションは、クレームを決定ロジック機構に渡します。 インメモリ コードや Web サービスの呼び出し、データベースに対するクエリを使用できます。または、高度なルール エンジンを呼び出すこともできます。
決定機構では、クレームに基づいて結果が計算されます。
結果が true の場合はアクセスが許可され、false の場合は拒否されます。 たとえば、ユーザーが 21 歳以上で、ワシントン州に住んでおり、Windows Live ID (Microsoft アカウント) によって認証されたというルールが考えられます。
ACS は、クレームを保持するトークンを発行する STS として機能します。 ACS ルール エンジンを使用して、発行する要求 (要求の種類と値の両方) を制御できます。 ACS ルール エンジンの詳細については、「 ルール グループとルール」および 「 方法: ルールを使用してトークン変換ロジックを実装する」を参照してください。 ClaimsAuthorizationManager は、要求対応アプリケーションでの CBAC の実装において重要になります。 ClaimsAuthorizationManager は WIF の一部として提供されるコンポーネントです。 ClaimsAuthorizationManager を使用すると、着信要求を受け取り、任意のロジックを実装して、受信クレームに基づいて承認決定を行うことができます。 これは、承認決定を外部化して、アプリケーション コードから分離できる機能拡張ポイントでもあります。 これは、承認ロジックを変更する必要があるときに重要になります。 この状況で ClaimsAuthorizationManager を使用してもアプリケーションの整合性には影響しないため、変更によってアプリケーション エラーが発生する可能性は少なくなります。 ClaimsAuthorizationManager を使用してクレーム ベースのアクセス制御を実装する方法の詳細については、「方法: WIF と ACS を使用してクレーム対応 ASP.NET アプリケーションにクレーム承認を実装する」を参照してください。