Entra IDサインイン設定

Power Portals Proは、ASP.NET Coreの標準 AddMicrosoftAccount プロバイダーを通じてユーザーをMicrosoftにサインインさせます。Microsoft Entra IDでの アプリ登録 が必要です。登録はEntraに、ポータルがサインインを要求できること、ユーザーを戻す場所、そしてどの認証情報で自己を証明するかを知らせます。このページでは、ポータルが実際に依存するすべてのプロパティを順に説明します。

これはDataverseの接続アプリではありません

典型的なポータルでは2つの別々の登録が関わっており、混同するのは最初の実行でよくあるミスです。 Dataverseの接続 アプリはサービスプリンシパルで、ポータル自体と同じようにデータを読み書きし、その認証情報は D365:ClientId / D365:ClientSecretの分類に分類されます。このページで説明されている登録はユーザーの サインイン専用で、認証情報は Authentication:Microsoft:ClientId / ClientSecretの下に分類されます。2つの登録を使いましょう。それぞれ異なるプロパティが必要で、漏洩した場合の爆発範囲も大きく異なります。

1. 申請書の登録

Microsoft Entra管理センターで登録を作成します。テナント内で少なくともアプリケーション開発者の役割が必要です。

1. Entra管理センターにサインインし、複数のテナントに属している場合は 設定アイコンを使って 登録を所有しているはずのテナントに切り替えてください。アプリ登録はその後、テナント間で移動することはできません。
2. Entra ID>アプリの登録をブラウズし、「新しい登録」を選択してください。
3. 例えば 名前を入力してください。例えば Contoso Portal Sign-In。ユーザーは同意画面でこの名前を見るので、ポータルとして認識できる名前にしてください。後で変更可能です。
4. 「サポートアカウントタイプ」の中で、ポータルに合ったオーディエンスを選択します — 下の表を参照してください。これは誰がサインインできるかを決定するプロパティです。
5. 登録を選択します。
6. 概要ページでアプリケーション(クライアント)IDをコピーします。その値はAuthentication:Microsoft:ClientIdになります。

サポートアカウントの種類の選択

この設定はポータルの正面ドアです。サインインが必要な全員をカバーできる範囲内で最も狭いオプションを選びます。

注記

Microsoftの ASP.NET コアプロバイダーは常にマルチオーディエンス /common/ エンドポイントに対して承認されるため、登録の 「サポートされたアカウントタイプ 」設定が、実際にそのアカウントを受け入れるか拒否するかを決定するのはアプリケーションコードではありません。もしアカウントが AADSTS50020で拒否された場合、登録対象は意図した対象よりも狭くなります。

2. リダイレクトURIを追加する

サインインが成功すると、Entraはプロバイダーのコールバックパス( /signin-microsoft)でユーザーをポータルに戻します。Entraは事前登録済みのアドレスにのみリダイレクトするため、ポータルが動作する各ホストにはそれぞれのエントリーが必要です。

1. 管理の下から認証を開き、プラットフォームを追加を選択します。
2. ウェブ プラットフォームを 選び、 シングルページアプリケーションではなく。ポータルサーバーはクライアントシークレットを使ってトークン交換を行い、これはBlazor WebAssemblyやReactホストでも同様で、サインインは依然としてサーバーサイドで処理されます。
3. ポータルのアドレスを入力し、その後に「 /signin-microsoft」を入力してください。
4. これをすべての環境で繰り返します。 launchSettings.json の開発URLと各デプロイされたホストはそれぞれ独自のリダイレクトURIが必要です。1つの登録を共有することもできるし、環境ごとに別々の登録を保持することもできます。

重要

リダイレクトURIはポータルが送るもの、すなわちスキーム、ホスト、ポート、パスと正確に一致しなければなりません。https://localhost:7228/signin-microsoftとhttps://localhost:7228/signin-microsoft/は同じアドレスではなく、また異なるポートでもありません。Entraはlocalhost以外のすべてのアドレスに1httpsを必要とします。

ポータルがリバースプロキシ、ロードバランサー、コンテナ入力でTLSを終了する場合は、ASP.NET Coreの転送ヘッダーミドルウェアを設定してください。これがなければ、アプリはリクエストが単なるHTTP経由で届いたと誤認し、登録されたhttps://と一致しないhttp://リダイレクトURIを構築します。

3. クライアントシークレットを作成する

秘密は、認証コードをトークンと交換することで、ポータルが本当に登録されたアプリケーションであることを証明する方法です。

1. 「Management」の「Certificates and secrets」を開いて「Clients secrets」タブを選択してください。
2. 「新しいクライアントシークレット」を選択し、環境名を付ける説明(例:portal-production)を付け、有効期限を選択します。
3. Value列をすぐにコピーしてください — Secret IDではなく。値は一度だけ表示され、Authentication:Microsoft:ClientSecretになります。

重要

クライアントの秘密は期限切れで、最大24ヶ月です。期限切れになると、すべてのMicrosoftサインインが失敗し、交換されるまで AADSTS7000215 が届くため、有効期限を追跡し、それより先にローテーションしてください。本番環境では、証明書認証情報やフェデレーテッドID認証情報で秘密の期限切れ問題を完全に回避できます。

4. API権限の検証

新しい登録は自動的にMicrosoft Graph User.Read (委任)され、サインインフローに必要な唯一の権限となります。プロバイダーは https://graph.microsoft.com/user.read スコープを要求し、サインインしたユーザーのプロフィールを https://graph.microsoft.com/v1.0/meから読み込みます。もし誰かがその権限を削除した場合は、 API権限の下で再度追加してください。管理者の同意付与はほとんどのワークフォーステナントでは任意ですが、初回サインイン時に各ユーザーに同意プロンプトを表示することを避けられます。外部テナントでは必須です。

Power Portals Proは、ポータルユーザーをリンクまたは作成する際に、そのプロファイルから以下の内容を読み取ります。

注記

Exchangeメールボックスがない場合は mail プロパティが空き、プロバイダーは返 userPrincipalNameに切り替えます。UPNは必ずしもルーティング可能なメールアドレスではなく、特にゲストアカウントは user_contoso.com#EXT#@yourtenant.onmicrosoft.com 型のUPNを持っています。ポータルがメールでユーザーをマッチングしても、既存の連絡先と一致しないと予想されます。

5. クライアントIDと秘密を保存する

ポータルは Authentication:Microsoft セクションの設定から両方の値を読み取ります。開発中は、 appsettings.json ではなくユーザーシークレットに保持し、ソース制御に到達しないようにしてください:

またはコマンドラインからサーバープロジェクトのディレクトリから:

ヒント

ホスト環境では、環境変数と同じキーや秘密ストアから同じキーを提供します。環境変数はコロンの代わりにダブルアンダースコア( Authentication__Microsoft__ClientId と Authentication__Microsoft__ClientSecret )を使用します。これはコロン区切りがプラットフォーム間で持ち運べないためです。

6. プロバイダーをProgram.csで有効化する

プロバイダーと他の認証設定をサーバープロジェクトの Program.csに登録してください:

プロジェクトテンプレートは、 内部ユーザー または 両方の オーディエンスを選択し、 または外部ユーザー向けにMicrosoftサインインを選択したときにこのコールを自動で書き込みます。もしプロジェクトを生成せずにプロジェクトを生成した場合、同じコールが Program.cs でコメントアウトされ、コメントを解除して2つの設定値を入力してください。

7. サインインと確認

ポータルを実行し、ログインページを開きます。サインインオプションの中に Microsoft のボタンが表示されます。アカウントが初めてサインインする際、ポータルはMicrosoftのIDをポータルユーザーにリンクし、可能な限り既存の連絡先とメールで照合し、そうでなければ訪問者がプロフィールの名前とメールアドレスを事前に入力して登録手続きを進めます。

もしアカウントがDataverse systemuserとしても存在しているなら、セッションは連絡先ではなくその内部ユーザーとして実行できます。この動作はアプリ登録に追加の設定を必要としません: SystemUserサインインを参照

トラブルシューティング

• AADSTS50011 — URIの不一致をリダイレクトします。 ポータルから送信されたアドレスは登録されていません。エラー内のURIと Web プラットフォームのエントリーを文字単位で比較し、ポート名や尾部のスラッシュがない点も含めて比較してください。
• AADSTS7000215 — 無効なクライアントシークレット。通常、シークレットの値の代わりにシークレットIDがコピーされたか、シークレットが期限切れになっている場合が多いです。新しいシークレットを作成し、設定を更新します。
• AADSTS50020 — アイデンティティプロバイダーのユーザーアカウントはテナントに存在しません。 サインインするアカウントは登録の 「サポート済みアカウントタイプ」の外にあります。その対象者をカバーするように設定を広げてください。
• サインインの往復は http://に着きます。 ポータルは転送ヘッダーミドルウェアが設定されていないTLS終了プロキシの背後にあり、不安全なリダイレクトURIを生成しています。
• 新しいアカウントにはメールアドレスがありません。 Microsoftアカウントにはメールボックスがなく、代わりにその userPrincipalName が使われていました。ステップ4のメモを参照してください。