方法: WIF および ACS を使用して、要求対応の ASP.NET アプリケーションにロールベースのアクセス制御 (RBAC) を実装する
TOC
目次を折りたたむ
目次を展開する

方法: WIF および ACS を使用して、要求対応の ASP.NET アプリケーションにロールベースのアクセス制御 (RBAC) を実装する

発行: 2011年4月

更新日: 2015年6月

適用対象: Azure

  • Microsoft Azure Active Directory アクセス制御 (アクセス制御サービスまたは ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

このトピックでは、WIF と ACS を使用して、要求対応の ASP.NET Web アプリケーションにロールベースのアクセス制御 (RBAC) 承認を実装する方法について説明します。

  • 目標

  • 概要

  • 手順の概要

  • 手順 1 - 単純な要求対応の ASP.NET Web アプリケーションを作成する

  • 手順 2 - ACS でロール要求を構成する

  • 手順 3 - ASP.NET Web アプリケーションにロール チェックを実装する

  • 手順 4 - カスタム ClaimsAuthenticationManager を使用して要求変換を実装する

  • 手順 5 - 作業をテストする

  • 関連項目

  • ACS を使用してロール要求を構成する。

  • ClaimsAuthenticationManager を使用してロール要求を変換する。

  • IsInRole メソッドと PrinciaplPermission 属性を使用して、ロールベースのアクセス制御チェックを実装する。

RBAC は、アプリケーションへのアクセスを制限するための幅広く採用されている方法です。ASP.NET Web アプリケーションでは、IsInRole メソッド、PrincipalPermission 属性、または ASP.NET 1.0 以降使用可能な要求を使用して、この方法が実装されます。承認のために要求を使用できるため、WIF や ACS などの新しいテクノロジを使用しながら、確立したプラクティスが維持されます。WIF ランタイムと SDK は次の場所からダウンロードできます。

  • 手順 1 - 単純な要求対応の ASP.NET Web アプリケーションを作成する

  • 手順 2 - ACS でロール要求を構成する

  • 手順 3 - ASP.NET Web アプリケーションにロール チェックを実装する

  • 手順 4 - カスタム ClaimsAuthenticationManager を使用して要求変換を実装する

  • 手順 5 - 作業をテストする

この手順では、RBAC を実装するベースラインとして使用される基本的な ASP.NET Web アプリケーションを作成する方法を示します。

  1. 「管理者として実行」オプションを指定して、Visual Studio を起動します。WIF の場合、これは必須です。

  2. 新しい空の ASP.NET Web アプリケーションを作成します。

  3. aspx Web フォームを追加してから、default.aspx などの名前を付けます。

この手順では、ACS 管理ポータルでルール グループを使用してロール要求を構成する方法を示します。詳細なチュートリアルについては、「方法:規則を使用してトークン変換ロジックを実装する」を参照してください。

  1. [証明書利用者アプリケーションの編集] ページで、[ルール グループ] セクションまでスクロール ダウンしてから、必要なグループのリンクをクリックします。それが選択されていることを確認します。

  2. [ルール グループの編集] ページで、[ルール] セクションまでスクロール ダウンしてから [ルールの追加] リンクをクリックします。

  3. [要求規則の追加] ページで、[出力方向の要求の種類] セクションまでスクロール ダウンし、[種類の選択] ボタンをクリックしてから、以下の要求の種類を選択します。

    http://schemas.microsoft.com/ws/2008/06/identity/claims/role
    
    
  4. [出力方向の要求の値] セクションで、[値の入力] をクリックしてから、テキスト ボックスに値として以下のテキストを入力します。
    ユーザー

  5. 必要に応じて、(推奨) 説明を追加してから [保存] をクリックします。

これで、すべてのトークンに追加できるユーザー ロール要求が構成されました。シナリオは要件によって異なる場合があります。より複雑なルールの構成の詳細については、「方法:規則を使用してトークン変換ロジックを実装する」を参照してください。

この手順では RBAC の実装方法を示します。

  1. Microsoft.IdentityModel アセンブリへの参照を追加します。

  2. default.aspx.cs 分離コード ファイルを開きます。

  3. 次の using 宣言を追加します。

    using System.Security.Permissions;
    using System.Threading;
    using Microsoft.IdentityModel.Claims;
    using System.Security;
    
    
  4. Page_Load イベント ハンドラーを次のセキュリティ要求で修飾します。この属性は、現在のユーザーにユーザー ロールがあるかどうかを確認します。ない場合は、例外がスローされます。

    [PrincipalPermission(SecurityAction.Demand, Role = "User")]
    
  5. 次のコードを Page_Load イベント ハンドラーの本文に追加します。これは、コードで表される要求とまったく同じです。

    PrincipalPermission p = new PrincipalPermission(null, "User");
       p.Demand();
    
    
  6. 次のコードを Page_Load イベントの本文に追加します。上記のコードとは対称的に、このコードでは例外がスローされません。代わりに、IsInRole によって、現在のユーザーに指定されたロールがあるかどうかを示すブール値が返されます。

    if (!User.IsInRole("User"))
                    throw new SecurityException("Access is denied.");
    
    
  7. 完了したコードは次のようになります。

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Web;
    using System.Web.UI;
    using System.Web.UI.WebControls;
    
    using System.Security.Permissions;
    using System.Threading;
    using Microsoft.IdentityModel.Claims;
    using System.Security;
    
    namespace WebIsInRoleACS
    {
        public partial class _default : System.Web.UI.Page
        {
            //THIS SHOULD THROW AN EXCEPTION
            [PrincipalPermission(SecurityAction.Demand, Role = "User")]
            protected void Page_Load(object sender, EventArgs e)
            {
    
                //THIS SHOULD THROW AN EXCEPTION
                PrincipalPermission p = new PrincipalPermission(null, "User");
                p.Demand();
    
                //THIS RETURNS BOOL
                if (!User.IsInRole("User"))
                    throw new SecurityException("Access is denied.");
            }
        }
    }
    
    

これは省略可能なステップです。この手順では、「手順 2 - ACS でロール要求を構成する」で説明されている ACS で実行される要求変換ルールとは対照的に、ASP.NET アプリケーションのコンテキスト内で実行される WIF パイプラインの一部である、ClaimsAuthenticationManager を使用して要求を変換する方法を示します。

  1. [クラス ライブラリ] プロジェクトを Visual Studio ソリューションに追加してから、MyClaimsTransformationModule などの名前を付けます。

  2. Microsoft.IdentityModel アセンブリへの参照を追加します。

  3. System.IdentityModel アセンブリへの参照を追加します。

  4. 新しいクラスを作成してから、ClaimsTransformationModule などの名前を付けます。

  5. 次の宣言をクラスに追加します。

    using Microsoft.IdentityModel.Claims;
    using System.Security.Principal;
    
    
  6. クラスは ClaimsAuthenticationManager 型から派生します。

  7. その [認証] メソッドをオーバーライドします (ここで、要求変換が行われます)。[認証] メソッドのコードは以下をベースにすることができます。

    if (incomingPrincipal != null && incomingPrincipal.Identity.IsAuthenticated == true)
    {
        //DECIDE ON SOME CRITERIA IF CURRENT USER DESERVES THE ROLE
        //IClaimsIdentity identity = (IClaimsIdentity)incomingPrincipal.Identity;
        ((IClaimsIdentity)incomingPrincipal.Identity).Claims.Add(
            new Claim(ClaimTypes.Role, "Admin"));
    }
    return incomingPrincipal;
    
    
  8. ASP.NET アプリケーションに切り替えて、カスタム ClaimsAuthenticationManager をその web.config で構成します。

      <microsoft.identityModel>
        <service>
          <claimsAuthenticationManager type="MyClaimsTransformationModule.ClaimsTransformationModule, MyClaimsTransformationModule" />
    
    
  9. 作成した新しいアセンブリをアプリケーションから検索できることを確認します。最も簡単な方法は、アプリケーションの bin フォルダーにそれを配置することです。

この手順では、ソリューションが機能することを検証する方法を示します。ソリューションをテストするには、F5 キーを押します。ASP.NET Web アプリケーションはデバッグ モードで実行する必要があります (ブレーク ポイントを追加して、Visual Studio 内のコードの実行を確認できます)。まず、フェデレーションに対して構成された ID プロバイダーの認証ページを表示する必要があります。認証が完了したら、Default.aspx ページに再度リダイレクトする必要があります。その場合、例外はスローされません。これは、ユーザー ロールのセキュリティ要求がすべて満たされていることを意味します。

表示:
© 2016 Microsoft