セールス: 1-800-867-1380

Azure AD を使用してサインオンを Web アプリケーションに追加

更新日: 2014年5月

noteメモ
このサンプルは有効期限が切れています。テクノロジ、メソッド、またはインターフェイスの命令、あるいはこれらがすべて新しい機能に置き換えられています。類似したアプリケーションを構築する更新済みのサンプルについては、「WebApp-OpenIDConnect-DotNet」を参照してください。

.

このチュートリアルでは、Azure AD を使用して ASP.NET アプリケーションで Web シングル サインオンを実装する方法について説明します。ここでは、Azure サブスクリプションに関連付けられているディレクトリのテナントを利用することに焦点を当てます。これが、組織にとって最適な基幹業務 (LoB) アプリケーションの ID プロバイダーであることは明らかだからです。

Web シングル サインオン ソリューションでは、通常、認証機能を外部エンティティに外注するように Web アプリケーションを構成する必要があります (この外部エンティティは、一般的には ID プロバイダー (IdP) と呼ばれます)。具体的に言うと、認証されていない要求が SAML-P、WS-Federation、OpenID Connect などのサインオン プロトコルに従って IdP にリダイレクトされるように、アプリケーションが構成されるということです。

認証機関 (つまり IdP) は認証を処理し、通常、Web アプリケーションは既にプロビジョニング プロセスによって認識されている必要があります。正常に認証が行われると、ブラウザーは、受信ユーザーに関する情報が記録されているセキュリティ トークンと共に Web アプリにリダイレクトされます。アプリケーションは、通常、ID 対応のミドルウェアを介してそのトークンを検証し、チェックが成功したら、ユーザーは認証済みと見なされ、サインインします。

この概要は、Azure AD にも適用されます。このドキュメントでは、Web サインオン プロトコルを使用できるように、.NET Framework 4.5 で Visual Studio 2012 と Windows Identity Foundation (WIF) のクラスを使用して、MVC 4 アプリケーションを構成する方法について説明します。また、Azure AD テナントで同じアプリケーションをプロビジョニングする方法と、アプリケーションのサインオン設定を構成してそのテナントに接続する方法についても取り上げます。そして、チュートリアルの終了時には、組織のシングル サインオン用に完全に構成された機能的な Web アプリケーションが完成します。

このチュートリアルの目的は、Azure AD のしくみをわかりやすく示すことです。それには、ここで説明する簡略化されたソリューションを、異なる角度から整理する必要があります。このドキュメントでは、作業サンプルを作成する具体的な手順のほか、Azure AD に関する理解を深め、その機能をここで説明する特定のシナリオ以外で利用する方法を把握するうえで役に立つアーティファクトや概念についても紹介します。四角で囲まれた「メモ」として示されている追加のセクションは、必ずしもチュートリアルの実行に必要ではありませんが、独自のソリューションで Azure AD を使用したいと考えている方は、この部分もお読みになることをお勧めします。

このドキュメントのこのチュートリアル部分は、以下のセクションで構成されています。

  • 前提条件: チュートリアルを完了するために満たす必要があるすべての要件を示します。

  • ソリューション アーキテクチャ: LoB (基幹業務) アプリケーションの Web SSO ソリューションの概要を示します。SSO を発生させる機能コンポーネントについて確認し、ドキュメントの説明に従って具体化するワイヤーフレームをセットアップします。

  • Azure AD のディレクトリ テナントの操作: Azure AD テナントと、このシナリオにかかわる機能を紹介します。また、Azure 管理ポータルの Active Directory セクションの主な要素についても簡単に説明します。

  • Azure AD へのアプリケーションの接続: MVC アプリケーションで Web シングル サインオンを有効にするための Visual Studio 2012 用 ID およびアクセス ツールを使用し、認証設定を、選択した特定の Azure AD テナントに関連付ける方法について説明します。

  • 高度なトピック: 基本機能を越えて、重要なトピックをさらに深く掘り下げ、アプリケーションを次のレベルに進める際に必要になる可能性がある他のタスクをいくつか取り上げます。

このチュートリアルを完了するには、次の前提条件を満たす必要があります。

ご質問がある場合またはサポートが必要な場合は、「Preparing for Azure AD Solutions and Scenarios」を参照してください。

シングル テナント アプリケーションのアーキテクチャ

このチュートリアルで重点的に取り組むシナリオ: 開発者は Web アプリケーションをクラウドに展開し、Azure Active Directory テナントのユーザーにのみアクセスを許可したいと考えています。これを実現するには、次の作業を行う必要があります。

  1. Azure AD テナントで Web アプリを登録する。アプリが認識されたら、ユーザーの認証要求が Azure AD によって受け入れられます。

  2. アプリの前に何か追加する。この目的を次に示します。

    1. 認証されていない要求をブロックし、ユーザー認証用の適切な Azure AD テナントにリダイレクトできるようにする

    2. Azure AD で認証されているユーザーが認識され、アクセスが許可されるようにする

最初の手順は、Azure 管理ポータルを使って実装します。新しい Azure AD テナントを Azure サブスクリプション内にプロビジョニングする方法、および Azure AD 管理ポータルの機能を操作してアプリケーションを登録する方法について学習します。

手順 2. を実装するには、組織の枠を越えた (インターネットを含む) 認証操作を許可することを目的とした、さまざまなハイレベル プロトコルを使用します。

.NET プラットフォームでは、この 2 番目の手順で、.NET が追加設定なしで提供するクラスを、要求ベースの ID およびフェデレーション認証を操作するために構成します。このクラスはまとめて Windows Identity Foundation (WIF) と呼ばれ、この WIF に含まれる HTTP モジュールと構成設定を使用すると、手順 2. で説明したリダイレクトおよび認証タスクを実行するインターセプション レイヤーを追加できます。Visual Studio 2012 には、WIF を使用するように Web アプリを自動構成するのに役立つツールが用意されています。このように構成することで、WS-Federation などの特定の Web SSO プロトコルをサポートする外部機関に認証が外注されます。このチュートリアルでは、こうしたツールを Azure AD で使用する方法について説明します。

Azure Active Directory は、Office 365 や Windows Intune などの Microsoft 製品の ID バックボーンを提供するサービスです。こうしたサービスにサブスクライブし、そのサービスに関連付けられているディレクトリ テナントを再利用する場合は、新しい Azure サブスクリプションを作成し、[ユーザーの追加] 機能を使用してそのテナントから管理者を追加します。このチュートリアルでは、このプロセスについては詳しく説明しません。

すべてのサブスクリプションに、Azure AD テナントと関連付けられたディレクトリがあります。自動生成されたテナントの場合、ディレクトリの名前は "既定のディレクトリ" になりますが、この名前は変更できます。チュートリアルのこのパートでは、ユーザーをディレクトリに追加してから、アプリケーションを追加します。

作成されたディレクトリ テナントは、クラウド内のユーザーと資格情報を格納するように構成されます。ディレクトリ テナントを、Windows Server Active Directory のオンプレミスの展開に統合する方法の詳細については、「ディレクトリの統合」を参照してください。

ご質問がある場合またはサポートが必要な場合は、「Preparing for Azure AD Solutions and Scenarios」を参照してください。

Azure AD シナリオとソリューション (およびコード サンプルとサンプル アプリケーション) では、Azure Active Directory ドメインのユーザー アカウントが必要です。Hotmail.com、Live.com、Outlook.com アカウントなどの Microsoft アカウントでアプリケーションにサインインしようとすると、サインインは失敗します。User@Contoso.onmicrosoft.com アカウントなど、Active Directory ドメインのアカウントを持つユーザーが既にいる場合は、そのアカウントを使用して、このシナリオにサインインできます。それ以外の場合は、新しいユーザーを作成する必要があります。

  1. Microsoft Azure 管理ポータル (https://manage.WindowsAzure.com) に移動してサインインし、[Active Directory] をクリックします。(トラブルシューティングのヒント:"Active Directory" 項目が見つからないか、使用できません)

  2. ディレクトリの名前が "既定のディレクトリ" の場合は、"ContosoEngineering" などのディレクトリを追加します。ディレクトリを追加するには、[Active Directory] ページの下部にある [追加] をクリックし、指示に従って新しいディレクトリを追加します。

  3. ディレクトリをダブルクリックし、[ドメイン] をクリックします。ユーザー アカウントを作成するときは、ページに表示されるドメイン名を使用します。たとえば、ドメインが ContosoEngineering@onmicrosoft.com の場合は、そのドメインにユーザー名を作成します (Test@ContosoEngineering@onmicrosoft.com など)。

  4. ユーザー アカウントをドメインに作成するには、[ユーザー] をクリックします ([ユーザー] タブが表示されない場合は、ディレクトリ名をダブルクリックします。ディレクトリ固有の各ページに [ユーザー] タブが表示されます)。ページの下部にある [ユーザーの追加] をクリックします。

  5. [組織内の新しいユーザー] を選択します。新しいドメインにユーザー (Test@ContosoEngineering.onmicrosoft.com など) を追加し、ページの下部にあるチェックマークをクリックします。

    ユーザー名およびドメインを入力する
  6. [ユーザー プロファイル] ページで、組織内でのロールをユーザーに割り当てます。テストの目的で、少なくとも 1 人のユーザーにグローバル管理者ロールを割り当て、さらにもう 1 人のユーザーにユーザー ロールを割り当てることをお勧めします。

    ユーザー ロールを入力する

最後の手順で、Azure 管理ポータルによって一時パスワードが生成されます。このパスワードは、ユーザーが初めてサインインするときに使用します。初回サインインが完了したら、この一時パスワードは変更する必要があります。一時パスワードは、シナリオのテストで必要になるため必ず保存しておいてください。

この時点で、有効なユーザーが含まれるディレクトリ テナントがあります。これを、Web シングル サインオン シナリオで認証機関に提供します。

一時パスワード

  1. まず始めに、アプリケーションに関する作業を行います。Visual Studio を開き、[新しいプロジェクト] をクリックして、[ASP.NET MVC 4 Web アプリケーション] を選択します。[新しい ASP.NET MVC 4 プロジェクト] ウィンドウで [イントラネット アプリケーション] を選択し、ビュー エンジンが [Razor] に設定されていることを確認して、[OK] をクリックします。このチュートリアルでは、プロジェクト名として [経費明細書] を使用します。

    noteメモ
    このチュートリアルでは、Visual Studio インストールが既定の設定で構成されていることを前提としています。(開発時に Web アプリケーションがホストされる場所などの) 基本構成をいくつか変更した場合は、それに合わせて手順も調整する必要があります。



    Visual Studio でのプロジェクトの新規作成

    このチュートリアルの手順は、ASP.NET 要求処理パイプラインを大きく変更するロジックがない限り、既存の VS 2012 Web アプリケーション、MVC、または Web フォームに適用できます。ただし、便宜上、ここでは新しいプロジェクトをゼロから作成します。

    noteメモ
    このチュートリアルでは、.NET ソリューションをセットアップする方法を詳しく説明しますが、他のプラットフォームやプログラミング スタックを対象にしても同じ結果を得られます。Azure AD では Web サインオン機能にオープン プロトコルを採用しており、主なプラットフォームはすべて、こうしたプロトコルをサポートするライブラリおよびツールを備えています。あらゆるスタックの構文や演習に対応するためには細かな手順を調整する必要はありますが、高レベルなタスクの下位区分は全体的に適用されます。

    Visual Studio によって新しい MVC プロジェクトが作成されます。このプロジェクトは、IIS Express で実行されるように既に構成されています。Web サインオンの追加方法については既定の設定のままで説明できるため、このプロジェクトには機能を追加しません。唯一の例外が、アプリケーションによって使用されるエンドポイントです。Visual Studio では、アプリケーションが HTTP 経由でコンテンツを提供するように既定で構成されます。ただし、通信が無防備になり、攻撃者によって Cookie やトークンが盗まれる可能性があることを考えると、HTTP は安全なセッション確立には適していません。Azure では HTTPS の使用が厳格に強制されているわけではないため、開発フェーズでは必須ではありませんが、これを使用することをお勧めします。

  2. IIS Express により、Visual Studio から直接 HTTPS を簡単に有効にできます。ソリューション エクスプローラーでプロジェクトを選択し、[プロパティ] ウィンドウで [SSL 有効][True] に切り替えます。

    以前は空だった SSL URL に新しいアドレスが設定されます。それを選択し、クリップボードにコピーします。



    SSL URL のコピー

  3. ここで、デバッグ中は常に HTTPS エンドポイントを使用する必要があることを Visual Studio に認識させる必要があります。ソリューション エクスプローラーに戻り、プロジェクトを右クリックして、[プロパティ] を選択します。左側で [Web] タブを選択し、[IIS Web サーバーの使用] オプションまで下にスクロールして、[プロジェクトの URL] フィールドに HTTPS URL を貼り付けます。設定を保存し (Ctrl + S)、[プロパティ] タブを閉じます。



    プロジェクト URL の変更

    この時点で、サインオンで Azure AD を利用するよう構成するのに適したアプリケーションが作成されています。次の手順では、この特定のアプリについて Azure AD テナントに認識させます。

  1. Visual Studio を最小化して、Azure 管理ポータルの [Active Directory] タブに戻ります。ここまでのチュートリアルでは、ユーザー領域で作業を行ってきました。ここからはアプリケーション領域で作業します。ページの上部にある [アプリケーション] をクリックします。



    統合されたアプリケーション

    この領域には、ディレクトリ テナントに登録されたアプリケーションの一覧が表示されます。次の場合に、アプリケーションがテナントに登録されます。

    • アプリケーションのディレクトリに、そのアプリケーションの主なコーディネートについて記述するエントリがある: 名前、関連付けられたエンドポイントなど。詳細は後半で説明します。

    • アプリケーション自体に、現在のディレクトリ テナントで操作を実行する許可が付与されている: サインオン トークンの要求から、ディレクトリに対するクエリの実行までの操作。これについても、後で詳しく説明します。

    Important重要
    未登録のアプリケーションは、セキュリティ上の理由および実務上の考慮事項から Azure AD を利用することはできません。たとえば、許可されるのは管理者が承認したアプリのみです (セキュリティ上の理由)。また、Azure AD を操作するには、特定のオープン プロトコルを使用する必要があり、これには、アプリについて記述する主要パラメーターに関する知識が必要です (実務上の考慮事項)。

  2. このディレクトリ テナントはゼロから作成したばかりなので、登録済みアプリケーションの一覧はまだ空です。実際、最初のエントリは、Visual Studio で作成したアプリケーションのエントリになります。このセクションでは、これをアプリとして登録する方法について説明します。

    これは最初のアプリなので、画面の下部にある Azure 管理ポータルのコマンド バーで [追加] ボタンをクリックして、処理を開始します。すると、以下の画面が表示されます。



    アプリ情報の指定

    Azure 管理ポータルを使用して 1 つのアプリを登録するプロセスは、従来のウィザードとして構成されています。このウィザードの以降に続く画面では、ユーザーが選択した内容に従って必要な情報の詳細が表示されます。

    上記の図は、最初に表示される画面です。提供されるオプションは簡単です。

    • 表示名: ここで入力したテキストは人が判読できるモニカーとして使用され、ユーザー (登録済みアプリ一覧を管理する管理者、またはアプリへのディレクトリ アクセスの付与を決める顧客) がアプリに対して何らかの操作を行う必要がある場合に必ず、そのアプリを参照します。詳細については、「Azure AD でのマルチテナント Web アプリケーションの開発」を参照してください。

    • アクセスの種類: この一連のラジオ ボタンを使用すると、アプリがディレクトリ テナントに対して実行できる操作を指定できます。このチュートリアルの目的は、単にアプリで Web サインオンを構成することです。したがって、[シングル サインオン] を選択するのが適切です。

      noteメモ
      アプリケーション権限のトピックについては他のドキュメントで深く掘り下げますが、ここでは背後で行われている処理について把握できるようにその背景の理念について簡単に触れます。

      Azure AD では、ServicePrincipal と呼ばれるエンティティを使用してアプリケーションを表します。その名前が示すように、これはより使い慣れたユーザー プリンシパルと似ていますが、その目的はアプリケーションの記述で使用することです。

      アプリケーションの登録動作とは、実際のところ、アプリケーションの ServicePrincipal を、そのアプリがアクセスすることになっているディレクトリ インスタンスのテナントに作成することなのです。

      指定したアプリケーションに許可するアクセス レベルは、対応する ServicePrincipal が属するロールによって決まります。このチュートリアルでは必要ありませんが、読み取り/書き込みアクセス レベルを選択した場合は、詳細な情報 (こうしたクエリを実行するときに認証に使用するキーなど) を収集するための追加のステップがいくつか、登録フローによって追加されます。この場合は、キーも、アプリケーションを記述する ServicePrincipal に格納されます。この詳細については、「Graph API を使用した Azure AD のクエリ」を参照してください。

      アプリケーション登録プロセスで許可された権限は、ディレクトリ自体にアクセスするときにのみ有効です。これにより、SQL Azure データベース、管理ポータル セクションなど、他の Azure リソースのアクセス ポリシーは決定されません。

  3. アプリケーションの名前を入力し、アクセスの種類としてシングル サインオンを選択したら、右下隅にある矢印をクリックして、次の画面に移動します。

    アプリのプロパティ この画面で、Azure 管理ポータルは、サービスに必要な重要なコーディネートを収集して、サインイン プロトコル フローを進めます。入力する必要がある情報を次に示します。

    • アプリの URL: このパラメーターは、Web アプリケーションの address を表します。この例では、IIS Express によってアプリケーションに割り当てられた https://localhost:44341/ に対応します。これまでの手順にきちんと従っていたら、このアドレスはまだクリップボードにあり、貼り付ける準備ができているはずです。 入力した値が有効なのは、開発フェーズの間だけです。アプリケーションをターゲット ステージングまたは実稼働環境に展開したら、管理ポータルに戻り、アプリケーションの場所に合わせてアドレスを変更する必要があります。この方法については、このチュートリアルで後ほど説明します。

      Warning警告
      Azure AD は、ユーザーが Azure AD のページで正常に認証された後に、フローをアプリケーションにリダイレクトできるように、そのアプリケーションのアドレスを把握しておく必要があります。

      このアドレスは、必ず事前に提供しておきます。Azure AD が認証フローを任意のアドレスにリダイレクトすると、攻撃者がさらに簡単に認証フローをハイジャックしたり、トークンを盗んだりできます。アプリケーションの URL を事前に登録しておけば、アプリ用の認証トークンがアプリにのみ送信されることが保証されます。

    • アプリ ID の URI: このパラメーターは、Web アプリケーションの identifier を表します。Azure AD はサインオン時にこの値を使用して、認証要求が、(すべての登録済みアプリケーションのうち) この特定のアプリケーションへのユーザー アクセスを許可するためのものであることを判断します。こうすることで適切な設定が適用されます。

    noteメモ
    アプリ ID の URI は、ディレクトリ テナント内で一意である必要があります。この値として適切な既定値は [アプリの URL] の値ですが、この戦略では、一意制約に従うのは必ずしも簡単にいくとは限りません。IIS Express、Azure Fabric Emulator などのローカル ホスティング環境でアプリを開発すると、アドレスの範囲が制限され、複数の開発者、または開発者が同じ複数のプロジェクトによって、こうしたアドレスが再利用されることはよくあります。そこで考えられるのが、アプリの URI の値に何か追加して区別するという戦略です。

    また、次の点にも注意してください。アプリ ID の URI は URI です。そのため、アドレス指定可能なネットワーク エンドポイントに対応する必要はありません。つまり、アプリの URL とは無関係のものを選択できます。実際に、このチュートリアルでは新しいアプリケーションを操作していますが、既に独自のアプリ ID の URI を持つ可能性がある既存のアプリケーションを登録する場合があり (ここで使用するサインオン プロトコル、WS-Federation では、アプリ ID の URIrealm と呼ばれます)、その場合は、そのアプリ ID の URI を使用する場合もあります。「Azure AD でのマルチテナント Web アプリケーションの開発」では、マルチテナントによる追加制約のいくつかに焦点を当てます。

  4. アプリの URL と APP ID の URI を入力したら、右下隅にあるチェック ボックス ボタンをクリックできます。

    クイック スタート これで登録プロセスは完了です。アプリのディレクトリ テナントには独自のエントリが用意され、Azure AD はいつでも自身のために Web 認証を処理できます。

    正常に登録が行われたことを通知する画面には、サインオンで Azure AD を使用できるよう Web アプリケーションを構成するのに必要な情報が示されています。つまり、[Azure AD でのシングル サインオンの有効化] セクションには、Visual Studio に戻ったときに貼り付ける必要がある設定がいくつか含まれます。

    このページでブラウザーを開いたまま Visual Studio に切り替えて、チュートリアルの次のタスクに進みます。

Azure AD でアプリケーションの認証トークンを発行する準備ができたので、Web サインオンを有効にするための最後のステップとして、適切な認証プロトコルで要求が処理されるようにアプリケーション自体を構成します。プロトコルの適用とは、アプリケーションが Azure AD、特にディレクトリ テナントを呼び出して、アプリでの作業セッションをユーザーが開始するときにユーザー認証を行えるようにすることです。

Web サインオン プロトコルを使用するときは、認証のメカニズムの背景情報をある程度理解しておくことが重要です。詳細については、高度なセクションで説明します。

選択したプロジェクト テンプレートは MVC 4 イントラネット アプリケーションです。このテンプレートは、通常、Windows 統合認証を使用して、アプリのユーザーが確実に認証されるようにします。このメカニズムはネットワーク レベルで動作します。つまり、これはイントラネットで公開されたすべてのサービスに適用されます。その際、認証ロジックをアプリケーション自体に追加する必要はありません。

アプリケーションをイントラネット外に展開する場合、たとえばクラウド アプリの場合は、ネットワーク レベルの認証を使用することはできません。この場合の認証を扱う方法として最も一般的な戦略に、ある種のミドルウェアをアプリケーションの前に追加するという方法があります。これにより、必要な認証チェックがさらに高いレベルで再作成されます。この追加のレイヤーでは、認証されていない要求の阻止、認証プロトコルの適用、アプリケーションから離れて認証するためのユーザーのリダイレクト、認証されたユーザーに関するアプリ情報の送信、セッションの管理など、一般的にアクセス制御に必要なすべてのタスクを実行します。

この戦略は、すべてのプラットフォーム、開発スタック、およびサインオン プロトコルに一貫して適用されます。ネットワーク上およびプログラミング モデルで行われることは変わりますが、一般的なパターンは概ね同じままです。

このチュートリアルでは、WS-Federation プロトコルを介してアプリケーションを Azure AD に接続します。このプロトコルは Web SSO を実装するための 1 つの選択肢にすぎません。もう 1 つの一般的なプロトコルとして SAML-P を選択することもできます。

.NET Framework 4.5 では、WS-Federation がネイティブでサポートされます。また、プロトコル フローの適用、認証処理、および ASP.NET アプリケーションでのセッションの処理に必要なすべてのクラスが含まれています。

まとめ:.NET 4.5 には、アプリケーションの HTTP パイプラインでインスタンス化されるように作られた一連の HttpModule が用意されています。これらのモジュールは、アプリケーションと認証機関の両方のプロトコル コーディネート (この場合は Azure AD テナント) が含まれる既知の構成セクションを参照するように設計されています。要求が入ってきたら、モジュールはその要求を調べ、必要に応じて認証プロトコルを適用します。たとえば、認証されていない要求を受け取った場合、モジュールは Azure AD テナントのコーディネートを構成から読み取り、そのコーディネートを使用して WS-Federation サインイン メッセージを作成し、そのメッセージを使用してユーザーを自動的にリダイレクトして Azure AD で認証します。

noteメモ
.NET Framework 4.5 の要求ベース ID 関連タスク専用クラスのサブセットは、Windows Identity Foundation (WIF) と呼ばれます。以前のバージョンのフレームワーク (3.5 および 4.0) を対象にしたアプリケーションが、スタンドアロン ライブラリとしてアウトバンドでリリースされた以前のバージョンの WIF (こちら からダウンロード) を利用して、このチュートリアルで説明されている手順を実装することもできます。ただし、この 2 つのバージョンは完全に互換していないうえに、異なるバージョンの Visual Studio 向けツール (2008 および 2010、こちら からダウンロード) を使用する必要があるため、手順は異なります。

Visual Studio 2012 には、ポイント アンド クリック ツールが用意されています。このツールは、WS-Federation を使用して Web サインオンするようアプリケーションを構成する際に役立ちます。ツールの UI を使用すると、信頼したい機関に関する重要な情報を認証機能に提供できます。また、このツールは、対応する構成エントリを出力します。このチュートリアルでは、ツールによってコードのほとんどが自動生成されるため、コードをほとんど記述する必要がありません。

  1. Web サインオンを実装する方法はわかったので、ID およびアクセス ツールを使用してアプリケーションを構成してみましょう。ソリューション エクスプローラーでアプリケーションのプロジェクトを右クリックし、コンテキスト メニューの [ID とアクセス] をクリックします。

    ID およびアクセス 次に示すダイアログ ボックスが表示されます。

    ID およびアクセス プロバイダー 現在表示されている [プロバイダー] タブですべての作業を行います。このチュートリアルの目的を考慮し、当面のタスクに必要ないオプションはすべて無視します。

  2. ツールには、認証を外注する際に使用できるさまざまな機関の種類が示されています。このケースでは、ビジネス ID プロバイダーを使用します。そこで、これに対応するエントリ (上から 2 番目のオプション) をクリックします。

    ID およびアクセスの構成 オプションを選択すると、対応する UI 要素が下のパネルに表示されます。これらのコントロールによって要求された情報は、前のセクションで説明したアプリケーション登録プロセスの最後に表示されたエントリと完全に一致します。入力する必要がある情報を、下から順番に次に示します。

    • アプリケーションのアプリ ID の URI (realm) を入力: 登録時に定義したアプリケーションの ID です。管理ポータルが表示されているブラウザー ウィンドウに切り替えて、対応する値を [アプリ ID の URI でコードを更新] フィールドからコピーして、ここに貼り付けます。

    • STS メタデータ ドキュメントへのパスを入力: "STS メタデータ ドキュメント" は、接続先機関のコンピューターが判読できる説明が含まれるファイルです。ツールは、これを使用して、サインオン フローに不可欠なパラメーターの値を判断します (詳細については以下を参照)。すべての Azure AD テナントが、こうしたドキュメントを、登録プロセスの最後に提供された場所で 1 つ公開しています。管理ポータルに切り替えて、対応する値をアプリ登録ページでコピーしてからツールに戻り、そのパスをこのフィールドに貼り付けます。

      noteメモ
      メタデータ ドキュメントへのパスをテキスト ボックスに貼り付けると、証明書が無効であることを示す警告が表示されます。この警告の原因はメタデータ ドキュメントが自己署名証明書で署名されていることなので、心配する必要はありません。

    [OK] を押します。ツールは、指定されたメタデータ ドキュメントにアクセスし、機関のコーディネート (サインオンに使用するエンドポイントのアドレス、認証トークンの署名を確認するときに使用する X.509 証明書、発行された認証トークンの形式とバージョンなど) を読み取ります。そして、その情報を使用して、アプリケーションを Azure AD に接続するのに必要なエントリを生成し、web.config に追加します。

次の一覧では、ツールによって web.config に追加される主なエントリについて説明します。詳細については、ドキュメントのさらに高度なセクションを参照してください。

  • system.identityModel および system.identityModel.services の <section>: 構成に必要なエントリで、ID 固有の構成設定を理解できるようにします。

  • <system.web> の <authorization> 設定: アプリへのすべての要求が認証を必要とするように、既存の ASP.NET 認証設定が自動的に変更されます。これにより、いわゆる "包括リダイレクト" 動作が実行され、(認証されていないユーザーがアプリの一部を利用できるようにするのではなく) 認証されていないすべての要求が認証機関にリダイレクトされます。これは LoB アプリケーションの既定の動作です。ユーザーは既に機関でサインインされており、多くの場合、サイレントで認証が行われます。開発者がこの動作を変更して、ケースバイケースで認証要件を提供する必要がある場合は、<authorization> 設定を適宜変更します。

  • <system.webServer/modules> の WSFederationAuthenticationModule (FAM) と SessionAuthenticationModule (SAM): このエントリは、アプリケーションの HTTP パイプラインで、認証に対して WS-Federation の使用を強制する HttpModule を追加します。FAM は、プロトコルの適用を担当するモジュールです。サインオン要求、トークン検証、およびサインアウト管理が、担当する主なフローです。SAM はセッションを処理します。具体的には、たとえば、セッション Cookie を生成および検証するほか、すべての要求にその Cookie が必ず存在するようにします。また、セッションの長さも処理します。これらの動作は、次に説明する構成要素によって決まります。

  • <system.identitymodel/identityConfiguration> セクション: この要素により、認証フェーズ中のアプリの動作が決まります。例:ValidatingIssuerNameRegistry サブ要素では、署名に使用する証明書や名前を記録することで、認証サービスを提供するための信頼された機関の一覧が格納されます。

  • <system.identitymodel.services/federationConfiguration> セクション: このセクションは、WS-Federation フローを進めるのに必要なコーディネート、たとえば、サインオン要求に使用する機関のアドレスや、要求に含めるアプリ自体の ID を提供します。

自動生成された構成はすべて、Azure AD を使用して Web サインオンする際に必要です。認証固有のコードをアプリケーション自体に書き込む必要はありません。 ユーザー ID の情報にアクセスする必要がある場合は、現在のプリンシパルで要求に対してクエリを実行することで、簡単にアクセスできます。たとえば、現在のユーザーの名前と姓にアクセスする必要があるとします。これを行うには、次のコードを使用します。認証が行われる方法について把握している必要はまったくありません。

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

.NET 4.5 以降、.NET ではすべての ID が ClaimsPrincipal で表されます。この場合、現在の ClaimsPrincipal は認証トークンの検証中に作成されました。この認証トークンは、Azure AD によって生成され、サインオン時にユーザーによって提示されたものです。

すべての ClaimsPrincipal に要求のコレクション、つまりユーザーを認証した機関によってアサートされたように現在のユーザーを記述する属性が含まれます。このチュートリアルでは、プリンシパルの要求は、Azure Active Directory によってトークンで発行されたものです。使用できる要求の一覧については、オンライン ドキュメントを参照してください。

Azure AD では、認証されたユーザーに対して固定の要求を発行します。Azure AD から発行されるすべての要求を簡単に次に示します。詳細については、ドキュメントを参照してください。

 

サンプルの値 説明

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

現在のアプリケーションに対して認証されたユーザーの、再利用も変更もできない一意のダイレクト ID

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

ディレクトリのユーザーの ID。ユーザーに関するディレクトリ クエリに役立ちます。

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

ディレクトリ テナントの ID

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

ユーザーの名前

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

ユーザーの UPN

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

ユーザーの姓

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

ユーザーを認証した機関の ID。Web サインオン プロトコルで表されます (この場合は、WS_Federation)

この時点で、アプリケーションには、Azure AD での Web サインオンを説明するために必要なものすべてが揃っていますが、まだ完全ではありません。追加する必要がある重要な機能が少なくともあと 2 つあります。機関のプロトコル コーディネートの自動更新とサインアウトのサポートです。

次の 2 つのセクションでは、この 2 つの機能を追加する方法について詳しく説明します。これらの操作も、"アプリの実行" セクションに進む前に行うことをお勧めします。

現在使用されている Web サインオン プロトコルには、通常、分散サインアウト操作のプロビジョニングが含まれます。このフローでは、現在のアプリケーションは、現在のユーザーのセッションを取り消すだけでなく、機関にアクセスして、その機関によって確立された可能性がある他のすべてのアプリケーション セッションにサインアウト コマンドを反映させる必要があることを知らせます。WS-Federation も例外ではなく、WIF のオブジェクト モデルで完全に実装された完全なサインアウト フローを提供します。このセクションでは、分散サインアウト機能をサンプル アプリケーションに追加する方法について説明します。つまり、ユーザー エクスペリエンスに適切なフックアップを提供して、サインアウト フローをトリガーし、Azure AD テナントに設定する適切なサインアウト メッセージを生成します。

  1. まず、サインアウト コントローラーをアプリケーションに追加します。これを簡単に行うには、ソリューション エクスプローラーのプロジェクトで [コントローラー] フォルダーを特定し、そのフォルダーを右クリックして [追加] を選択し、[コントローラー] をクリックします。そのコントローラーに SignOutController という名前を付けて、[空の MVC コントローラー] (通常は既定の設定) を選択し、[追加] をクリックします。

  2. 新しいアセンブリへの参照を追加する必要があるため、そのアセンブリのクラスを使用する必要があります。再度ソリューション エクスプローラー[参照] ノードを右クリックし、[参照の追加] を選択します。次に、[アセンブリの検索] フィールドに「system.identitymodel.services」と入力し、対応するアセンブリをメイン リストから選択します。[OK] を押します。

  3. 新しく作成した SignOutController.cs ファイルに戻ります。using ディレクティブに次のエントリを追加します。

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    ここで、SignOutController クラスの実装を次のように変更します。

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    コードが行っていることを簡単に説明します。

    • 最初のメソッド Index() は、https://localhost:44341/SignOut という形式で要求を提供します。これは、このチュートリアルの後の手順で追加するビューのアドレスです。その目的はサインアウトの成功を知らせることです。この情報は、次のメソッドで使用します。

    • SignOut() メソッドは、https://localhost:44341/SignOut/SignOut という形式で要求を提供します。このメソッドには主なサインアウト ロジックが含まれます。

    • 先頭行は、WIF が web.config で WS-Federation 設定を追跡するために使用するオブジェクトを取得します。これは、現在のアプリケーションに合ったサインアウト メッセージを作成するときに必要になります。

      noteメモ
      通常は、ハードコード値ではなく構成値を参照すること、またはカスタム リポジトリから構成値を使用することをお勧めします。これにより、コードが残りのプロトコル設定に合わせて調整されるからです。展開の前後に構成ファイルで設定が何回変更されても、ロジックは動作し続けます。

    • 2 行目と 3 行目では、サインアウト フローの最後に機関が使用する戻り先アドレスを作成します。このアドレスは、前に説明したビューを指定する必要があります。したがって、コードは現在の要求の URL を取得し、末尾の "SignOut" を削除します。要求からアドレスを引き出すことで、アドレスがクライアントに対して適切に解決することが保証されます。一方、ホスティング レイヤーからアドレスを取得すると、ロード バランサーを使用するときに、内部ポートに関する問題が発生する可能性があります。

    • 4 行目は、WIF を使用して WS-Federation サインアウト メッセージを作成し、機関の URL と前の行で定義した戻り先アドレスに渡します。メッセージはネットワーク フォームで直接簡単に作成できますが、WIF オブジェクト モデルを使用すると、より簡潔なコードを記述し、構文の詳細のほとんどを無視できるようになります。サインアウト メッセージの外観を確認するには、後のセクションでアプリを実行するときに HTTP トレースを取得するか、こちらの仕様を確認してください。

    • 4 行目では、<wsFederation> 構成要素の realm 属性で記録されているように、現在のアプリの ID をメッセージに追加します。

    • 5 行目では、SAM (自動生成された構成の説明で前述) を使用してローカル セッションをクリーンアップします。これには、サインオン時に生成されたセッション Cookie の削除と、必要と思われるすべてのローカル リソース クリーンアップが含まれます。

      noteメモ
      ここで示すサンプル アプリケーションによる処理はそれほど多くありませんが、実際のアプリケーションは、ユーザー セッション中にリソースを割り当てることがあります。この場合、SAM の SigningOut イベントと SignedOut イベントを利用するには、対応するイベント ハンドラーを Global.asax ファイルに追加します。これにより、セッションの終了時に処理する必要があるすべてのリソースをクリーンアップできます。

ここで使用するビューは非常にシンプルです。前述したように、このビューの目的は、サインアウト フローに対して有意義な戻り先ポイントを作成するにすぎません。

  1. ソリューション エクスプローラー[ビュー] ノードを右クリックし、[サインアウト] フォルダーを追加します。

  2. そのフォルダーでビューを追加します。それには、フォルダーを右クリックして [追加] をクリックし、[ビュー] をクリックします。新しいビュー [サインアウト] も呼び出します。プレースホルダー プレゼンテーション コードをビュー ファイル (SignOut.cshtml) に追加して、サインアウトが行われたことを示します。例:

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. 前のセクションでは、包括リダイレクトによって認証を処理するようにアプリケーションを構成しました。つまり、(予定どおりに) サインアウトが正常に行われた後にこのビューにアクセスしようとすると、再度サインインするために直ちに Azure AD にリダイレクトされます。この動作を回避するには、web.config<location> 要素を使用して、認証ポリシーの例外を 1 つ作成します。

    <system.web> 要素が最初に出現している場所を探し、そのすぐ上に次のスニペットを貼り付けます。

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    これは、認証されていないユーザーを含め、だれもが SignOut パスにアクセスできることを ASP.NET に示します。このように設定すると、正常にサインアウトが行われても、このビューをブラウザーに表示することができます。

  1. アプリにサインアウトの機能が追加されました。あとは、その機能がユーザーに表示されるようにするだけです。これを非常に簡単に行う方法があります。まず、ソリューション エクスプローラーで Views\Shared パスから _layout.cshtml を開きます。"Hello" という文字列を探して、標準の MVC 4 レイアウトの上部にログイン情報を表示するコードを特定し、ログイン セクションを次のように変更します。

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

これによりサインアウト コマンドが、ログイン ユーザーのあいさつの右側に追加されるため、どのビューからでもサインアウト アクションをトリガーできます。

ID およびアクセス ツールにより、選択した Azure AD テナントからのトークンを受け入れるようにアプリケーションを構成しました。これを行うため、アプリケーションでは、対象の Azure AD エンドポイントに接続する目的で、必要なプロトコル コーディネートが web.config にキャッシュされました。さらに、受け取ったトークンが実際に Azure AD テナントから発信されたものかどうかを検証するために、認証時に使用される重要な情報、つまり、テナントを表す発行者名と、トークンの署名の確認に使用する公開キー (X.509 証明書形式) が保存されました。

定期的に暗号化キーを更新することは一般的なセキュリティ プラクティスで、Azure AD 署名キーも例外ではありません。定期的に古いキーが廃棄され、新しいキーが、発行者の署名ロジックおよびテナントのメタデータ ドキュメントで古いキーに取って代わります。 緊急の場合は、(ほとんど) 警告なしで、キーが予定外に更新されることがあります。

アプリケーションの設定は、署名キーが展開されるたびに、それに応じてを変更する必要があります。チュートリアルのこれまでのアプローチに従うということは、ツールを再実行して新しいメタデータ ドキュメントを読み取り、web.config エントリを更新するということです。

ダウンタイムを最小限に抑えるために、自己修復ロジックをアプリケーションに直接追加することをお勧めします。これにより、プログラムによってメタデータ ドキュメントを使用し、オペレーターの介入なしでキー展開に対応できます。こうした機能を実装する方法の例を次に示します。

  1. ドキュメントで前述したように、ソリューション エクスプローラーを使用して、System.IdentityModel アセンブリへの参照を追加します。

  2. 次の using ディレクティブを Global.asax ファイルに追加します。

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. その後、次のメソッドを Global.asax ファイルに追加します。

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    このロジックは非常にシンプルです。ValidatingIssuerNameRegistry は ID およびアクセス ツールによって使用されるクラスで、信頼されている機関、およびその機関が発行するトークンを確認するときに使用するキーに関する情報が記録されます。WriteToConfig は、メタデータ ドキュメントから発行者の設定を読み取る静的メソッドです (この場合は、ツールの初回実行時に格納された場所で、メソッドの 2 行目によって構成から取得)。このメソッドは、この設定を使用して、指定されたパスにあるファイルの対応する構成セクションを作成または更新します (メソッドの先頭行の現在の AppDomain から作成)。

  4. RefreshValidationSettings() をアプリケーションのライフサイクルに挿入するには、以下に示すように、Application_Start() から呼び出します。

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    RefreshValidationSettingsApplication_Start から呼び出すことで、web.config が必ず安全なときに変更されるようになります。一方、これをアプリのライフサイクルの中で後で行うと、リスクを負いながら更新をトリガーすることになります。

Important重要
アプリケーションから検証キーを自動更新するときに、さらに気を付けなければならないことがいくつかあります。軽減する必要がある主な脅威は DNS ハイジャックです。この攻撃では、攻撃者がマルウェアを使用して悪意のあるメタデータ ドキュメントをユーザーに示し、誤ったキーを信頼するようアプリを誘導します。

HTTP 要求を処理するための .NET 既定値をオーバーライドしなければ、メタデータ ドキュメントは HTTPS エンドポイントでホストされるため、上記のシナリオではこの脅威は既に緩和されています。DNS ハイジャックでは、要求を悪意のあるエンドポイントにリダイレクトできますが、こうしたエンドポイントは HTTPS サーバー検証に合格できません。攻撃者はメタデータ ドキュメントがホストされているドメインを実際に所有しておらず、そのドキュメントに対して発行された証明書を取得できません。これにより、クライアントはサーバーの問題を検出し、誤って誘導されるのを回避できます。

開発シナリオによっては、HTTPS 検証をオフにしなければならない場合があります (一般的には、ServicePoint クラス経由の検証)。このセクションで示す自動メタデータ更新ロジックを使用する場合は、アプリケーションを実稼働環境に展開する前に、HTTPS 検証設定を復元することが重要です。

  1. ようやくアプリケーションの動作を確認できます。F5 キーを押してください。ブラウザー ウィンドウが開き、プロジェクト設定で指定された URL (「MVC アプリの作成」セクションで指定) へのアクセスを試みます。

    最初は、証明書エラーが表示されます。これは想定された動作なので、[このサイトの閲覧を続行する (推奨されません)] をクリックします。実稼働アプリケーションではこのエラーは無視できませんが、このチュートリアルの目的を考慮し、ここでは許容できます。

    CertificateError アドレス バーを注意して見ていると、アプリの URL が一瞬表示されるのに気が付くでしょう。しかし、アプリの前にある FAM モジュールは、これが認証されていない呼び出しであることを即座に認識し、その対処方法を構成から読み取って、Azure AD へのサインインのリダイレクトをトリガーします。URL アドレス バーの URL は機関の 1 つに置き換えられ、ユーザーは Azure AD UI での認証が求められます。

    noteメモ
    最初に Microsoft アカウントを使用して管理ポータルにサインインした場合、前に作成した新しいユーザー アカウントは、Azure サブスクリプションの管理には使用できません。新しいユーザーとしてアプリケーションにサインインした後に、管理ポータルに戻ろうとすると、エラー メッセージが表示されます。代わりに、管理ポータルには、ディレクトリ テナントを作成したときに使用したアカウントでサインインする必要があります。最初に Azure AD アカウントを使用して管理ポータルにサインインし、前に作成した新しいユーザーにグローバル管理者ロールが割り当てられていると、この新しいユーザーは Azure サブスクリプションを管理できます。

    AAD へのサインイン
  2. このチュートリアルの最初のセクションで Azure テナントに作成したユーザーの資格情報を入力します。[サインイン] ボタンをクリックします。

    Azure AD テナントにユーザーを作成したときに、管理ポータルが一時パスワードをそのユーザーに割り当てたことを思い出してください。そのパスワードを使用して認証する必要があります。ただし、このパスワードは一時的なものであるため、この初回サインインの操作中に、適切なユーザー パスワードを選択するよう求められます。パスワードを選択しないと、認証フローを進めることができません。これを行うと、アプリへの通常のサインイン フローが復元されます。

    アプリケーション ホーム ページ 認証が適切に行われると、WIF が着信認証トークンからの要求を処理し、その要求は、ホーム コントローラーで追加した簡単な表示コードによって使用されます。以降、認証なしでサイトを閲覧でき、すべてのポストバックが、SAM モジュールで処理されるセッション Cookie を持つことになります。

  3. セッションを終了するときの動作を確認するには、右上隅の [サインアウト] リンクをクリックします。前にコーディングしたリダイレクトを確認します。このリダイレクトにより最終的に表示されるビューを次に示します。

    サインアウト 実際にサインアウトしたことを確認するには、他の UI 要素をクリックします。認証サイクルは最初からやり直されます。

ドキュメントのチュートリアル部分では、Web サインオンを Web アプリケーションに追加するために実行する必要がある重要な手順を紹介しました。このドキュメントの残りの部分では、基本機能を越えて、重要なトピックをさらに深く掘り下げ、アプリケーションを次のレベルに進める際に必要になる可能性がある他のタスクをいくつか取り上げます。

このセクションでは、アプリケーションの設定を変更して、そのアプリケーションを Azure Web サイトに展開して実行する方法について説明します。アプリケーションの大部分は変更されていません。唯一気を付ける必要があるのは、アプリの新しいアドレスとセッション管理への対応です。

ドキュメントのこのパートでは、アプリケーションを展開する Azure Web サイトが必要です。使用できる Web サイトが既にある場合は、それを使用します。使用できる Web サイトがない場合は、こちらのドキュメントで、Azure Web サイトを作成して発行する方法を参照してください。このドキュメントのチュートリアルに従う場合は、発行プロファイルをダウンロードしたらすぐに、作業を止めてください。アプリケーションを展開する前に、いくつか調整が必要です。

Azure 管理ポータルでのアプリケーション設定の調整

アプリケーション登録のセクションを思い出してください。Azure AD UI でアプリケーションを定義する主要パラメーターの 1 つが、アプリケーション自体の URL でした。ここまでのチュートリアルの手順では、アプリがローカルの IIS Express にあることを前提としていましたが、Azure Web サイトに展開すると、アプリケーションの URL が変わります。また、Azure AD の設定もそれに合わせて調整する必要があります。

  1. 管理ポータルに戻り、左側にある [Active Directory] タブを選択し、ディレクトリ テナントをクリックします。次に、[アプリケーション] ヘッダーを選択し、対象のアプリケーションに対応するエントリをクリックします。[構成] ヘッダーをクリックし、作成時に入力したアプリケーションの設定を変更できる画面に移動します。このチュートリアルの目的を考慮し、画面上部の領域は無視し、シングル サインオン セクションまで下にスクロールします。

    シングル サインオン
  2. [返信 URL] ボックスを探して、そのテキスト ボックスにターゲット Azure Web サイトのアドレスを入力します (https://aadga.windowsazure.net/ など)。これにより、正常に認証が行われた時点で、Azure AD がトークンを (スレッドで前に使用した開発時の場所ではなく) Azure Web サイトの場所に返すことができます。値を更新したら、画面の下部にあるコマンド バーで [保存] をクリックします。

noteメモ
[アプリ ID の URI] が、このドキュメントの前半で作成したローカルホスト ベースの値をまだ使用している場合があります。

技術的には、ID が URI 形式で、現在のディレクトリ テナントのすべてのアプリで一意であれば、ここで説明した種類のアプリに関しては、すべての値を使用できます。このため、主要手順ではこの値の更新については触れていません。

ただし、管理目的で [アプリ ID の URI] を変更して、もっとよくアプリケーションを表す値を使用することもできます。返信 URL 値の派生値はその典型的な例です。

[アプリ ID の URI] の値を変更した場合は、アプリを展開する前に、さらに広範にそのアプリを変更する必要があります。詳細は後半で説明します。

Azure Web サイトでアプリケーションを実行するための準備

Web サインオン構成の大部分がクラウド対応で、適用が必要な変更は 1 つだけです。これは主に Azure Web サイトの機能によるものです。

Web サインオン プロセスによりセッション Cookie が作成されます。この Cookie は、認証インスタントオンからのすべての要求で送信されます。セッション Cookie は WIF ミドルウェアによって作成され、クライアントによる不正使用 (特権昇格のための要求一覧の変更など) を防ぐために、既定では DPAPI で署名および暗号化されます (背景情報については、こちらのドキュメントを参照)。ただし、セッションを保護する DPAPI は、Azure Web サイトの IIS 設定により使用できなくなります。この場合は、WIF による関連 Cookie の保護方法を変更する必要があります。.NET Framework 4.5 には、MachineKey (こちらのドキュメントを参照) を利用する代替手段が用意されています。この方法は追加設定なしで使用でき、Azure Web サイトで問題なく動作します。

ID およびアクセス ツールを使用すると、この変更が非常に簡単になります。

  1. ソリューション エクスプローラーでプロジェクトを右クリックし、[ID とアクセス][構成] タブの順に選択します。次のスクリーンショットが表示されます。

    ID およびアクセスの Azure Web サイト
  2. [Web ファーム対応 Cookie を有効にする] チェック ボックスをオンにして、[OK] をクリックします。このツールでは、Cookie の保護方法として MachineKey に切り替えるため、web.config に必要な要素を追加します (具体的には、既定の SessionSecurityTokenHandler クラスを MachineKeySessionSecurityTokenHandler に置き換えます)。

    noteメモ
    前の手順で、Azure 管理ポータルの [アプリ ID の URI] を変更した場合、その変更は、この UI で簡単にプロジェクトに適用できます。上部の 2 つのテキスト フィールドに [アプリ ID の URI] の値を貼り付けて、[OK] をクリックするだけです。これにより、これらの変更が構成ファイルの適切な場所に適用されます。

    オプションで、ASP.NET カスタム エラー メッセージを一時的にオフにすることを検討します。それには、<customErrors mode="Off" /> エントリを、web.config<system.web> セクションに追加します。展開時に問題が発生する場合は、このように設定しておくとトラブルシューティングに役立ちます。ただし、このカスタム エラー メッセージは、実稼働環境に移動する前に必ずオンに戻してください。攻撃者は詳細なエラー メッセージを使用して、アプリに穴がないかどうかを調べますが、この攻撃は customError によって防ぐことができます。

アプリケーションを Azure Web サイトとして実行するための準備はこれだけです。発行の設定を使用してアプリケーションを展開し、ブラウザーでアプリの azurewebsite.net アドレスに移動して、チュートリアルのテスト セクションで説明したフローに従って操作します。すべてのカスタム ロジックを場所に依存しないように設計したため、ここで説明した操作はオンプレミスでも実行できます。

ID およびアクセス ツールでは、WS-Federation を介してアプリを Azure AD テナントに統合するのに必要な構成設定が自動生成されます。最善の状況では、これらの設定を実際に確認する必要はありませんが、場合によっては、既定の動作の変更や問題のトラブルシューティングが必要になることがあります。このような場合は、WIF 構成設定によってその方法がわかれば便利です。

Web サインイン フローで使用する WIF クラスとメソッドは MSDN で完全にドキュメント化されています。ここでは、ID およびアクセス ツールで変更した後の注釈付き web.config を示します。また、便宜上、Azure Web サイトへの発行に関するセクションの変更も含めました。

noteメモ
わかりやすくするために、ドキュメントには完全な Web.config ソースが含まれていますが、注釈が付いているのは WIF に関連するセクションだけです。

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

上記の構成に関するコメントはありません。

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

上記の構成では、この領域は、WIF が使用する構成セクションを読み取って解釈する目的で ASP.NET に必要なクラスを読み込んで、WS-Federation フローと認証設定をモデル化します。

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

上記の構成に関するコメントはありません。

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

上記の構成では、これらの appSettings エントリは ID およびアクセス ツールによって取得され、他の場所に保存されない重要な設定 (キー展開セクションで使用したメタデータ ドキュメントのアドレスなど) を追跡します。

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

上記の構成では、この 2 つの <location> 要素は、Web アプリケーションに認証要求なしでアクセスできる 2 つの領域を作成します (以下を参照)。FederationMetadata セクションは、ID とアクセス ツールによって作成されます。このツールは、アプリケーションを記述するメタデータ ドキュメントを作成します。このメタデータ ドキュメントは、機関がアプリをプロビジョニングするときに使用できます。SignOut セクションは、Web サインアウトを実装する方法について説明したときにご自身で追加しました。

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

上記の構成では、既定では、ID とアクセス ツールによって ASP.NET 認証と承認の設定が指定されます。これにより Web アプリのすべての部分 (上記の例外を除く) で、要求を行う前にユーザー認証が必要になります。これは、通常、LoB アプリには適していますが、場合によっては、開発者が匿名でアクセスできる領域を保持する必要も出てきます。この場合は、適宜設定を変更します。

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

上記の構成に関するコメントはありません。

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

上記の構成では、このセクションのエントリにより、コア プロトコルとセッション処理機能を実装する HTTPModule が SP.NET パイプラインに挿入されます。WSFederationAuthenticationModule (FAM) は、受信したトークンを検証し、プロトコルの仕様に合わせて機関に対するサインオン メッセージを生成することで WS-Federation を適用します。SessionAuthenticationModule (SAM) は、FAM と連携して、セッション Cookie を作成および検証します。

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

上記の構成に関するコメントはありません。

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

上記の構成では、<system.identityModel> により、WIF クラス固有のすべての設定がラップされます。その最初の子要素 IdentityConfiguration は、アプリケーション動作のプロトコルに依存しない説明を提供します。AudienceUri リストには、WIF が、現在のアプリケーションに対して受け取ったトークンで許容可能な範囲として見なすすべての値が示されます。通常、これは、アプリケーションの領域 (Azure AD ではアプリ ID の URI) に対応します。受け取ったトークンは、対象の受信者が、ここに示されている値の 1 つであることを宣言する必要があります。宣言しないと、WIF はこれが盗まれたトークンであると見なし、呼び出しを拒否します。

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

上記の構成では、ValidatingIssuerNameRegistry 要素に、許容可能な発行者の名前/署名チェック キー タプルの一覧が含まれます。このチュートリアルでは、Azure AD テナントに関連付けられている値が設定に反映されます。この要素により、他の発行者 (他の企業が所有する他の Azure AD テナントを含む) がアプリケーションにアクセスできないことが保証されます。

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

上記の構成では、この要素は、WIF パイプラインでの証明書の検証をオフにします。自己署名証明書が使用されている場合、この測定は Azure AD の状況で必要です。ローカル証明書ストアに証明書自体をインストールする場合を除き、チェインまたはピアの検証は失敗しますが、実際のところ、このために Azure AD 認証のセキュリティが低下することはありません。ValidatingIssuerNameRegistry により適切な証明書が使用されるからです。ただし、同じアプリで WIF を使用して他の発行者を信頼する場合は、これらの設定がその発行者にも拡張されることに注意してください。

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

このセクションを使用すると、受け取ったセキュリティ トークンを処理するために WIF が使用するクラスのコレクション (いわゆるトークン ハンドラー) を操作できます。たとえば、個別のハンドラーの動作を調整したり、ハンドラーの種類を追加および削除したりできます。この場合、ツールは既定のセッション ハンドラー (DPAPI に基づき、Azure Web サイトでは動作できません) を削除し、MachineKey で動作するものに置き換えます。

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

上記の構成では、<system.identityModel.services> は、WS-Federation 固有のコーディネートを格納するために使用されます。

この wsFederation 要素は、特に、Azure AD テナントの WS-Federation サインオン エンドポイント (サインオン時に ID として送信されるアプリの領域 (アプリ ID の URI))、および WIF のローカル動作を調整するその他のフラグ (アプリからの 401 エラーが必ず機関へのサインイン メッセージをトリガーするか (passiveRedirectEnabled)、クリア HTTP のトランザクションを許可するかなど) を記録するときに使用されます。

この要素を使用すると、さらに多くのプロトコル パラメーターを指定できます。これは、サインオン フローが機能するための絶対最小値です。

このドキュメントでは、.NET アプリケーションを Azure AD に接続し、WS-Federation を介して Web サインオンを実行するという、かなり限られたタスクに焦点を当てています。さまざまなオープン プロトコルや、最新のプラットフォームで任意のプログラミング スタックを利用して、またはネットワーク上のプロトコル レベルで直接操作して、対処できるシナリオは他にも多数あります。

Azure へのアプリの展開に関するセクションでは、管理ポータルで、さらに多くのアプリケーションの登録設定を変更できることを確認しました。この追加コントロールのほとんどを、このシリーズの次のチュートリアルで取り上げます、ここでは、Web サインオンまたはサポートされる他のフローに対して、プロトコル レベルで Azure AD を操作する場合に必要な情報を取得する方法について簡単に説明します。

  1. ブラウザー ウィンドウで Azure 管理ポータルを開き、[Azure AD] セクションの [アプリケーション] ヘッダーに移動します。画面の下部にあるコマンド バーに [エンドポイントの表示] というエントリが含まれていることがわかります。それをクリックします。

    アプリのエンドポイント プログラムによる Azure AD テナントの操作に使用できるすべてのエンドポイントが、ダイアログ ボックスに表示されます。ここでは、すべてのエントリについて簡単に説明します。

    • フェデレーション メタデータ ドキュメント: Web サインオン機関として Azure AD テナントを記述するメタデータ ドキュメントの場所。チュートリアルで確認したように、このドキュメントのキーの自動更新に関するセクションには、WS-Federation メタデータ コーディネートが含まれます。また SAML プロトコル メタデータも同じパッケージに含まれます。詳細については、「フェデレーション メタデータ」を参照してください。

    • WS-Federation サインオン エンドポイント: すべての WS-Federation トランザクションのエントリ ポイント。サインオン フローとサインアウト フローの両方に対してチュートリアルで使用したエンドポイントです。詳細については、「WS-Federation Endpoint URL」を参照してください。

    • SAML-P サインオン エンドポイント: SAML プロトコルでサインオン フローを実装するために使用されるエンドポイント。詳細については、「SAML プロトコルのメタデータおよびエンドポイント」を参照してください。

    • SAML-P サインアウト エンドポイント: SAML プロトコルでサインアウト フローを実装するために使用されるエンドポイント。詳細については、「SAML プロトコルのメタデータおよびエンドポイント」を参照してください。

    • Azure AD Graph エンドポイント:現在の Azure AD テナントに格納されたディレクトリ情報を取得するクエリは、Graph API 構文を使用して、このエンドポイントにアドレス指定する必要があります。詳細については、「Graph API を使用した Azure AD のクエリ」を参照してください。

    • OAuth2 トークン エンドポイント: これはサーバー用のエンドポイントで、サーバー認証フローを提供します。たとえば、アクセス トークンを取得して、Graph エンドポイントを起動する際に使用できます。詳細については、「OAuth 2.0 (Preview Version)」を参照してください。

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました

コミュニティの追加

表示:
© 2015 Microsoft