条件付きアクセス認証コンテキストに関する開発者ガイド

[アーティクル]
10/25/2023

条件付きアクセスは、あらゆるアプリ、つまり新旧、プライベート、パブリック、オンプレミス、マルチクラウドのアプリへのアクセスに対してポリシーを適用できるようにするゼロトラストコントロールプレーンです。条件付きアクセス認証コンテキストを使用して、それらのアプリ内でさまざまなポリシーを適用できます。

条件付きアクセス認証コンテキスト (認証コンテキスト) を使用すると、単にアプリレベルだけではなく、機密データとアクションに詳細なポリシーを適用できます。ユーザーの摩擦をできるだけ少なくし、ユーザーの生産性とリソースの安全性を向上させながら、最低特権アクセスのためにゼロトラストポリシーを調整できます。現在、これは、OpenId Connect を使用するアプリケーションで利用でき、高価値のトランザクションや従業員の個人データの表示など、機密性の高いリソースを保護するために会社で開発された認証用に使用されます。

アプリケーションとサービス内からステップアップ認証をトリガーするには、Microsoft Entra 条件付きアクセスエンジンの認証コンテキスト機能を使用します。開発者は、アプリケーション内からのエンドユーザーによる MFA など、高度でより強力な認証を選択的に要求することができるようになりました。この機能により、開発者はアプリケーションのほとんどの部分でよりスムーズなユーザーエクスペリエンスを構築できるようになると同時に、より強力な認証制御に基づいて、より安全な操作やデータへのアクセスが保持されます。

問題の説明

IT 管理者と規制機関は、認証の追加要素をユーザーに頻繁に求めすぎることと、アプリケーションやサービスに機密性の高いデータと操作が含まれる場合に、それらに対する適切なセキュリティとポリシーの準拠を実現することの間のバランスを取ることで悩むことが多くあります。これは、ほとんどのデータやアクションへのアクセス時にユーザーの生産性に影響を与える強力なポリシーか、機密性の高いリソースに対して十分ではないポリシーかのいずれかの選択になる場合があります。

では、アプリが両方を兼ね備えている場合はどうでしょうか。つまり、大半のユーザーと操作に対してセキュリティの強度が比較的低く、プロンプトが出される頻度も低い状態で機能する一方、ユーザーが機密性の高い部分にアクセスしたときにセキュリティ要件を条件付きでステップアップできるような場合です。

一般的なシナリオ

たとえば、ユーザーは多要素認証を使用して SharePoint にサインインする可能性がありますが、機密性の高いドキュメントを含む SharePoint のサイトコレクションへのアクセスには、準拠しているデバイスを使用する必要があり、かつ信頼できる IP 範囲からしかアクセスできないようにすることができます。

前提条件

最初に、認証と許可に OpenID Connect/ OAuth 2.0 プロトコルを使用して、アプリを Microsoft ID プラットフォームと統合する必要があります。 Microsoft ID プラットフォームの認証ライブラリを使用してアプリケーションを統合し、Microsoft Entra ID でセキュリティ保護することが推奨されます。アプリと Microsoft ID プラットフォームの統合方法の学習は、Microsoft ID プラットフォームのドキュメントをお読みになることから始めることをお勧めします。条件付きアクセス認証コンテキスト機能のサポートは、業界標準の OpenID Connect プロトコルによって提供されるプロトコル拡張機能に基づいて構築されています。開発者は、条件付きアクセス認証コンテキスト参照の値とクレーム要求パラメーターを使用して、アプリがポリシーをトリガーして満たすことができるようにします。

2 番目に、条件付きアクセスでは、Microsoft Entra ID P1 ライセンスが必要になります。ライセンスの詳細については、Microsoft Entra の価格に関するページを参照してください。

3 番目に、現時点では、ユーザーがサインインするアプリケーションでのみ使用できます。それ自体として認証されるアプリケーションはサポートされていません。 Microsoft ID プラットフォームでサポートされている認証アプリの種類とフローについては、「認証フローとアプリケーションのシナリオ」ガイドを参照してください。

統合手順

サポートされている認証プロトコルを使用してアプリケーションを統合し、条件付きアクセス機能を使用できる Microsoft Entra テナントに登録したら、ユーザーがサインインするアプリケーションにこの機能を統合するプロセスを開始できます。

Note

この機能の詳細なチュートリアルは、Use Conditional Access Auth Context in your app for step-up authentication の録画されたセッションでも参照できます。

最初に、認証コンテキストを宣言し、テナントで使用できるようにします。詳しくは、認証コンテキストの構成に関する記事をご覧ください。

テナントの認証コンテキスト ID として値 C1 から C99 を使用できます。認証コンテキストの例を次に示します。

C1 - 強力な認証が必要
C2 – 準拠しているデバイスが必須
C3 – 信頼できる場所が必要

条件付きアクセス認証コンテキストを使用する条件付きアクセスポリシーを作成または変更します。ポリシーの例を次に示します。

この Web アプリケーションにサインインするすべてのユーザーは、認証コンテキスト ID C1 の 2FA を正常に完了している必要があります。
この Web アプリケーションにサインインするすべてのユーザーは、2FA を正常に完了し、さらに、認証コンテキスト ID C3 の特定の IP アドレス範囲から Web アプリにアクセスする必要があります。

注意

条件付きアクセス認証コンテキストの値は、アプリケーションとは別に宣言および管理されます。アプリケーションが認証コンテキスト ID に強く依存することは推奨されません。条件付きアクセスポリシーは通常、ポリシーを適用するために使用できるリソースをより深く理解している IT 管理者によって作成されます。たとえば、Microsoft Entra テナントの場合、IT 管理者は、MFA に 2FA を使用する用意ができているテナントのユーザー数を把握しているため、2FA を必要とする条件付きアクセスポリシーの範囲をこれらの対応ユーザーに限定することができます。同様に、アプリケーションが複数のテナントで使用されている場合、使用される認証コンテキスト ID は異なる可能性があり、場合によっては、まったく使用できない場合もあります。

2 番目: 条件付きアクセス認証コンテキストを使用する予定のアプリケーションの開発者は、まず、アプリケーション管理者または IT 管理者に、潜在的に機密性の高いアクションを認証コンテキスト ID にマップする方法を提供することをお勧めします。手順は大まかに次のとおりです。

認証コンテキスト ID にマップすることができるコード内のアクションを識別します。
IT 管理者が、機密性の高いアクションを使用可能な認証コンテキスト ID にマップするために使用できる、アプリの管理ポータル内の画面 (または同等の機能) を作成します。
実行方法の例については、条件付きアクセス認証コンテキストを使用したステップアップ認証の実行に関するページのコードサンプルを参照してください。

以下の手順は、コードベースで実行する必要がある変更です。これらの手順は、大まかに以下で構成されています。

MS Graph にクエリを実行して、使用可能なすべての認証コンテキストを一覧表示します。
IT 管理者が機密性が高く、高い特権を持つ操作を選択し、使用可能な認証コンテキストに対して条件付きアクセスポリシーを使用してそれらを割り当てることができるようにします。
このマッピング情報をデータベースまたはローカルストアに保存します。

認証コンテキストを作成するためのセットアップフロー

3 番目: アプリケーション (この例では、Web API を想定します) では、保存されたマッピングに対して呼び出しを評価し、その結果に応じて、クライアントアプリのクレームチャレンジを発生させる必要があります。このアクションを準備するには、次の手順を実行します。

機密性が高く、認証コンテキストによって保護されている操作の場合は、前に保存した認証コンテキスト ID マッピングに対して acrs 要求の値を評価し、次のコードスニペットに示すクレームチャレンジを発生させます。

次の図は、ユーザー、クライアントアプリ、Web API の間の相互作用を示しています。

ユーザー、Web アプリ、API、Microsoft Entra ID の相互作用を示す図

次のコードスニペットは、条件付きアクセス認証コンテキストを使用したステップアップ認証の実行に関するページのコードサンプルです。 API の最初のメソッド CheckForRequiredAuthContext() は、以下を実行します。

呼び出されているアプリケーションのアクションにステップアップ認証が必要かどうかを確認します。そのために、このメソッド用に保存されたマッピングがデータベースにあるかどうかを確認します。
このアクションで昇格された認証コンテキストが実際に必要な場合は、既存の一致する認証コンテキスト ID があるか acrs 要求を確認します。
一致する認証コンテキスト ID が見つからない場合は、クレームチャレンジが発生します。

public void CheckForRequiredAuthContext(string method)
{
    string authType = _commonDBContext.AuthContext.FirstOrDefault(x => x.Operation == method
                && x.TenantId == _configuration["AzureAD:TenantId"])?.AuthContextId;

    if (!string.IsNullOrEmpty(authType))
    {
        HttpContext context = this.HttpContext;
        string authenticationContextClassReferencesClaim = "acrs";

        if (context == null || context.User == null || context.User.Claims == null
            || !context.User.Claims.Any())
        {
            throw new ArgumentNullException("No Usercontext is available to pick claims from");
        }

        Claim acrsClaim = context.User.FindAll(authenticationContextClassReferencesClaim).FirstOrDefault(x
            => x.Value == authType);

        if (acrsClaim == null || acrsClaim.Value != authType)
        {
            if (IsClientCapableofClaimsChallenge(context))
            {
                string clientId = _configuration.GetSection("AzureAd").GetSection("ClientId").Value;
                var base64str = Convert.ToBase64String(Encoding.UTF8.GetBytes("{\"access_token\":{\"acrs\":{\"essential\":true,\"value\":\"" + authType + "\"}}}"));

                context.Response.Headers.Append("WWW-Authenticate", $"Bearer realm=\"\", authorization_uri=\"https://login.microsoftonline.com/common/oauth2/authorize\", client_id=\"" + clientId + "\", error=\"insufficient_claims\", claims=\"" + base64str + "\", cc_type=\"authcontext\"");
                context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
                string message = string.Format(CultureInfo.InvariantCulture, "The presented access tokens had insufficient claims. Please request for claims requested in the WWW-Authentication header and try again.");
                context.Response.WriteAsync(message);
                context.Response.CompleteAsync();
                throw new UnauthorizedAccessException(message);
            }
            else
            {
                throw new UnauthorizedAccessException("The caller does not meet the authentication  bar to carry our this operation. The service cannot allow this operation");
            }
        }
    }
}

注意

クレームチャレンジの形式については、Microsoft Identity Platform のクレームチャレンジに関する記事で説明しています。

クライアントアプリケーションで、クレームチャレンジをインターセプトし、ユーザーを Microsoft Entra に再度リダイレクトして、さらにポリシーを評価します。次のコードスニペットは、条件付きアクセス認証コンテキストを使用したステップアップ認証の実行に関するページのコードサンプルです。

internal static string ExtractHeaderValues(WebApiMsalUiRequiredException response)
{
    if (response.StatusCode == System.Net.HttpStatusCode.Unauthorized && response.Headers.WwwAuthenticate.Any())
    {
        AuthenticationHeaderValue bearer = response.Headers.WwwAuthenticate.First(v => v.Scheme == "Bearer");
        IEnumerable<string> parameters = bearer.Parameter.Split(',').Select(v => v.Trim()).ToList();
        var errorValue = GetParameterValue(parameters, "error");

        try
        {
            // read the header and checks if it contains error with insufficient_claims value.
            if (null != errorValue && "insufficient_claims" == errorValue)
            {
                var claimChallengeParameter = GetParameterValue(parameters, "claims");
                if (null != claimChallengeParameter)
                {
                    var claimChallenge = ConvertBase64String(claimChallengeParameter);

                    return claimChallenge;
                }
            }
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    return null;
}

Web API の呼び出しで例外を処理します。クレームチャレンジが提示された場合、ユーザーを再び Microsoft Entra ID にリダイレクトして、さらに処理を行います。

try
{
    // Call the API
    await _todoListService.AddAsync(todo);
}
catch (WebApiMsalUiRequiredException hex)
{
    // Challenges the user if exception is thrown from Web API.
    try
    {
        var claimChallenge =ExtractHeaderValues(hex);
        _consentHandler.ChallengeUser(new string[] { "user.read" }, claimChallenge);

        return new EmptyResult();
    }
    catch (Exception ex)
    {
        _consentHandler.HandleException(ex);
    }

    Console.WriteLine(hex.Message);
}
return RedirectToAction("Index");

(省略可能) クライアントの機能を宣言します。クライアントの機能は、呼び出し元のクライアントアプリケーションがクレームチャレンジを認識し、それに応じて応答をカスタマイズできるかどうかをリソースプロバイダー (RP) (上記の Web API など) が検出するために役立ちます。この機能は、すべての API クライアントがクレームチャレンジを処理できるわけではなく、以前の一部のクライアントでは依然として別の応答が必要になる場合に便利であることがあります。詳細については、「クライアント機能」のセクションを参照してください。

注意事項と推奨事項

アプリで認証コンテキストの値をハードコーディングしないでください。アプリは、MS Graph 呼び出しを使用して、認証コンテキストの読み取りと適用を行う必要があります。この方法は、マルチテナントアプリケーションの場合に重要になります。認証コンテキストの値は、Microsoft Entra テナントによって異なり、Microsoft Entra ID 無料版では使用できません。アプリがコード内で認証コンテキストをクエリ、設定、使用する方法の詳細については、条件付きアクセス認証コンテキストを使用したステップアップ認証の実行に関する記事のコードサンプルを参照して、アプリがコード内で認証コンテキストをクエリ、設定、使用する方法について確認してください。

アプリ自体が条件付きアクセスポリシーのターゲットになる場合には認証コンテキストを使用しないでください。この機能は、アプリケーションの一部で、ユーザーが高いレベルの認証を満たす必要がある場合に最適です。

コードサンプル

条件付きアクセスの想定される動作における認証コンテキスト [ACR]

要求における認証コンテキストの明示的な充足

クライアントは、要求本文の要求を通じて、認証コンテキスト (ACRS) を持つトークンを明示的に要求できます。 ACRS が要求された場合、すべてのチャレンジが完了すれば、要求された ACRS を持つトークンの発行が条件付きアクセスによって許可されます。

テナントの条件付きアクセスによって認証コンテキストが保護されていない場合の想定される動作

ACRS 値に割り当てられたすべての条件付きアクセスポリシーが満たされている場合、条件付きアクセスはトークンの要求で ACRS を発行できます。 ACRS 値に条件付きアクセスポリシーが割り当てられていなくても、すべてのポリシー要件は満たされているため、要求は引き続き発行される可能性があります。

ACRS が明示的に要求された場合に想定される動作の概要表

ACRS の要求	ポリシーの適用	制御が満たされているか	要求に ACRS が追加されたか
はい	いいえ	イエス	イエス
イエス	はい	いいえ	番号
イエス	イエス	イエス	イエス
はい	ACRS で構成されたポリシーはない	はい	はい

日和見的な評価による暗黙的な認証コンテキストの充足

リソースプロバイダーは、オプションの "acrs" 要求をオプトインできます。条件付きアクセスは、Microsoft Entra ID への新しいトークンを取得するためのラウンドトリップを回避するために、日和見的に ACRS をトークン要求に追加しようと試みます。この評価では、条件付きアクセスによって認証コンテキストのチャレンジを保護するポリシーが既に満たされているかどうかの確認が行われ、満たされている場合はトークン要求に ACRS が追加されます。

Note

各トークンの種類は、個別にオプトインする必要があります (ID トークン、アクセストークン)。

リソースプロバイダーがオプションの "acrs" 要求をオプトインしない場合、トークンに ACRS を追加するには、トークン要求で明示的に要求するしかありません。日和見的な評価の利点は得られないため、必要な ACRS がトークン要求から欠落するたびに、リソースプロバイダーは、要求にある新しいトークンを取得するようクライアントに要求することになります。

暗黙的な ACRS の日和見的な評価における認証コンテキストとセッション制御で想定される動作

条件付きアクセスは、現在存在するすべての認証要素の認証インスタンスがサインイン頻度の間隔に収まっている場合、ACRS の日和見的な評価における "サインイン頻度 (間隔別)" が満たされていると見なします。第 1 要素認証のインスタンスが古い場合、または第 2 要素 (MFA) が存在し、その認証インスタンスが古い場合は、「間隔によるサインイン頻度」は満たされず、トークンへの日和見的な ACRS の発行は行われません。

Cloud App Security (CAS)

条件付きアクセスでは、その要求の間に CAS セッションが確立された場合、ACLS の日和見的な評価において CAS セッション制御が満たされているとみなします。たとえば、ある要求が届き、これに何らかの条件付きアクセスポリシーが適用されて CAS セッションが強制され、さらに CAS セッションを要求する条件付きアクセスポリシーがあった場合、CAS セッションが強制されるため、日和見的な評価の CAS セッション制御は満たされることになります。

テナントに認証コンテキストを保護する条件付きアクセスポリシーが含まれている場合の想定される動作

次の表は、ACRS が日和見的な評価によってトークンの要求に追加される、まれなすべてのケースを示しています。

ポリシー A: "c1" acrs を要求する際に、ユーザー "Ariel" を除くすべてのユーザーから MFA を要求します。 ポリシー B: "c2" または "c3" acrs を要求する際に、ユーザー "Jay" を除くすべてのユーザーをブロックします。

Flow	ACRS の要求	ポリシーの適用	制御が満たされているか	要求に ACRS が追加されたか
Ariel がアクセストークンを要求する	"c1"	なし	はい ("c1" の場合)。いいえ ("c2" と "c3" の場合)	"c1" (要求済み)
Ariel がアクセストークンを要求する	"c2"	ポリシー B	ポリシー B によってブロックされる	なし
Ariel がアクセストークンを要求する	なし	なし	はい ("c1" の場合)。いいえ ("c2" と "c3" の場合)	"c1" (ポリシー A から日和見的に追加)
Jay がアクセストークンを要求する (MFA なし)	"c1"	ポリシー A	いいえ	なし
Jay がアクセストークンを要求する (MFA あり)	"c1"	ポリシー A	はい	"c1" (要求済み)、"c2" (ポリシー B から日和見的に追加)、"c3" (ポリシー B から日和見的に追加)
Jay がアクセストークンを要求する (MFA なし)	"c2"	なし	はい ("c2" と "c3" の場合)。いいえ ("c1" の場合)	"c2" (要求済み)、"c3" (ポリシー B から日和見的に追加)
Jay がアクセストークンを要求する (MFA あり)	"c2"	なし	はい ("c1"、"c2"、"c3" の場合)	"c1" (A からのベストエフォート)、"c2" (要求済み)、"c3" (ポリシー B から日和見的に追加)
Jay がアクセストークンを要求する (MFA あり)	なし	なし	はい ("c1"、"c2"、"c3" の場合)	"c1"、"c2"、"c3" がすべて日和見的に追加
Jay がアクセストークンを要求する (MFA なし)	なし	なし	はい ("c2" と "c3" の場合)。いいえ ("c1" の場合)	"c2"、"c3" がすべて日和見的に追加

次の方法で共有

条件付きアクセス認証コンテキストに関する開発者ガイド

問題の説明

一般的なシナリオ

前提条件

統合手順

注意事項と推奨事項

コードサンプル

条件付きアクセスの想定される動作における認証コンテキスト [ACR]

要求における認証コンテキストの明示的な充足

テナントの条件付きアクセスによって認証コンテキストが保護されていない場合の想定される動作

ACRS が明示的に要求された場合に想定される動作の概要表

日和見的な評価による暗黙的な認証コンテキストの充足

暗黙的な ACRS の日和見的な評価における認証コンテキストとセッション制御で想定される動作

Cloud App Security (CAS)

テナントに認証コンテキストを保護する条件付きアクセスポリシーが含まれている場合の想定される動作

次のステップ

フィードバック

その他のリソース

次の方法で共有

条件付きアクセス認証コンテキストに関する開発者ガイド

問題の説明

一般的なシナリオ

前提条件

統合手順

注意事項と推奨事項

コード サンプル

条件付きアクセスの想定される動作における認証コンテキスト [ACR]

要求における認証コンテキストの明示的な充足

テナントの条件付きアクセスによって認証コンテキストが保護されていない場合の想定される動作

ACRS が明示的に要求された場合に想定される動作の概要表

日和見的な評価による暗黙的な認証コンテキストの充足

暗黙的な ACRS の日和見的な評価における認証コンテキストとセッション制御で想定される動作

サインイン頻度 (間隔別)

Cloud App Security (CAS)

テナントに認証コンテキストを保護する条件付きアクセス ポリシーが含まれている場合の想定される動作

次のステップ

フィードバック

その他のリソース

コードサンプル

テナントに認証コンテキストを保護する条件付きアクセスポリシーが含まれている場合の想定される動作