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

アプリケーションの追加、更新、および削除

更新日: 2014年10月

ここでは、Azure Active Directory (Azure AD) で、アプリケーションの追加、更新、または削除を行う方法について説明します。また、Azure AD と統合できるさまざまな種類のアプリケーション、アプリケーションを構成して Web API など他のリソースにアクセスする方法などについても説明します。アプリケーション プロパティの詳細については、「Application Objects and Service Principal Objects」を参照してください。

Azure AD の機能を使用するアプリケーションは、あらかじめディレクトリに登録しておく必要があります。この登録プロセスでは、アプリケーションが配置されている URL、ユーザーの認証後に応答を返す先の URL、アプリケーションを識別する URI など、Azure AD に対するアプリケーションの詳細情報が提供されます。

Azure AD のユーザーのサインオンが必要な Web アプリケーションを構築する場合は、以下の指示に従って構築してください。Web API へのアクセスが必要なアプリケーションの場合、Web アプリケーションへのアクセスが必要なネイティブ アプリケーションを構築する場合、またはアプリケーションをマルチテナントにする場合は、次に「アプリケーションを更新する」セクションを参照して、アプリケーションの構成を続けてください。

アプリケーションを他の組織でも使用できるようにするには、アプリケーションを追加した後で外部アクセスを有効にする必要があります。

  1. Azure 管理ポータルにサインインします。

  2. 左側のメニューの [Active Directory] アイコンをクリックし、目的のディレクトリをクリックします。

  3. 上部のメニューの [アプリケーション] をクリックします。ディレクトリに追加されているアプリケーションがない場合、このページには [アプリケーションの追加] リンクのみが表示されます。リンクをクリックします。または、コマンド バーの [追加] ボタンをクリックします。

  4. [作業内容] ページの [組織で開発中のアプリケーションを追加] リンクをクリックします。

  5. [アプリケーションの指定] ページでは、アプリケーションの名前だけでなく、Azure AD に登録するアプリケーションの種類を指定します。Web アプリケーションまたは Web API (既定)、またはネイティブ クライアント アプリケーション (電話機やコンピューターなどのデバイスにインストールされるアプリケーション) から選択できます。

    完了したら、ページの右下にある矢印アイコンをクリックします。

  6. [アプリケーションのプロパティ] ページで、Web アプリケーションの [サインオン URL] と [アプリケーションの ID/URI] (ネイティブ クライアント アプリケーションの場合は [リダイレクト URI] のみ) を指定し、ページの右下にあるチェック ボックスをクリックします。

  7. アプリケーションが追加され、アプリケーションの [クイック スタート] ページが表示されます。Web アプリケーションかネイティブ アプリケーションかによって、アプリケーションに機能を追加する方法のオプションが変わります。アプリケーションの追加が完了したら、アプリケーションを更新できるようになります。ユーザーによるサインインを有効にしたり、他のアプリケーションで Web API にアクセスできるようにしたり、マルチテナント アプリケーションを構成したりすることができます (他の組織がこのアプリケーションにアクセスできるようになります)。

    noteメモ
    既定で、新しく作成されたアプリケーションの登録は、ディレクトリのユーザーがアプリケーションにサインインできるように構成されます。

アプリケーションを Azure AD に登録した後に、Web API へのアクセス権を付与し、他の組織で使用できるようにするなどの更新が必要な場合があります。ここでは、アプリケーションの詳細な構成方法について説明します。Azure AD での詳細な認証方法については、「Azure AD の認証シナリオ」を参照してください。

アプリケーションを更新する前に、Azure AD の同意フレームワークについて理解しておく必要がある、重要な概念がいくつかあります。

Azure AD の新しい同意フレームワークを使用すると、Azure AD で保護された Web API にアクセスする必要がある Web アプリケーションとネイティブ アプリケーションを簡単に開発できるようになります。この Web API には、自作の Web API だけでなく、Graph API、Office 365、その他の Microsoft サービスも含まれます。このフレームワークは、アプリケーションをディレクトリに登録することをユーザーまたは管理者が同意する処理に基づいていており、ディレクトリ データへのアクセスが必要な場合があります。たとえば、Office 365 の Web API を呼び出して、ユーザーに関するカレンダー情報を読み取る必要がある Web アプリケーションの場合、そのユーザーはそのアプリケーションに同意する必要があります。ユーザーが同意すると、Web アプリケーションはユーザーの代理で Office 365 Web API を呼び出し、必要に応じてカレンダー情報を使用できるようになります。

同意フレームワークは、パブリック クライアントと秘密のクライアントを使用して、OAuth 2.0 とさまざまなフロー (認証コード付与、クライアント資格情報の付与など) に基づいて構築されています。Azure AD は OAuth 2.0 を使用して、電話機、タブレット、サーバー、Web アプリケーションなど用にさまざまなクライアント アプリケーションを構築し、必要なリソースのアクセス権を取得します。

同意フレームワークの詳細については、「Azure AD での OAuth 2.0」、「Azure AD の認証シナリオ」、および Office 365 のトピック「共通の同意フレームワークを使用した認証と承認 (英語)」を参照してください。

次の手順では、同意エクスペリエンスがアプリケーション開発者とユーザーの両方に対してどのように働くかについて説明します。

  1. Azure 管理ポータルのアプリケーションの構成ページで、[他のアプリケーションに対するアクセス許可] コントロールのドロップダウン メニューを使用して、アプリケーションに必要なアクセス許可を設定します。



    他のアプリケーションに対するアクセス許可

  2. たとえば、アプリケーションのアクセス許可が更新され、アプリケーションが実行され、ユーザーがアプリケーションを初めて使用したとします。アプリケーションがまだアクセス権または更新トークンを獲得していない場合、アプリケーションは Azure AD の認証エンドポイントに接続し、認証コードを取得する必要があります。認証コードを使用すると、新しいアクセス権と更新トークンを獲得できます。

  3. ユーザーがまだ認証されていない場合、Azure AD にサインインするように求められます。



    ユーザーまたは管理者による Azure AD へのサインイン

  4. ユーザーがサインインした後、Azure AD でユーザーに同意ページを表示するかどうかが決定されます。この決定は、ユーザー (または組織の管理者) が既にアプリケーションに同意しているかどうかに基づいて行われます。まだ同意されていない場合は、同意するように求めるメッセージと、アプリケーションの機能に必要なアクセス許可がユーザーに表示されます。同意ダイアログに表示されるアクセス許可は、Azure 管理ポータルの [他のアプリケーションに対するアクセス許可] コントロールで選択したアクセス許可と同じです。



    ユーザー同意画面

  5. ユーザーが同意すると、認証コードはアプリケーションに返され、アクセス トークンと更新トークンの獲得に利用できます。このフローの詳細については、「Azure AD の認証シナリオ」の「Web Application to Web API」セクションを参照してください。

ここで説明した同意フレームワークを使用すると、ディレクトリ内の Web API に公開されているデータにアクセスする場合に、アクセス許可が必要になるようにアプリケーションを構成できます。既定では、すべてのアプリケーションが Azure Active Directory (Graph API) と Azure Service Management API のアクセス許可を選択できます。Azure AD の "サインオンを有効にしてユーザーのプロファイルを読み取る" アクセス許可は、既定で選択されています。ディレクトリに Office 365 のサブスクリプションもある場合、Web API と SharePoint および Exchange Online のアクセス許可も選択できます。目的の Web API の横に表示されるドロップダウン メニューでは、2 種類のアクセス許可から選択できます。

  • アプリケーションのアクセス許可:アプリケーションは、アプリケーションだけで (ユーザー コンテキストなしで) Web API に直接アクセスできる必要があります。このようなアクセス許可には管理者の同意が必要であり、ネイティブ クライアント アプリケーションには使用できません。

  • 委任のアクセス許可:アプリケーションは、サインイン ユーザーとして Web API にアクセスする必要がありますが、アクセスは選択したアクセス許可で制限されています。このようなアクセス許可は、管理者の同意が必要というアクセス許可が構成されていない場合、ユーザーが付与できます。

  1. Azure 管理ポータルにサインインします。

  2. 左側のメニューの [Active Directory] アイコンをクリックし、目的のディレクトリをクリックします。

  3. 上部のメニューにある [アプリケーション] をクリックし、構成するアプリケーションをクリックします。[クライアント スタート] ページが開き、シングル サインオンと他の構成情報が表示されます。

  4. [クライアント スタート] の [他のアプリケーションの Web API へのアクセス] を展開し、[アクセス許可の設定] セクションの [今すぐ構成] リンクをクリックします。アプリケーションのプロパティ ページが表示されます。

  5. [他のアプリケーションに対するアクセス許可] セクションまでスクロールします。1 列目では、Web API を公開しているディレクトリ内の使用できるアプリケーションから選択できます。選択すると、アプリケーションと、Web API が公開している委任アクセス許可を選択できます。

  6. 選択が完了したら、コマンド バーの [保存] ボタンをクリックします。

    noteメモ
    [保存] ボタンをクリックすると、構成した [他のアプリケーションに対するアクセス許可] に基づいて、ディレクトリ内のアプリケーションのアクセス許可も自動的に設定されます。これらのアプリケーションのアクセス許可を確認するには、アプリケーションの [プロパティ] タブを表示します。

Web API を開発し、他の組織が使用できるようにするには、アクセス許可のスコープを他のアプリケーション開発者に公開します。正しく構成した Web API は、Graph API や Office 365 API など、他の Microsoft Web API と同様に使用できます。Web API を使用できるようにするには、アプリケーション マニフェストを構成します。アプリケーション マニフェストは、アプリケーションの ID 構成を示す JSON ファイルです。アクセス許可のスコープを公開するには、Azure 管理ポータルでアプリケーションを開き、コマンド バーの [アプリケーション マニフェスト] ボタンをクリックします。

  1. Azure 管理ポータルにサインインします。

  2. 左側のメニューの [Active Directory] アイコンをクリックし、目的のディレクトリをクリックします。

  3. 上部のメニューにある [アプリケーション] をクリックし、構成するアプリケーションをクリックします。[クライアント スタート] ページが開き、シングル サインオンと他の構成情報が表示されます。

  4. コマンド バーの [マニフェストの管理] ボタンをクリックし、[マニフェストのダウンロード] を選択します。

  5. JSON アプリケーション マニフェスト ファイルを開き、“oauth2Permissions” ノードを次の JSON スニペットで置き換えます。このスニペットは、ユーザーの偽装というアクセス許可のスコープを公開する例です。実際のアプリケーションに合わせてテキストと値を変更してください。

    "oauth2Permissions": [
        {
          "adminConsentDescription": "Allow the application full access to the Todo List service on behalf of the signed-in user",
          "adminConsentDisplayName": "Have full access to the Todo List service",
          "id": "b69ee3c9-c40d-4f2a-ac80-961cd1534e40",
          "isEnabled": true,
          “origin”: “Application”
          "type": "User",
          "userConsentDescription": "Allow the application full access to the todo service on your behalf",
          "userConsentDisplayName": "Have full access to the todo service",
          "value": "user_impersonation"
        }
      ],
    

    id 値は、GUID 生成ツールまたはプログラムを使用して作成した新しい GUID である必要があります。GUID とは、Web API で公開されているアクセス許可の一意の識別子です。Web API へのアクセスを要求し、Web API を呼び出すようにクライアントが適切に構成されている場合、クライアントは、scope (scp) 要求セットが上記の (この例では user_impersonation) に設定された OAuth 2.0 JWT トークンを示します。

    noteメモ
    必要に応じて、追加のアクセス許可スコープを公開できます。たとえば、自作の Web API が、多様な機能と関連付けられた複数のアクセス許可を公開しているとします。この場合、受け取った OAuth 2.0 JWT トークンのスコープ (scp) 要求を使用して、Web API へのアクセスを制御できるようになります。

  6. コマンド バーの [マニフェストの管理] ボタンをクリックし、[マニフェストのアップロード] を選択し、更新されたマニフェスト ファイルを参照して選択して、更新された JSON ファイルを保存し、アップロードします。アップロードされると、ディレクトリ内の他のアプリケーションから使用できるように Web API が構成されます。

  1. 上部のメニューの [アプリケーション] をクリックし、Web API へのアクセス権を構成する対象のアプリケーションを選択し、[構成] をクリックします。

  2. [他のアプリケーションに対するアクセス許可] セクションまでスクロールします。[アプリケーションの選択] ドロップダウン メニューをクリックすると、アクセス許可を公開した Web API のみを選択できます。[委任のアクセス許可] ドロップダウン メニューから、新しいアクセス許可を選択します。

    作業一覧のアクセス許可の表示

次の表は、アプリケーション マニフェスト JSON ファイルの oauth2Permissions の部分で使用できる値の一覧です。

 

要素 説明

adminConsentDescription

管理者の同意ダイアログと同意されたアプリケーションのプロパティ ページで、マウスを移動して表示されるヘルプの説明。

adminConsentDisplayName

アプリケーションと委任のアクセス許可スコープのドロップダウンに表示されるアクセス許可のフレンドリ名。同意中に管理者に表示され、アプリケーションのプロパティ ページにも表示されます。

id

アクセス許可スコープの一意の内部識別子を示します。アプリケーションのすべてのアクセス許可で一意にする必要があります。また、GUID にする必要もあります。

isEnabled

OAuth2 アクセス許可を作成または更新すると、この値は常に true に設定されます。アクセス許可を削除する場合、まずこの値を false に設定し、マニフェストをアップロードする必要があります。アップロード後は、以降のマニフェストのアップロードでアクセス許可を削除できます。

origin

将来の使用のために予約されています。常に "application" に設定されています。

次の値のいずれかです。

  • “User”: エンド ユーザーが同意できます

  • “Admin”: 会社の管理者が同意する必要があります

userConsentDescription

ユーザーの同意ダイアログでマウスを移動すると表示されるヘルプの説明。

userConsentDisplayName

同意中にエンドユーザーに表示されるアクセス許可のフレンドリ名。アプリケーションのアクセス パネルで、アプリケーションのプロパティ ページにも表示されます。

value

ユーザーがアクセス許可に同意した場合、この値が OAuth 2.0 アクセス トークンの scp 要求に設定されます。Web API はこの値を使用して、アプリケーションがユーザーを偽装するときに持つアクセス レベルのスコープを設定できます。この値に空白を含めることはできません。また、アプリケーションのすべてのアクセス許可で一意にする必要があります。

ここでは、Graph API にアクセスするようにアプリケーションを更新する方法について説明します。Graph API は、[他のアプリケーションに対するアクセス許可] のリストで [Azure Active Directory] と表示されます。Azure AD に登録されたすべてのアプリケーションで、Graph API を既定で使用できます。Graph API を使用すると、次のアクセス許可から選択できます。

 

アクセス許可名 説明

サインオンを有効にしてユーザーのプロファイルを読み取る

組織のアカウントを使用してアプリケーションにサインインし、サインインしたユーザーのプロファイル (電子メール アドレスや連絡先情報など) をアプリケーションが読み取ることを許可します。

委任のアクセス許可のみ。ユーザーが同意できます。

組織のディレクトリにアクセスする

サインインしたユーザーの代理で組織が組織のディレクトリにアクセスすることを許可します。

委任のアクセス許可のみ。ネイティブ クライアントのユーザー、および Web アプリケーションの管理者のみが同意できます。

ディレクトリ データの読み込み

ユーザー、グループ、アプリケーションなど、組織のディレクトリ内のデータを読み取ることを、アプリケーションに許可します。

委任とアプリケーションのアクセス許可。管理者が同意する必要があります。

ディレクトリ データの読み取りと書き込み

ユーザー、グループなど、組織のディレクトリ内のデータの読み取りと書き込みを、アプリケーションに許可します。

委任とアプリケーションのアクセス許可。管理者が同意する必要があります。

Azure 管理ポータルの既存のユーザーの場合、新しい [他のアプリケーションに対するアクセス許可] コントロールでアプリケーションのアクセス許可 [ディレクトリ データの読み取り] と [ディレクトリ データの読み取りと書き込み] を設定する処理は、以前の [アクセスの管理] ウィザードを使用する処理と同様です。Office 365 で公開されているアクセス許可スコープを確認する方法については、「共通の同意フレームワークを使用する認証と承認」を参照してください。

noteメモ
現在、制限があるため、ネイティブ クライアント アプリケーションが [組織のディレクトリにアクセスする] アクセス許可を使用する場合、Azure AD Graph API のみを呼び出すことができます。この制限は Web アプリケーションには適用されません。

Azure AD にアプリケーションを追加する場合、組織内のユーザーにのみ、アプリケーションへのアクセスを許可したいことがあります。また、外部組織のユーザーに、アプリケーションへのアクセスを許可することもあります。これら 2 種類のアプリケーションは、シングル テナント アプリケーションとマルチテナント アプリケーションと呼ばれます。シングル テナントアプリケーションの構成を変更して、マルチテナント アプリケーションにすることができます。このセクションでは、その方法について説明します。

シングル テナント アプリケーションとマルチテナント アプリケーションの違いについて理解することが重要です。シングル テナント アプリケーションは、1 つの組織で使用されることを目的としています。シングル テナント アプリケーションは、通常、エンタープライズ開発者によって作成された基幹業務 (LOB) アプリケーションです。シングル テナント アプリケーションは、1 つのディレクトリのユーザーのみによってアクセスされる必要があり、結果として、1 つのディレクトリのみでプロビジョニングされる必要があります。マルチテナント アプリケーションは、複数の組織で使用されることを目的としています。マルチテナント アプリケーションは、通常、独立系ソフトウェア ベンダー (ISV) によって作成された、サービスとしてのソフトウェア (SaaS) アプリケーションです。マルチテナント アプリケーションは、使用される各ディレクトリでプロビジョニングされる必要があります。これらを登録するには、ユーザーまたは管理者の同意が必要です。

組織の外部の顧客やパートナーが使用できるアプリケーションを作成する場合、Azure 管理ポータルでアプリケーションの定義を更新する必要があります。

noteメモ
外部アクセスを有効にする場合、アプリケーションのアプリケーション ID URI が検証済みドメインに属していることを確認する必要があります。さらに、リターン URL の先頭は https:// である必要があります。詳細については、「Application Objects and Service Principal Objects」を参照してください。

  1. Azure 管理ポータルにサインインします。

  2. 左側のメニューの [Active Directory] アイコンをクリックし、目的のディレクトリをクリックします。

  3. 上部のメニューにある [アプリケーション] をクリックし、構成するアプリケーションをクリックします。[クライアント スタート] ページが開き、シングル サインオンと他の構成情報が表示されます。

  4. [クライアント スタート] の [マルチテナント アプリケーションの構成] セクションを展開し、[アクセスの有効化] セクションの [今すぐ構成] リンクをクリックします。アプリケーションのプロパティ ページが表示されます。

  5. [アプリケーションはマルチテナントです] の横の [はい] をクリックし、コマンド バーの [保存] をクリックします。

上記の変更を完了したら、組織内のユーザーと管理者は、ディレクトリや他のデータへのアクセス権をアプリケーションに付与できるようになります。

同意フレームワークを使用してアクセス権を付与するには、クライアント アプリケーションは OAuth 2.0 を使用して承認を要求する必要があります。Web アプリケーション、ネイティブ アプリケーション、またはサーバー/デーモン アプリケーションが認証コードとアクセス トークンを要求して、Web API を呼び出すコード サンプルを利用できます。

Web アプリケーションは、ユーザーにサインアップ エクスペリエンスを提供できます。サインアップ エクスペリエンスを提供する場合、ユーザーがサインアップ (またはサインイン ボタン) をクリックして、ブラウザーが Azure AD OAuth2.0 承認エンドポイントまたは OpenID Connect ユーザー情報エンドポイントにリダイレクトされることになります。このようなエンドポイントでは、アプリケーションが id_token を調べて、新規ユーザーに関する情報を取得できます。

また、Web アプリケーションで、管理者が "自分の会社をサインアップ" できるエクスペリエンスを提供することもできます。このエクスペリエンスでも、ユーザーは Azure AD OAuth 2.0 承認エンドポイントにリダイレクトされます。この場合、prompt=admin_consent パラメーターを渡して、管理者の同意エクスペリエンスをトリガーすることもできます。ここで、管理者は組織の代理で同意することができます。同意に成功すると、応答には admin_consent=true が含まれます。アクセス トークンを引き換えると、ファイルにサインアップした組織と管理者に関する情報を提供する id_token も受け取ります。

ここでは、2014 年 3 月 12 日より前の、従来の同意エクスペリエンスについて説明します。このエクスペリエンスは現在もサポートされています。今回の新機能の前には、次のアクセス許可のみを付与できました。

  • 組織のユーザーをサインオンする

  • ユーザーをサインオンし、組織のディレクトリ データを読み取る (アプリケーションとしてのみ)

  • ユーザーをサインオンし、組織のディレクトリ データを書き込む (アプリケーションとしてのみ)

Azure AD でのマルチテナント Web アプリケーションの開発」の手順に従って、Azure AD に登録された新しいアプリケーションにアクセス権を付与することができます。新しい同意フレームワークでは、さらに強力なアプリケーションを許可し、管理者だけでなく、ユーザーもアプリケーションに同意できるようになりました。

外部ユーザーが組織のアカウントを使用してアプリケーションにサインアップできるようにするには、アプリケーションを更新して、アクセスを付与できる Azure AD のページにリンクするボタンを表示する必要があります。このサインアップ ボタンのブランド設定に関するガイドラインについては、「統合アプリケーションのブランド化ガイドライン」を参照してください。ユーザーがアクセス権を付与または拒否すると、Azure AD のアクセス権の付与ページによって、ブラウザーは応答付きでアプリケーションにリダイレクトされます。アプリケーションのプロパティの詳細については、「Application Object」を参照してください。

アクセス権の付与ページは Azure AD によって作成されます。このページへのリンクは、管理ポータルのアプリケーションの [構成] ページに表示されます。[構成] ページを表示するには、Azure AD テナントの上部のメニューにある [アプリケーション] リンクをクリックし、構成するアプリケーションをクリックし、[クライアント スタート] ページの上部のメニューから [構成] をクリックします。

アプリケーションのリンクは、http://account.activedirectory.windowsazure.com/Consent.aspx?ClientID=058eb9b2-4f49-4850-9b78-469e3176e247&RequestedPermissions=DirectoryReaders&ConsentReturnURL= https%3A%2F%2Fadatum.com%2FExpenseReport.aspx%3FContextId%3D123456 のようになります。次の表は、リンクの各部分の説明です。

 

Parameter 説明

ClientId

必須。アプリケーション追加の一環で取得するクライアント ID。

RequestedPermissions

省略可能。アプリケーションが要求しているアクセス レベル。アプリケーションのアクセス権を付与するユーザーに表示されます。指定しない場合、要求されるアクセス権は既定でシングル サインオンのみに設定されます。その他のオプションは DirectoryReadersDirectoryWriters です。これらのアクセス レベルの詳細については、「Application Access Levels」を参照してください。

ConsentReturnUrl

省略可能。アクセス権の付与の応答を返す先の URL。この値は、URL エンコーディングする必要があります。また、アプリケーションの定義で構成した Reply URL と同じドメインに属する必要があります。指定しない場合、アクセス権の付与の応答は、構成した Reply URL にリダイレクトされます。

Reply URL とは別に ConsentReturnUrl を指定すると、アプリケーションは別のロジックを実装して、Reply URL (通常は、サインオンのための SAML トークンを処理します) からの別の URL に対する応答を処理できるようになります。また、エンコーディングされた URL の ConsentReturnURL に追加のパラメーターを指定することもできます。このようなパラメーターは、リダイレクト時にクエリ文字列パラメーターとしてアプリケーションに渡されます。このメカニズムを使用して、追加情報を保持したり、アプリケーションのアクセス権の付与要求を Azure AD からの応答に関連付けたりすることができます。

アプリケーションがアクセス権の付与リンクにリダイレクトされると、次の例のような画像がユーザーに表示されます。

ユーザーがまだサインインしていない場合は、サインインを求められます。

AAD へのサインイン

ユーザーが認証されると、Azure AD によってユーザーはアクセス権の付与ページにリダイレクトされます。

アクセス権の付与

noteメモ
外部組織の会社の管理者のみが、アプリケーションへのアクセス権を付与できます。ユーザーが会社の管理者ではない場合、このアプリケーションのアクセス権を付与するように依頼するメールを会社の管理者に送信することができます。

顧客が [アクセス権の付与] をクリックしてアプリケーションのアクセス権を付与した後、または [キャンセル] をクリックしてアクセス権を許可した場合、Azure AD は応答を ConsentReturnUrl または構成した Reply URL に送信します。この応答には次のパラメーターがあります。

 

Parameter 説明

TenantId

アプリケーションのアクセス権を付与した Azure AD 内の組織の一意な ID。このパラメーターは、顧客がアクセス権を付与した場合にのみ指定します。

Consent

アプリケーションにアクセス権が付与された場合、この値は Granted に設定され、要求が拒否された場合は Denied に設定されます。

エンコーディングされた URL の ConsentReturnUrl にその他のパラメーターが含まれていた場合、アプリケーションに返されます。次の例は、アプリケーションが承認されたことを示すアクセス権の付与要求に対する応答を示します。この応答には、アクセス権の付与要求で指定された ContextID が含まれます。https://adatum.com/ExpenseReport.aspx?ContextID=123456&Consent=Granted&TenantId=f03dcba3-d693-47ad-9983-011650e64134

noteメモ
アクセス権の付与応答に、ユーザーのセキュリティ トークンは含まれません。アプリケーションは別の処理でユーザーをサインインさせる必要があります。

次の例は、アクセス権の付与要求に対する拒否の応答を示します。https://adatum.com/ExpenseReport.aspx?ContextID=123456&Consent=Denied

アプリケーションの有効期間中に、Azure AD を呼び出して、Graph API を呼び出すアクセス トークンを獲得するときに使用するキーを変更する必要があります。通常、キーの変更は 2 つのカテゴリに分類されます。キーのセキュリティが侵害された場合の緊急ロール オーバーと、現在のキーが間もなく期限切れなるときのロール オーバーです。(主に 2 番目のカテゴリのために) キーを更新するときに、アプリケーションのアクセスを中断させないようにするには、次の手順に従うことをお勧めします。

  1. Azure 管理ポータルで、ディレクトリ テナントをクリックし、上部のメニューから [アプリケーション] をクリックし、構成するアプリケーションをクリックします。[クライアント スタート] ページが開き、シングル サインオンと他の構成情報が表示されます。

  2. 上部のメニューの [構成] をクリックすると、アプリケーションのプロパティのリストと、キーのリストが表示されます。

  3. [キー] の [時間の選択] というドロップダウンをクリックし、1 年または 2 年を選択し、コマンド バーの [保存] をクリックします。アプリケーションの新しいパスワード キーが生成されます。この新しいパスワード キーをコピーします。この時点で、アプリケーションは既存のキーと新しいキーの両方を使用して、Azure AD からアクセス トークンを取得できます。

  4. アプリケーションに戻り、新しいパスワード キーを使用するように構成を更新してください。この更新が実行される例については、「Graph API を使用した Azure AD のクエリ」を参照してください。

  5. この変更は運用環境全体に展開する必要があります。まず 1 つのサービス ノードで検証してから、残りに展開してください。

  6. 運用デプロイ全体で更新が完了したら、Azure 管理ポータルに戻り、古いキーを削除することができます。

アプリケーションに対する外部ユーザーのアクセス権を有効にした後は、Azure 管理ポータルで引き続きアプリケーションのプロパティ変更することもできます。ただし、アプリケーションを変更するbefore、既にアプリケーションへのアクセス権を付与した顧客の場合、Azure 管理ポータルでアプリケーションに関する詳細情報を表示したときに、反映された変更内容は表示されません。アプリケーションが顧客に使用できるようにした後は、特定の変更を加えるときに注意する必要があります。たとえば、App ID URI を更新すると、その変更前にアクセス権を付与した既存の顧客は、会社のアカウントまたは学校のアカウントを使用して、アプリケーションにログインできなくなります。

より高いアクセス レベルを要求するように RequestedPermissions を変更した場合、既存の顧客は、その高いアクセス レベルを使用した新しい API 呼び出しが利用されるアプリケーションの機能を実行するときに、Graph API からアクセスの拒否応答を受け取る可能性があります。このような場合はアプリケーションが処理し、高いアクセス レベルの要求があるアプリケーションにアクセス権を付与するように顧客に依頼する必要があります。

ここでは、シングル テナント アプリケーションとマルチテナントの両方について、ディレクトリからアプリケーションを削除する方法について説明します。

  1. Azure 管理ポータルにサインインします。

  2. 左側のメニューの [Active Directory] アイコンをクリックし、目的のディレクトリをクリックします。

  3. 上部のメニューにある [アプリケーション] をクリックし、構成するアプリケーションをクリックします。[クライアント スタート] ページが開き、シングル サインオンと他の構成情報が表示されます。

  4. コマンド バーの [削除] ボタンをクリックします。

  5. 確認メッセージに対して [はい] をクリックします。

  1. Azure 管理ポータルにサインインします。

  2. 左側のメニューの [Active Directory] アイコンをクリックし、目的のディレクトリをクリックします。

  3. 上部のメニューにある [アプリケーション] をクリックし、構成するアプリケーションをクリックします。[クライアント スタート] ページが開き、シングル サインオンと他の構成情報が表示されます。

  4. [アプリケーションはマルチテナントです] セクションで [いいえ] をクリックします。これでアプリケーションはシングル テナントに変換されますが、アプリケーションが既に同意している組織は変わりません。

  5. コマンド バーの [削除] ボタンをクリックします。

  6. 確認メッセージに対して [はい] をクリックします。

会社の管理者が (同意した後に) ディレクトリに対するアプリケーションのアクセス権を削除するには、会社の管理者が Azure のサブスクリプションを使用して Azure 管理ポータルでアクセス権を削除する必要があります。または、会社の管理者が Azure AD PowerShell コマンドレット を使用してアクセス権を削除することもできます。

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