認証の概要

Power Platform アプリは 2 つの異なるドメインにまたがり、それぞれに個別の認証済みセッションが必要です。

フレームワークは、ブラウザー のストレージ状態 を 1 回取得し、すべてのテスト実行で再利用することで、両方のドメインを処理します。 この方法では、すべてのテストにログインすることが回避され、テスト スイートの期間が大幅に短縮されます。

Playwright でのストレージ状態のしくみ

Playwright の storageState 機能は、認証されたブラウザー セッションからすべての Cookie とローカル ストレージ (MSAL トークンを含む) をキャプチャし、JSON ファイルに保存します。 テストが開始されると、ブラウザー コンテキストはこの保存された状態で初期化され、対話型サインイン フローはバイパスされます。

フレームワークには、次の 2 つの状態ファイルが格納されます。

既定の保存場所: packages/e2e-tests/.playwright-ms-auth/

認証プロバイダー

フレームワークでは、次の 3 つの資格情報プロバイダーがサポートされています。

パスワード認証

証明書インフラストラクチャを使用できない場合は、ローカル開発にパスワード認証を使用します。

MS_AUTH_CREDENTIAL_TYPE=password
MS_USER_PASSWORD=<password>

証明書の認証

CI/CD パイプラインと共有環境に証明書認証を使用します。 この方法では、パスワードの格納を回避し、多要素シナリオをサポートします。

MS_AUTH_CREDENTIAL_TYPE=certificate
MS_AUTH_CREDENTIAL_PROVIDER=local-file
MS_AUTH_LOCAL_FILE_PATH=../../cert/<cert-file>.pfx
MS_AUTH_CERTIFICATE_PASSWORD=<optional-pfx-password>

Azure Key Vault

証明書を一元的に管理する運用パイプラインには、Azure Key Vaultを使用します。

MS_AUTH_CREDENTIAL_TYPE=certificate
MS_AUTH_CREDENTIAL_PROVIDER=azure-keyvault
AZURE_KEYVAULT_URL=https://<vault>.vault.azure.net/
AZURE_CERTIFICATE_NAME=<certificate-name>

認証状態のトークン検証と有効期限

各テストを実行する前に、フレームワークはストレージ状態ファイルを検証します。

• Power Apps state: localStorage からの MSAL アクセス トークンの有効期限を検証します
• MDA state: Dynamics 365 のセッションクッキーをCRMドメインから検証します。

状態ファイルの有効期限が切れている場合、フレームワークによって削除され、再認証を求められます。 CI/CD では、認証は globalSetup で実行され、すべてのパイプラインが実行される前に新しい状態が取得されます。

複数のテスト ユーザー

異なるユーザー アカウント (ロールベースのアクセスのテストなど) でテストを実行するには、 MS_AUTH_EMAIL を設定し、各ユーザーの認証スクリプトを実行して、個別のストレージ状態ファイルを作成します。

MS_AUTH_EMAIL=user1@contoso.com npm run auth:headful
MS_AUTH_EMAIL=user2@contoso.com npm run auth:headful

次に、テスト内の特定の状態ファイルを参照します。

test.use({
  storageState: getStorageStatePath('user1@contoso.com'),
});

セキュリティの考慮事項

• ストレージ状態ファイルにはセッション トークンが含まれています。 .playwright-ms-auth/に.gitignoreを追加します。
• テスト ユーザーの資格情報をローテーションし、定期的に再認証します。
• 必要最小限のアクセス許可を持つ専用のテスト アカウントを使用します。
• 運用 CI/CD の場合は、Azure Key Vaultに格納されている証明書で証明書認証を使用します。

次のステップ

• 認証ガイド 各資格情報プロバイダーの詳細な手順

こちらも参照ください

• 環境変数
• CI/CD 統合