コマーシャル マーケットプレースで取引可能な SaaS オファーのランディング ページを構築する
この記事では、Microsoft コマーシャル マーケットプレースで販売される取引可能な SaaS アプリのランディング ページを構築するプロセスについて説明します。
重要
Azure Active Directory (Azure AD) Graph は、2023 年 6 月 30 日の時点で非推奨となっています。 今後、Azure AD Graph への投資は行いません。 Azure AD Graph API には、セキュリティ関連の修正プログラム以外の SLA やメンテナンス コミットメントはありません。 新機能への投資は、Microsoft Graph でのみ行われます。
アプリケーションを Microsoft Graph API に移行するのに十分な時間を確保できるように、段階的な手順で Azure AD Graph を廃止します。 後日お知らせしますが、Azure AD Graph を使用して新しいアプリケーションの作成をブロックします。
詳細については、「重要: Azure AD Graph の廃止と Powershell モジュールの廃止」を参照してください。
概要
ランディング ページは、サービスとしてのソフトウェア (SaaS) オファーの "ロビー" と考えることができます。 購入者がオファーをサブスクライブすると、コマーシャル マーケットプレースからランディング ページに誘導され、SaaS アプリケーションへのサブスクリプションをアクティブ化して構成します。 これは、購入者が購入した内容を確認し、アカウントの詳細を確認できる注文確認手順と考えてください。 Microsoft Entra ID と Microsoft Graph を使用すると、購入者に対してシングル サインオン (SSO) を有効にし、購入者の名前、メール アドレス、組織など、サブスクリプションの確認とアクティブ化に使用できる購入者に関する重要な詳細を取得します。
サブスクリプションのアクティブ化に必要な情報は制限されており、Microsoft Entra ID と Microsoft Graph によって提供されるため、基本的な同意以上の情報を要求する必要はありません。 アプリケーションに追加の同意が必要なユーザーの詳細が必要な場合は、サブスクリプションのアクティブ化が完了した後にこの情報を要求する必要があります。 これにより、購入者の摩擦のないサブスクリプションのアクティブ化が可能になり、破棄のリスクが減少します。
ランディング ページには通常、次のものが含まれます。
- 購入したオファーとプランの名前と課金条件を提示します。
- 名、姓、組織、電子メールなど、購入者のアカウントの詳細を表示します。
- 購入者に、別のアカウントの詳細を確認するか、別のアカウントの詳細に置き換えるよう求めるメッセージを表示します。
- アクティブ化後の次の手順について購入者をガイドします。 たとえば、ウェルカム メールを受信したり、サブスクリプションを管理したり、サポートを受けたり、ドキュメントを読んだりします。
注
購入者は、アクティブ化後にサブスクリプションを管理するときにもランディング ページに移動します。 購入者のサブスクリプションがアクティブ化されたら、SSO を使用してユーザーがサインインできるようにする必要があります。 ユーザーをアカウント プロファイルまたは構成ページに誘導することをお勧めします。
次のセクションでは、ランディング ページを構築するプロセスについて説明します。
- ランディング ページの Microsoft Entra アプリ登録 を作成します。
- アプリの開始点としてコード サンプルを使用。
- 2 つの Microsoft Entra アプリを使用して、運用のセキュリティを強化します。
- コマーシャル マーケットプレースによって URL に追加された 購入識別トークンを解決します。
- サインイン後に Microsoft Entra ID から受信した ID トークンでエンコードされた要求から情報を読み取り、要求と共に送信されます。
- Microsoft Graph API を使用して、必要に応じて追加情報を収集します。
Microsoft Entra アプリの登録を作成する
コマーシャル マーケットプレースは、Microsoft Entra ID と完全に統合されています。 購入者は、Microsoft Entra アカウントまたは Microsoft アカウント (MSA)で認証されたマーケットプレースに到着します。 購入後、購入者はコマーシャル マーケットプレースからランディング ページの URL に移動して、SaaS アプリケーションのサブスクリプションをアクティブ化および管理します。 購入者が Microsoft Entra SSO を使用してアプリケーションにサインインできるようにする必要があります。 (ランディング ページの URL は、オファーの Technical Configuration ページで指定されています)。
ヒント
ランディング ページの URL にシャープ記号 (#) を含めないでください。 そうしないと、顧客はランディング ページにアクセスできなくなります。
ID を使用する最初の手順は、ランディング ページが Microsoft Entra アプリケーションとして登録されていることを確認することです。 アプリケーションを登録すると、Microsoft Entra ID を使用してユーザーを認証し、ユーザー リソースへのアクセスを要求できます。 これはアプリケーションの定義と見なすことができます。これにより、サービスはアプリの設定に基づいてアプリにトークンを発行する方法を知ることができます。
Azure portal を使用して新しいアプリケーションを登録する
開始するには、新しいアプリケーションを登録するための 手順に従います。 他の企業のユーザーがアプリにアクセスできるようにするには、アプリケーションを使用できるユーザーを求められたら、マルチテナント オプションのいずれかを選択する必要があります。
Microsoft Graph API に対してクエリを実行する場合 、Web APIにアクセスするように新しいアプリケーションを構成します。 このアプリケーションの API アクセス許可を選択すると、既定の User.Read で、オンボード プロセスをスムーズかつ自動にするための購入者に関する基本情報を収集するのに十分です。 管理者の同意 必要ラベルが付いた API アクセス許可を要求しないでください。これにより、管理者以外のすべてのユーザーがランディング ページにアクセスできなくなります。
オンボードまたはプロビジョニング プロセスの一環として昇格されたアクセス許可が必要な場合は、マーケットプレースから送信されたすべての購入者が最初にランディング ページと対話できるように、Microsoft Entra ID の 増分同意 機能を使用することを検討してください。
開始点としてコード サンプルを使用する
Microsoft Entra ログインを有効にした単純な Web サイトを実装するサンプル アプリがいくつか用意されています。 アプリケーションが Microsoft Entra ID に登録されると、図 1 に示すように、クイック スタート ブレードには、一般的なアプリケーションの種類と開発スタックの一覧が表示されます。 環境に一致するものを選択し、ダウンロードとセットアップの手順に従います。
図 1: Azure portal の [クイック スタート] ブレード
コードをダウンロードして開発環境を設定したら、前の手順で記録したアプリケーション ID、テナント ID、クライアント シークレットを反映するようにアプリの構成設定を変更します。 正確な手順は、使用しているサンプルによって異なります。
2 つの Microsoft Entra アプリを使用して運用環境のセキュリティを強化する
この記事では、コマーシャル マーケットプレース SaaS オファーのランディング ページを実装するためのアーキテクチャの簡略化されたバージョンを示します。 運用環境でページを実行する場合は、別のセキュリティで保護されたアプリケーションを介してのみ SaaS フルフィルメント API と通信することで、セキュリティを強化することをお勧めします。 これには、次の 2 つの新しいアプリケーションを作成する必要があります。
- 1 つ目は、これまでに説明してきたマルチテナント ランディング ページ アプリケーション。ただし、SaaS Fulfillment API に接続する機能はありません。 この機能は、次に説明するように、別のアプリケーションにオフロードされます。
- 次に、SaaS フルフィルメント API との通信を管理するアプリケーションです。 このアプリケーションは、組織でのみ使用されるシングル テナントである必要があり、アクセス制御リストを確立して、このアプリからの API へのアクセスのみを制限できます。
これにより、ソリューションは懸案事項の分離原則を観察するシナリオで動作できるようになります。 たとえば、ランディング ページでは、最初に登録された Microsoft Entra アプリを使用してユーザーをサインインさせます。 ユーザーがサインインすると、ランディング ページは 2 番目の Microsoft Entra ID を使用して、SaaS フルフィルメント API を呼び出して解決操作を呼び出すアクセス トークンを要求します。
マーケットプレース購入 ID トークンを解決する
購入者がランディング ページに送信されると、トークンが URL パラメーターに追加されます。 このトークンは、Microsoft Entra ID が発行するトークンや、サービス間認証で使用されるアクセス トークンとは異なり、サブスクリプションの詳細を取得するために、SaaS フルフィルメント API の 解決呼び出しの入力として使用されます。 SaaS フルフィルメント API に対するすべての呼び出しと同様に、サービス間の要求は、サービス間認証用のアプリの Microsoft Entra アプリケーション ID ユーザーに基づくアクセス トークンで認証されます。
注
ほとんどの場合、2 つ目のシングルテナント アプリケーションからこの呼び出しを行う方が望ましいです。 「2 つの Microsoft Entra アプリを使用して運用環境のセキュリティを向上させる、この記事の前半を参照してください。
アクセス トークンを要求する
SaaS フルフィルメント API を使用してアプリケーションを認証するには、Microsoft Entra ID OAuth エンドポイントを呼び出すことによって生成できるアクセス トークンが必要です。 発行元の承認トークンを取得する方法を参照してください。
解決エンドポイントを呼び出す
SaaS フルフィルメント API は、marketplace トークンの有効性を確認し、サブスクリプションに関する情報を返すために呼び出すことができる、解決 エンドポイントを実装します。
ID トークンでエンコードされた要求から情報を読み取る
OpenID Connect フローの一部として、受信したテナント ID 値を https://login.microsoftonline.com/{tenant}/v2.0に配置します。 Microsoft Entra ID は、購入者がランディング ページに送信されるときに、要求に ID トークンを追加します。 このトークンには、アクティブ化プロセスで役立つ可能性のある複数の基本情報 (この表に示されている情報を含む) が含まれています。
| 値 | 説明 |
|---|---|
| aud | このトークンの対象ユーザー。 この場合は、アプリケーション ID と一致し、検証する必要があります。 |
| preferred_username | アクセスするユーザーのプライマリ ユーザー名。 電子メール アドレス、電話番号、またはその他の識別子を指定できます。 |
| ユーザーのメール アドレス。 このフィールドは空である可能性があることに注意してください。 | |
| name | トークンのサブジェクトを識別する人間が判読できる値。 この場合は、購入者の名前になります。 |
| oid | アプリケーション間でユーザーを一意に識別する Microsoft ID システム内の識別子。 Microsoft Graph は、この値を特定のユーザー アカウントの ID プロパティとして返します。 |
| tid | 購入者の元の Microsoft Entra テナントを表す識別子。 MSA ID の場合、これは常に 9188040d-6c67-4c5b-b112-36a304b66dad。 詳細については、次のセクション「Microsoft Graph API を使用する」のメモを参照してください。 |
| sub | この特定のアプリケーションのユーザーを一意に識別する識別子。 |
Microsoft Graph API を使用する
ID トークンには購入者を識別するための基本情報が含まれていますが、アクティブ化プロセスでは、オンボード プロセスを完了するために、購入者の会社などの追加の詳細が必要になる場合があります。 Microsoft Graph API を使用して、この情報を要求して、ユーザーがこれらの詳細を再度入力することを強制しないようにします。 標準の User.Read アクセス許可には、既定で次の情報が含まれます。
| 値 | 説明 |
|---|---|
| displayName | ユーザーのアドレス帳に表示される名前。 |
| givenName | ユーザーの名。 |
| jobTitle | ユーザーの役職。 |
| ユーザーの SMTP アドレス。 | |
| mobilePhone | ユーザーのプライマリ携帯電話番号。 |
| preferredLanguage | ユーザーの優先言語の ISO 639-1 コード。 |
| surname | ユーザーの姓。 |
追加のプロパティ (ユーザーの会社の名前やユーザーの場所 (国/地域) など) は、要求に含めるために選択できます。 詳細については、ユーザー リソースの種類の の プロパティを参照してください。
Microsoft Entra ID に登録されているほとんどのアプリは、会社の Microsoft Entra テナントからユーザーの情報を読み取る委任されたアクセス許可を付与します。 その情報に対する Microsoft Graph への要求には、認証用のアクセス トークンが添付されている必要があります。 アクセス トークンを生成する具体的な手順は、使用しているテクノロジ スタックによって異なりますが、サンプル コードには例が含まれます。 詳しくは、「ユーザーに代わってアクセスを取得する」をご覧ください。
注
(テナント ID 9188040d-6c67-4c5b-b112-36a304b66dadを持つ) MSA テナントのアカウントは、ID トークンで既に収集されているよりも多くの情報を返しません。 そのため、これらのアカウントの Graph API へのこの呼び出しをスキップできます。
関連コンテンツ
- コマーシャル マーケットプレース で SaaS オファーを作成する方法
ビデオ チュートリアル