Azure App Service 認証でユーザー ID を操作する

この記事では、Azure App Service で 組み込みの認証と承認 を使用する場合に、ユーザー ID を操作する方法について説明します。

[前提条件]

App Service の認証および承認モジュールが有効になっている Azure App Service で実行されている Web アプリケーション。

アプリ コードでユーザー クレームにアクセスする

アプリの認証されたエンド ユーザーまたはクライアント アプリケーションは、受信トークンで要求を行います。 App Service は、クレームを要求ヘッダーに注入して、コードで使用できるようにします。 外部要求は、これらのヘッダーの設定を許可されていないため、App Service によって設定された場合にのみ存在します。

App Service 認証で提供される要求情報を使用して、アプリ コードで承認チェックを実行できます。 任意の言語またはフレームワークのコードは、要求ヘッダーから必要な情報を取得できます。 一部のコード フレームワークには、より便利な追加オプションが用意されています。 フレームワーク固有の代替手段を参照してください。

次の表に、ヘッダーの例をいくつか示します。

同様のヘッダーは 、プロバイダー トークンを公開します。 たとえば、Microsoft Entra では、必要に応じて X-MS-TOKEN-AAD-ACCESS-TOKEN および X-MS-TOKEN-AAD-ID-TOKEN プロバイダー トークン ヘッダーを設定します。

クライアント プリンシパル ヘッダーをデコードする

X-MS-CLIENT-PRINCIPAL ヘッダーには、Base64 でエンコードされた JSON で使用可能な要求の完全なセットが含まれています。 このヘッダーを処理するには、アプリでペイロードをデコードし、 claims 配列を反復処理して関連する要求を見つける必要があります。

デコードされたペイロード構造は次のとおりです。

{
    "auth_typ": "",
    "claims": [
        {
            "typ": "",
            "val": ""
        }
    ],
    "name_typ": "",
    "role_typ": ""
}

次の表では、プロパティについて説明します。

便宜上、要求をアプリの言語フレームワークで使用される表現に変換できます。 次の C# の例では、アプリで使用する ClaimsPrincipal 型を構築します。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Claims;
using System.Text;
using System.Text.Json;
using System.Text.Json.Serialization;
using Microsoft.AspNetCore.Http;

public static class ClaimsPrincipalParser
{
    private class ClientPrincipalClaim
    {
        [JsonPropertyName("typ")]
        public string Type { get; set; }
        [JsonPropertyName("val")]
        public string Value { get; set; }
    }

    private class ClientPrincipal
    {
        [JsonPropertyName("auth_typ")]
        public string IdentityProvider { get; set; }
        [JsonPropertyName("name_typ")]
        public string NameClaimType { get; set; }
        [JsonPropertyName("role_typ")]
        public string RoleClaimType { get; set; }
        [JsonPropertyName("claims")]
        public IEnumerable<ClientPrincipalClaim> Claims { get; set; }
    }

    public static ClaimsPrincipal Parse(HttpRequest req)
    {
        var principal = new ClientPrincipal();

        if (req.Headers.TryGetValue("x-ms-client-principal", out var header))
        {
            var data = header[0];
            var decoded = Convert.FromBase64String(data);
            var json = Encoding.UTF8.GetString(decoded);
            principal = JsonSerializer.Deserialize<ClientPrincipal>(json, new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
        }

この時点で、コードは principal.Claims を反復処理して、検証の一環として要求を確認できます。 または、 principal.Claims を標準オブジェクトに変換し、それを使用して、後で要求パイプラインでこれらのチェックを行うこともできます。 また、そのオブジェクトを使用して、ユーザー データを関連付け、その他の用途に使用することもできます。

関数の残りの部分では、この変換を実行して、他の .NET コードで使用できる ClaimsPrincipal を作成します。

        var identity = new ClaimsIdentity(principal.IdentityProvider, principal.NameClaimType, principal.RoleClaimType);
        identity.AddClaims(principal.Claims.Select(c => new Claim(c.Type, c.Value)));
        
        return new ClaimsPrincipal(identity);
    }
}

フレームワークごとの代替方法

• ASP.NET 4.6 アプリの場合、App Service は認証されたユーザーの要求を ClaimsPrincipal.Current に設定します。 [Authorize]属性を含め、標準の .NET コード パターンに従うことができます。

  ClaimsPrincipal.Currentは Azure Functions の .NET コード用に設定されていませんが、要求ヘッダーでユーザー要求を見つけたり、要求コンテキストまたはバインド パラメーターを使用してClaimsPrincipalオブジェクトを取得したりできます。 詳細については、「 Azure Functions でのクライアント ID の操作」を参照してください。

• PHP アプリの場合、App Service も同様に _SERVER['REMOTE_USER'] 変数を設定します。

• Java アプリの場合、要求には Tomcat サーブレットからアクセスできます。

• .NET Core の場合、 Microsoft.Identity.Web では、現在のユーザーに App Service 認証を設定できます。 詳細については、「 Microsoft.Identity.Web で実行されている Web アプリの Azure App Services 認証との統合」を参照してください。 Microsoft Graph にアクセスする Web アプリのデモについては、「 チュートリアル: セキュリティで保護された .NET アプリからユーザーとして Microsoft Graph にアクセスする」を参照してください。

API を使用してユーザー要求にアクセスする

トークン ストアがアプリに対して有効になっている場合は、/.auth/meを呼び出して、認証されたユーザーに関するその他の詳細を取得することもできます。

関連コンテンツ

• Azure App Service および Azure Functions での認証と承認
• チュートリアル: エンド ツー エンドでユーザーを認証および承認する