Azure AD B2C で API コネクタとして使用される API をセキュリティで保護する

Azure AD B2C ユーザー フロー内で REST API を統合する場合は、認証を使用して REST API エンドポイントを保護する必要があります。 REST API 認証により、Azure AD B2C などの適切な資格情報を持つサービスだけが REST API エンドポイントを呼び出すことができます。 この記事では、REST API をセキュリティで保護する方法について説明します。

必須コンポーネント

チュートリアル「API コネクタをサインアップ ユーザー フローに追加する」ガイドの手順を完了している。

API エンドポイントを保護するには、HTTP 基本認証または HTTPS クライアント証明書認証を使用します。 どちらの場合も、API エンドポイントを呼び出すときに Azure AD B2C によって使用される資格情報を指定します。 次に、API エンドポイントは資格情報を確認し、承認の決定を行います。

HTTP 基本認証

HTTP 基本認証は RFC 2617 で定義されています。 基本認証は、次のように動作します。Azure AD B2C によって、クライアントの資格情報 (usernamepassword) が Authorization ヘッダーに含まれた HTTP 要求が送信されます。 資格情報は、Base64 でエンコードされた文字列 username:password として書式設定されます。 その後、お使いの API によってこれらの値がチェックされ、他の承認決定が実行されます。

HTTP 基本認証を使用して API コネクタを構成するには、次の手順を実行します。

  1. Azure portal にサインインします。
  2. [Azure サービス] で、B2C Azure AD選択するか、B2Cを検索Azure AD選択します
  3. [API コネクタ] を選択し、構成する [API コネクタ] を選択します。
  4. [認証の種類] で、 [基本] を選択します。
  5. REST API エンドポイントの [ユーザー名][パスワード] を指定します。 Providing basic authentication configuration for an API connector.
  6. [保存] を選択します。

REST API ユーザー名とパスワードのポリシーのキーを追加する

HTTP 基本認証を使用して REST API の技術プロファイルを構成するには、ユーザー名とパスワードを格納するために次の暗号化キーを作成します。

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページで Azure AD B2C ディレクトリを [ディレクトリ名] リストで見つけ、 [Switch] を選択します。
  4. Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
  5. [概要] ページで、 [Identity Experience Framework] を選択します。
  6. [ポリシー キー] を選択し、 [追加] を選択します。
  7. [オプション] には [手動] を選択します。
  8. [名前] に「RestApiUsername」と入力します。 プレフィックス B2C_1A_ が自動的に追加される場合があります。
  9. [秘密] ボックスに、REST API ユーザー名を入力します。
  10. [キー使用法] には [暗号化] を選択します。
  11. [作成] を選択します
  12. [ポリシー キー] を再度選択します。
  13. [追加] を選択します。
  14. [オプション] には [手動] を選択します。
  15. [名前] に「RestApiPassword」と入力します。 プレフィックス B2C_1A_ が自動的に追加される場合があります。
  16. [秘密] ボックスに、REST API パスワードを入力します。
  17. [キー使用法] には [暗号化] を選択します。
  18. [作成] を選択します

HTTP 基本認証を使用するように REST API の技術プロファイルを構成する

必要なキーを作成した後、資格情報を参照するように REST API の技術プロファイル メタデータを構成します。

  1. 作業ディレクトリで、拡張ポリシー ファイル (TrustFrameworkExtensions.xml) を開きます。
  2. REST API の技術プロファイルを検索します。 例: REST-ValidateProfile、または REST-GetProfile
  3. <Metadata> 要素を見つけます。
  4. AuthenticationTypeBasic に変更します。
  5. AllowInsecureAuthInProductionfalse に変更します。
  6. </Metadata> 要素の終了直後に、次の XML スニペットを追加します。
    <CryptographicKeys>
        <Key Id="BasicAuthenticationUsername" StorageReferenceId="B2C_1A_RestApiUsername" />
        <Key Id="BasicAuthenticationPassword" StorageReferenceId="B2C_1A_RestApiPassword" />
    </CryptographicKeys>
    

HTTP 基本認証を使用して構成された RESTful 技術プロファイルの例を次の XML スニペットに示します。

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">Basic</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="BasicAuthenticationUsername" StorageReferenceId="B2C_1A_RestApiUsername" />
        <Key Id="BasicAuthenticationPassword" StorageReferenceId="B2C_1A_RestApiPassword" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

HTTPS クライアント証明書認証

クライアント証明書の認証は証明書ベースの相互認証であり、クライアントである Azure AD B2C がクライアント証明書をサーバーに提供し、その ID を証明します。 これは、SSL ハンドシェイクの一部として発生します。 お使いの API によって、証明書が有効なクライアント (Azure AD B2C など) に属していることが確認され、承認の決定が実行されます。 クライアント証明書は、X.509 デジタル証明書です。

重要

運用環境では、この証明書は証明機関によって署名されている必要があります。

証明書を作成する

証明書を作成するには、Azure Key Vault を使用できます。これには、自己署名証明書のオプションと、署名された証明書の証明書発行者プロバイダーとの統合があります。 推奨設定には次が含まれます。

  • [サブジェクト] : CN=<yourapiname>.<tenantname>.onmicrosoft.com
  • [コンテンツの種類] : PKCS #12
  • [有効期間のアクション タイプ] : Email all contacts at a given percentage lifetime または Email all contacts a given number of days before expiry
  • [キーの種類] : RSA
  • [キー サイズ] : 2048
  • エクスポート可能な秘密キー: Yes (.pfx ファイルをエクスポートできるようにするため)

これで、証明書をエクスポートできます。

オプション 2: PowerShell モジュールを使用して自己署名証明書を準備する

証明書をまだ持っていない場合は、自己署名証明書を使用できます。 自己署名証明書は、証明機関 (CA) によって署名されていないセキュリティ証明書であり、CA によって署名された証明書のセキュリティ保証を提供するものではありません。

Windows では、PowerShell の New-SelfSignedCertificate コマンドレットを使用して証明書を生成します。

  1. この PowerShell コマンドを実行して、自己署名証明書を生成します。 contosowebapp.contoso.onmicrosoft.com などのアプリケーションと Azure AD B2C のテナント名に合わせて -Subject 引数を変更します。 また、証明書に別の有効期限を指定するように -NotAfter 日付を調整することもできます。

    New-SelfSignedCertificate `
        -KeyExportPolicy Exportable `
        -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
        -KeyAlgorithm RSA `
        -KeyLength 2048 `
        -KeyUsage DigitalSignature `
        -NotAfter (Get-Date).AddMonths(12) `
        -CertStoreLocation "Cert:\CurrentUser\My"
    
  2. Windows コンピューターで、 [ユーザー証明書の管理] を検索して選択します

  3. [証明書 - 現在のユーザー] で、 [個人用]>[証明書]>yourappname.yourtenant.onmicrosoft.com を開きます。

  4. 証明書を選択し、 [アクション]>[すべてのタスク]>[エクスポート] の順に選択します。

  5. [次へ]>[はい、秘密キーをエクスポートします]>[次へ] を選択します。

  6. [エクスポート ファイルの形式] の既定値を受け入れて、 [次へ] を選択します。

  7. [パスワード] オプションを有効にして、証明書のパスワードを入力し、 [次へ] を選択します。

  8. 証明書を保存する場所を指定するには、 [参照] を選択し、任意のディレクトリに移動します。

  9. [名前を付けて保存] ウィンドウで、 [ファイル名] を入力して、 [保存] を選択します。

  10. [次へ]>[完了] の順に選択します。

Azure AD B2C で .pfx ファイルのパスワードを受け入れるには、Windows 証明書ストアのエクスポート ユーティリティで、AES256-SHA256 ではなく、TripleDES-SHA1 オプションを使用してパスワードを暗号化する必要があります。

API コネクタを構成する

クライアント証明書認証を使用して API コネクタを構成するには、次の手順を実行します。

  1. Azure portal にサインインします。
  2. [Azure サービス] で、 [Azure AD B2C] を選択します。
  3. [API コネクタ] を選択し、構成する [API コネクタ] を選択します。
  4. [認証の種類][証明書] を選択します。
  5. [証明書のアップロード] ボックスで、秘密キーを備えた証明書の .pfx ファイルを選択します。
  6. [パスワードの入力] ボックスに、証明書のパスワードを入力します。 Providing certificate authentication configuration for an API connector.
  7. [保存] を選択します。

承認の決定を実行する

API エンドポイントを保護するために、API では、送信されたクライアント証明書に基づいて承認が実装される必要があります。 Azure App Service と Azure Functions については、TLS 相互認証の構成に関するページで、API コードから証明書を有効化および検証する方法をご覧ください。 または、Azure API Management をすべての API サービスの前のレイヤーとして使用して、クライアント証明書のプロパティを目的の値と照合することもできます。

証明書を書き換える

証明書の有効期限がまもなく切れることを知らせるリマインダー アラートを設定することをお勧めします。 使用されている証明書の有効期限が迫っている場合は、新しい証明書を生成し、上の手順を繰り返す必要があります。 新しい証明書の使用を "ロール" するために、新しい証明書がデプロイされている間、一時的に、お使いの API サービスで引き続き古い証明書と新しい証明書を受け入れることができます。

既存の API コネクタに新しい証明書をアップロードするには、 [API コネクタ] で API コネクタを選択し、 [新しい証明書のアップロード] をクリックします。 直近でアップロードされ、開始日を過ぎていて有効期限が切れていない証明書が、Azure AD B2C によって自動的に使用されます。

Providing a new certificate to an API connector when one already exists.

クライアント証明書ポリシー キーを追加する

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページで Azure AD B2C ディレクトリを [ディレクトリ名] リストで見つけ、 [Switch] を選択します。
  4. Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
  5. [概要] ページで、 [Identity Experience Framework] を選択します。
  6. [ポリシー キー] を選択し、 [追加] を選択します。
  7. [オプション] ボックスで、 [アップロード] を選択します。
  8. [名前] ボックスに「RestApiClientCertificate」と入力します。 プレフィックス B2C_1A_ が自動的に追加されます。
  9. [ファイルのアップロード] ボックスで、秘密キーを備えた証明書の .pfx ファイルを選択します。
  10. [パスワード] ボックスに、証明書のパスワードを入力します。
  11. [作成] を選択します

クライアント証明書認証を使用するように REST API の技術プロファイルを構成する

必要なキーを作成した後、クライアント証明書を参照するように REST API の技術プロファイル メタデータを構成します。

  1. 作業ディレクトリで、拡張ポリシー ファイル (TrustFrameworkExtensions.xml) を開きます。
  2. REST API の技術プロファイルを検索します。 例: REST-ValidateProfile、または REST-GetProfile
  3. <Metadata> 要素を見つけます。
  4. AuthenticationTypeClientCertificate に変更します。
  5. AllowInsecureAuthInProductionfalse に変更します。
  6. </Metadata> 要素の終了直後に、次の XML スニペットを追加します。
    <CryptographicKeys>
       <Key Id="ClientCertificate" StorageReferenceId="B2C_1A_RestApiClientCertificate" />
    </CryptographicKeys>
    

HTTP クライアント証明書を使用して構成された RESTful 技術プロファイルの例を次の XML スニペットに示します。

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">ClientCertificate</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="ClientCertificate" StorageReferenceId="B2C_1A_RestApiClientCertificate" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

OAuth2 ベアラー認証

注意

この機能はパブリック プレビュー段階にあります。

ベアラー トークン認証の定義については、「OAuth 2.0 Authorization Framework:Bearer Token Usage (RFC 6750)」(OAuth 2.0 承認フレームワーク: ベアラー トークンの使用法 (RFC 6750)) をご覧ください。 ベアラー トークン認証では、Azure AD B2C は、Authorization ヘッダーにトークンを含む HTTP 要求を送信します。

Authorization: Bearer <token>

ベアラー トークンは、不透明な文字列です。 これは、JWT アクセス トークン、または REST API が Azure AD B2C によって Authorization ヘッダーで送信されることを想定する任意の文字列です。 Azure AD B2C では、次の種類がサポートされています。

  • ベアラー トークン。 ベアラー トークンを Restful 技術プロファイルで送信できるようにするには、ポリシーでベアラー トークンを取得してから、それを RESTful 技術プロファイルで使用する必要があります。
  • 静的ベアラー トークン。 REST API が長期アクセス トークンを発行する場合に、このアプローチを使用します。 静的ベアラー トークンを使用するには、ポリシー キーを作成し、RESTful 技術プロファイルからポリシー キーへの参照を作成します。

OAuth2 ベアラーの使用

次の手順では、クライアント資格情報を使用してベアラー トークンを取得し、それを REST API 呼び出しの Authorization ヘッダーに渡す方法について説明します。

ベアラー トークンを格納する要求を定義する

要求は、Azure AD B2C ポリシーの実行時に、データの一時的なストレージとなります。 要求スキーマは、要求を宣言する場所です。 アクセス トークンは、後で使用するために、要求に格納する必要があります。

  1. お使いのポリシーの拡張ファイルを開きます。 たとえば、「 SocialAndLocalAccounts/TrustFrameworkExtensions.xml 」のように入力します。
  2. BuildingBlocks 要素を検索します。 要素が存在しない場合は追加します。
  3. ClaimsSchema 要素を見つけます。 要素が存在しない場合は追加します。
  4. 次の要求を ClaimsSchema 要素に追加します。
<ClaimType Id="bearerToken">
  <DisplayName>Bearer token</DisplayName>
  <DataType>string</DataType>
</ClaimType>
<ClaimType Id="grant_type">
  <DisplayName>Grant type</DisplayName>
  <DataType>string</DataType>
</ClaimType>
<ClaimType Id="scope">
  <DisplayName>scope</DisplayName>
  <DataType>string</DataType>
</ClaimType>

アクセス トークンの取得

アクセス トークンは、フェデレーション ID プロバイダーから取得する方法、アクセス トークンを返す REST API を呼び出す方法、ROPC フローを使用する方法、またはクライアント資格情報フローを使用する方法のいずれかで取得できます。 クライアント資格情報フローは、一般的にバックグラウンドでの実行が必要なサーバー間の相互作用に使用され、ユーザーとの即時の相互動作は必要ありません。

Azure AD アクセス トークンの取得

次の例では、REST API の技術プロファイルを使用し、HTTP 基本認証として渡されたクライアント資格情報を使用して Azure AD トークン エンドポイントに要求を行います。 詳しくは、「Microsoft ID プラットフォームと OAuth 2.0 クライアント資格情報フロー」をご覧ください。

技術プロファイルがアクセストークンを取得するために Azure AD と対話できるようにするには、アプリケーションを登録する必要があります。 Azure AD B2C は、Azure AD プラットフォームに依存しています。 アプリは、Azure AD B2C テナント、または管理する任意の Azure AD テナントで作成できます。 アプリケーションを登録するには、以下を行います。

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページの [ディレクトリ名] の一覧で自分の Azure AD または Azure AD B2C ディレクトリを見つけて、 [切り替え] を選択します。
  4. 左側のメニューで、 [Azure Active Directory] を選択します。 または、 [すべてのサービス] を選択してから、 [Azure Active Directory] を検索して選択します。
  5. [アプリの登録] を選択し、 [新規登録] を選択します。
  6. アプリケーションの名前を入力します。 たとえば、Client_Credentials_Auth_app のように入力します。
  7. [サポートされているアカウントの種類] で、 [この組織のディレクトリ内のアカウントのみ] を選択します。
  8. [登録] を選択します。
  9. [アプリケーション (クライアント) ID] を記録します。

クライアント資格情報フローの場合は、アプリケーション シークレットを作成する必要があります。 クライアント シークレットは、"アプリケーション パスワード" とも呼ばれます。 このシークレットは、アクセス トークンを取得するためにアプリケーションによって使用されます。

  1. [Azure AD - アプリの登録] ページで、作成したアプリケーション (例: Client_Credentials_Auth_app) を選択します。
  2. 左側のメニューで、[管理][証明書とシークレット] を選択します。
  3. [新しいクライアント シークレット] を選択します。
  4. [説明] ボックスにクライアント シークレットの説明を入力します。 たとえば、clientsecret1 のようにします。
  5. [有効期限] で、シークレットが有効な期間を選択してから、 [追加] を選択します。
  6. クライアント アプリケーションのコードで使用できるように、シークレットのを記録します。 このページからの移動後は、このシークレットの値は "二度と表示されません"。 アプリケーションのコード内で、この値をアプリケーション シークレットとして使用します。

Azure AD B2C ポリシー キーの作成

Azure AD B2C テナントで前に記録したクライアント ID およびクライアント シークレット値を格納する必要があります。

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページで Azure AD B2C ディレクトリを [ディレクトリ名] リストで見つけ、 [Switch] を選択します。
  4. Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
  5. [概要] ページで、 [Identity Experience Framework] を選択します。
  6. [ポリシー キー] を選択し、 [追加] を選択します。
  7. オプションについては、Manualを選択します。
  8. ポリシー キーの名前を入力します (SecureRESTClientId)。 プレフィックス B2C_1A_ がキーの名前に自動的に追加されます。
  9. [シークレット] に、前に記録したクライアント ID を入力します。
  10. [キー使用法] として [Signature] を選択します。
  11. [作成] を選択します
  12. 次の設定で別のポリシー キーを作成します。
    • [名前] : SecureRESTClientSecret
    • [シークレット] : 前に記録したクライアント シークレットを入力します

ServiceUrl で、your-tenant-name を Azure AD テナントの名前に置き換えます。 使用可能なすべてのオプションについては、RESTful 技術プロファイルのリファレンスを参照してください。

<TechnicalProfile Id="REST-AcquireAccessToken">
  <DisplayName></DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token</Item>
    <Item Key="AuthenticationType">Basic</Item>
     <Item Key="SendClaimsIn">Form</Item>
  </Metadata>
  <CryptographicKeys>
    <Key Id="BasicAuthenticationUsername" StorageReferenceId="B2C_1A_SecureRESTClientId" />
    <Key Id="BasicAuthenticationPassword" StorageReferenceId="B2C_1A_SecureRESTClientSecret" />
  </CryptographicKeys>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="client_credentials" AlwaysUseDefaultValue="true" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="https://graph.microsoft.com/.default" AlwaysUseDefaultValue="true" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="bearerToken" PartnerClaimType="access_token" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

注意

その他の技術プロファイルで grant_type または scope 要求を使用する場合、さらに DefaultValue を指定し、AlwaysUseDefaultValue="true" を使用することで、正しくない値をバインドして競合が発生する可能性を回避することをお勧めします。

ベアラー トークン認証を使用するように REST 技術プロファイルを変更する

カスタム ポリシーでベアラー トークン認証をサポートするには、REST API の技術プロファイルを次のように変更します。

  1. 作業ディレクトリで、TrustFrameworkExtensions.xml 拡張ポリシー ファイルを開きます。

  2. Id="REST-API-SignUp" を含む <TechnicalProfile> ノードを探します。

  3. <Metadata> 要素を見つけます。

  4. 次のように、AuthenticationTypeBearer に変更します。

    <Item Key="AuthenticationType">Bearer</Item>
    
  5. 次のように、UseClaimAsBearerTokenbearerToken に変更または追加します。 bearerToken は、ベアラー トークンの取得元になる要求の名前 (REST-AcquireAccessToken からの出力要求) です。

    <Item Key="UseClaimAsBearerToken">bearerToken</Item>
    
  6. 上記で使用した要求を入力要求として追加します。

    <InputClaim ClaimTypeReferenceId="bearerToken"/>
    

上記のスニペットを追加すると、技術プロファイルは次の XML コードのようになります。

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">Bearer</Item>
        <Item Key="UseClaimAsBearerToken">bearerToken</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="bearerToken"/>
      </InputClaims>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

REST 技術プロファイルを呼び出す

REST-GetProfile 技術プロファイルを呼び出すには、まず REST-AcquireAccessToken 技術プロファイルを使用して Azure AD アクセス トークンを取得する必要があります。 次の例は、検証技術プロファイルから REST-GetProfile 技術プロファイルを呼び出す方法を示しています。

<ValidationTechnicalProfiles>
  <ValidationTechnicalProfile ReferenceId="REST-AcquireAccessToken" />
  <ValidationTechnicalProfile ReferenceId="REST-GetProfile" />
</ValidationTechnicalProfiles>

次の例は、ユーザー体験またはサブ体験から REST-GetProfile 技術プロファイルを呼び出す方法を示しています。

<OrchestrationSteps>
  <OrchestrationStep Order="2" Type="ClaimsExchange">
    <ClaimsExchanges>
      <ClaimsExchange Id="REST-AcquireAccessTokens" TechnicalProfileReferenceId="REST-AcquireAccessToken" />
    </ClaimsExchanges>
  </OrchestrationStep>

  <OrchestrationStep Order="3" Type="ClaimsExchange">
    <ClaimsExchanges>
      <ClaimsExchange Id="REST-GetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
    </ClaimsExchanges>
  </OrchestrationStep>
</OrchestrationSteps>

静的 OAuth2 ベアラーの使用

OAuth2 ベアラー トークン ポリシー キーを追加する

OAuth2 ベアラー トークンを使用して REST API の技術プロファイルを構成するには、REST API 所有者からアクセス トークンを取得します。 次に、ベアラー トークンを格納するための次の暗号化キーを作成します。

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページで Azure AD B2C ディレクトリを [ディレクトリ名] リストで見つけ、 [Switch] を選択します。
  4. Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
  5. [概要] ページで、 [Identity Experience Framework] を選択します。
  6. [ポリシー キー] を選択し、 [追加] を選択します。
  7. オプションについては、Manualを選択します。
  8. ポリシー キーの名前を入力します。 たとえば、「 RestApiBearerToken 」のように入力します。 プレフィックス B2C_1A_ がキーの名前に自動的に追加されます。
  9. [シークレット] に、前に記録したクライアント シークレットを入力します。
  10. [キー使用法] として [Encryption] を選択します。
  11. [作成] を選択します

ベアラー トークン ポリシー キーを使用するように REST API の技術プロファイルを構成する

必要なキーを作成した後、ベアラー トークンを参照するように REST API の技術プロファイル メタデータを構成します。

  1. 作業ディレクトリで、拡張ポリシー ファイル (TrustFrameworkExtensions.xml) を開きます。
  2. REST API の技術プロファイルを検索します。 例: REST-ValidateProfile、または REST-GetProfile
  3. <Metadata> 要素を見つけます。
  4. AuthenticationTypeBearer に変更します。
  5. AllowInsecureAuthInProductionfalse に変更します。
  6. </Metadata> 要素の終了直後に、次の XML スニペットを追加します。
    <CryptographicKeys>
       <Key Id="BearerAuthenticationToken" StorageReferenceId="B2C_1A_RestApiBearerToken" />
    </CryptographicKeys>
    

ベアラー トークン認証を使用して構成された RESTful 技術プロファイルの例を次の XML スニペットに示します。

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">Bearer</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="BearerAuthenticationToken" StorageReferenceId="B2C_1A_RestApiBearerToken" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

検証技術プロファイルの参照を、REST-AcquireAccessToken を呼び出すサインアップ技術プロファイルに追加します。 この動作は、検証が成功した後にのみ、Azure AD B2C がディレクトリにアカウントを作成することを意味します。

例: XML <ValidationTechnicalProfiles> .... <ValidationTechnicalProfile ReferenceId="REST-AcquireAccessToken" /> .... </ValidationTechnicalProfiles>

API キー認証

一部のサービスは、"API キー" メカニズムを使用して、呼び出し元に HTTP ヘッダーまたは HTTP クエリ パラメーターとして一意のキーを含めることを要求することにより、開発中に HTTP エンドポイントへのアクセスを難読化します。 Azure Functions に対しては、お使いの API コネクタのエンドポイント URLcode をクエリ パラメーターとして含めることで、これを実現できます。 たとえば、https://contoso.azurewebsites.net/api/endpoint?code=0123456789 です。

これは、運用環境で単独で使用する必要があるメカニズムではありません。 そのため、基本認証または証明書認証の構成は常に必要です。 開発上の目的により、いずれの認証方法も実装しない場合 (推奨されません)、API コネクタの構成で "基本" 認証を選択し、適切な承認を実装する間、API が無視できる一時的な値を usernamepassword に使用します。

API キーは、REST API エンドポイントにアクセスするユーザーを認証するために使用される一意の識別子です。 キーはカスタム HTTP ヘッダーで送信されます。 たとえば、Azure Functions HTTP トリガーは、x-functions-key HTTP ヘッダーを使用して要求者を識別します。

API キーのポリシー キーを追加する

API キー認証を使用して REST API の技術プロファイルを構成するには、API キーを格納するために次の暗号化キーを作成します。

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページで Azure AD B2C ディレクトリを [ディレクトリ名] リストで見つけ、 [Switch] を選択します。
  4. Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
  5. [概要] ページで、 [Identity Experience Framework] を選択します。
  6. [ポリシー キー] を選択し、 [追加] を選択します。
  7. [オプション] には [手動] を選択します。
  8. [名前] に「RestApiKey」と入力します。 プレフィックス B2C_1A_ が自動的に追加される場合があります。
  9. [秘密] ボックスに、REST API キーを入力します。
  10. [キー使用法] には [暗号化] を選択します。
  11. [作成] を選択します

API キー認証を使用するように REST API の技術プロファイルを構成する

必要なキーを作成した後、資格情報を参照するように REST API の技術プロファイル メタデータを構成します。

  1. 作業ディレクトリで、拡張ポリシー ファイル (TrustFrameworkExtensions.xml) を開きます。
  2. REST API の技術プロファイルを検索します。 例: REST-ValidateProfile、または REST-GetProfile
  3. <Metadata> 要素を見つけます。
  4. AuthenticationTypeApiKeyHeader に変更します。
  5. AllowInsecureAuthInProductionfalse に変更します。
  6. </Metadata> 要素の終了直後に、次の XML スニペットを追加します。
    <CryptographicKeys>
        <Key Id="x-functions-key" StorageReferenceId="B2C_1A_RestApiKey" />
    </CryptographicKeys>
    

暗号化キーの ID によって、HTTP ヘッダーが定義されます。 この例では、API キーは x-functions-key として送信されます。

API キー認証で Azure 関数を呼び出すように構成された RESTful 技術プロファイルの例を次の XML スニペットに示します。

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">ApiKeyHeader</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="x-functions-key" StorageReferenceId="B2C_1A_RestApiKey" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

次のステップ