要求でディレクトリ スキーマ拡張属性を使用する

  • [アーティクル]

ディレクトリ スキーマ拡張属性を使用すると、Azure Active Directory で、ユーザー オブジェクトやその他のディレクトリ オブジェクト (グループ、テナントの詳細、サービス プリンシパルなど) に追加のデータを格納することができます。 アプリケーションに対する要求の出力に使用できるのは、ユーザー オブジェクトの拡張属性だけです。 この記事では、トークン要求でユーザー データをアプリケーションに送信するために、ディレクトリ スキーマ拡張属性を使用する方法について説明します。

Note

Microsoft Graph には、Graph オブジェクトをカスタマイズするための 2 つの拡張メカニズムが他に用意されています。 これらは Microsoft Graph オープン拡張と Microsoft Graph スキーマ拡張と呼ばれています。 詳細については、Microsoft Graph のドキュメントを参照してください。 これらの機能を使用して Microsoft Graph オブジェクトに格納されたデータは、トークン内の要求のソースとしては使用できません。

ディレクトリ スキーマ拡張属性は、常にテナント内のアプリケーションに関連付けられており、アプリケーションの名前が付いた applicationId で参照されます。

ディレクトリ スキーマ拡張属性の識別子は、Extension_xxxxxxxxx_AttributeName の形式です。 ここで xxxxxxxxx は、拡張機能が定義されたアプリケーションの applicationId です。

ディレクトリ スキーマ拡張の登録と使用

ディレクトリ スキーマ拡張属性は、次の 2 つの方法のいずれかで登録および設定できます。

AD Connect を使用して作成されたディレクトリ スキーマ拡張属性からのデータを使用して要求を出力する

AD Connect を使用して作成および同期されるディレクトリ スキーマ拡張属性は、AD Connect によって使用されるアプリケーション ID と常に関連付けられます。 これらは、Enterprise Applications の Gallery または Gallery 以外のアプリケーション構成エクスペリエンスを使用して登録された SAML アプリケーションにある Portal UI の Enterprise Applications 構成でそれらを要求として構成するか、アプリケーションの登録エクスペリエンスを使用して登録されたアプリケーションの要求のマッピング ポリシー経由で、要求のソースとして使用することができます。 AD Connect を使用して作成されたディレクトリ拡張属性がディレクトリ内にあると、SAML SSO 要求の構成 UI に表示されます。

Graph または PowerShell を使用してアプリケーション用に作成されたディレクトリ スキーマ拡張属性からのデータを使用して要求を出力する

Microsoft Graph または PowerShell を使用してアプリケーションにディレクトリ スキーマ拡張属性が登録された場合 (たとえば、アプリケーションの初期セットアップまたはプロビジョニング手順を使用)、ユーザーがサインインしたときに、ユーザー オブジェクトからその属性のデータを要求で受信するように Azure Active Directory で同じアプリケーションを構成できます。 このアプリケーションは、オプションの要求を使用して同じアプリケーションに登録されているディレクトリ スキーマ拡張でデータを受信するように構成できます。 これらは、アプリケーション マニフェストで設定できます。 これにより、マルチテナント アプリケーションで、独自に使用するディレクトリ スキーマ拡張属性を登録できます。 アプリケーションがテナントにプロビジョニングされると、関連付けられているディレクトリ スキーマ拡張が、そのテナント内のユーザーに設定でき、使用できるようになります。 これがテナントで構成され、同意が付与されると、Graph を使用してデータの格納と取得を行うことや、Microsoft ID プラットフォームからアプリケーションに出力されるトークン内の要求にマッピングすることができます。

ディレクトリ スキーマ拡張属性は、任意のアプリケーションに対して登録および設定できます。

別のアプリケーションに登録されている拡張属性からのデータを使用して、アプリケーションから要求を送信する必要がある場合は、要求のマッピング ポリシーを使用して、拡張属性を要求にマッピングする必要があります。 ディレクトリ スキーマ拡張属性を管理するための一般的なパターンは、必要なすべてのスキーマ拡張の登録ポイントとなる、専用のアプリケーションを作成することです。 これは実際のアプリケーションである必要はなく、この手法は、すべての拡張の名前に同じアプリケーション ID が含まれることを意味します。

たとえば、次に示すのは、OAuth/OIDC トークンのディレクトリ スキーマ拡張属性から 1 つの要求を生成するための要求のマッピング ポリシーです。

{
    "ClaimsMappingPolicy": {
        "Version": 1,
        "IncludeBasicClaimSet": "false",
        "ClaimsSchema": [{
                "Source": "User",
                "ExtensionID": "extension_xxxxxxx_test",
                "JWTClaimType": "http://schemas.contoso.com/identity/claims/exampleclaim"
            },
        ]
    }
}

ここで xxxxxxx は、拡張機能が登録されたアプリケーション ID です。

ヒント

オブジェクトのディレクトリ拡張属性を設定するときは、大文字と小文字の整合性が重要です。 拡張属性名は、設定時には大文字と小文字が区別されませんが、トークン サービスによってディレクトリから読み取られるときは大文字と小文字が区別されます。 "LegacyId" という名前のユーザー オブジェクトと、"legacyid" という名前の別のユーザー オブジェクトに拡張属性が設定された場合、"LegacyId" という名前を使用して属性が要求にマッピングされると、最初のユーザーのトークンではデータが正常に取得され、要求が含まれますが、2 番目のユーザーではこれが行われません。

組み込みのディレクトリ属性に使用される要求スキーマの "Id" パラメーターは、ディレクトリ拡張属性の "ExtensionID" です。

次のステップ