コマーシャル マーケットプレースで無料または試用版 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 アプリケーションへのサブスクリプションをアクティブ化して構成するために、コマーシャル マーケットプレースはその顧客をランディング ページに移動します。 サービスとしてのソフトウェア (SaaS) オファーを作成した場合は、パートナー センターで、Microsoft 経由で販売するかどうかを選択できます。 Microsoft コマーシャル マーケットプレースでオファーを一覧表示するだけで、Microsoft 経由で販売しない場合は、潜在顧客がそのオファーをどのように操作できるかを指定できます。 [今すぐ入手 (無料)] または [無料試用版] 一覧オプションを有効にする場合は、ユーザーが無料サブスクリプションまたは無料試用版にアクセスするために移動できるランディング ページの URL を指定する必要があります。

ランディング ページの目的は、単純に、無料試用版または無料サブスクリプションをアクティブ化できるようにユーザーを受け付けることです。 Microsoft Entra ID と Microsoft Graph を使用すると、ユーザーのシングル サインオン (SSO) を有効にし、ユーザーの名前、メール アドレス、組織など、無料試用版または無料サブスクリプションのアクティブ化に使用できるユーザーに関する重要な詳細を取得します。

サブスクリプションのアクティブ化に必要な情報は制限されており、Microsoft Entra ID と Microsoft Graph によって提供されるため、基本的な同意以上の情報を要求する必要はありません。 アプリケーションに対してより多くの同意が必要なユーザーの詳細が必要な場合は、サブスクリプションのアクティブ化が完了した後にこの情報を要求する必要があります。 これにより、ユーザーによる円滑なサブスクリプションのアクティブ化が可能になり、破棄されるリスクが軽減されます。

ランディング ページには通常、次の情報とリスト オプションが含まれています。

  • 無料試用版または無料サブスクリプションの名前と詳細を指定します。 たとえば、試用版の使用制限または期間を指定します。
  • ユーザーのアカウントの詳細 (姓名、組織、電子メールを含む) を指定します。
  • ユーザーに別のアカウントの詳細を確認するか、または置き換えるよう求めます。
  • ユーザーをアクティブ化の後の次のステップに案内します。 たとえば、ウェルカム メールを受信したり、サブスクリプションを管理したり、サポートを受けたり、ドキュメントを参照したりします。

この記事の次のセクションでは、ランディング ページを構築するプロセスについて説明します。

  1. ランディング ページの Microsoft Entra アプリ登録 を作成します。
  2. アプリの開始点としてコード サンプルを使用します。
  3. サインイン後に Microsoft Entra ID から受信した ID トークンでエンコードされた要求から、要求と共に送信された情報を読み取る。
  4. Microsoft Graph API を使用して、必要に応じて追加情報を収集します。

Microsoft Entra アプリの登録を作成する

コマーシャル マーケットプレースは、Microsoft Entra ID と完全に統合されています。 ユーザーは、Microsoft Entra アカウントまたは Microsoft アカウント (MSA) で認証されたマーケットプレースに到着します。 一覧表示のみのオファーから無料試用版サブスクリプションを取得した後、ユーザーはコマーシャル マーケットプレースからランディング ページの URL に移動して、SaaS アプリケーションへのサブスクリプションをアクティブ化して管理します。 ユーザーが Microsoft Entra SSO を使用してアプリケーションにサインインできるようにする必要があります。 (ランディング ページの URL は、そのプランの [技術的な構成] ページで指定されます)。

ヒント

ランディング ページの URL にはシャープ記号 (#) を含めないでください。 そうしないと、顧客はランディング ページにアクセスできません。

ID を使用する最初の手順は、ランディング ページが Microsoft Entra アプリケーションとして登録されていることを確認することです。 アプリケーションを登録すると、Microsoft Entra ID を使用してユーザーを認証し、ユーザー リソースへのアクセスを要求できます。 これは、アプリケーションの定義と見なすことができます。これにより、サービスは、アプリの設定に基づいてアプリにトークンを発行する方法を認識できるようになります。

Azure portal を使用して新しいアプリケーションを登録します

作業を開始するには、新しいアプリケーションの登録に関する記事の手順に従います。 他の会社のユーザーがアプリにアクセスできるようにするには、アプリケーションを使用できるユーザーを尋ねられたら、任意の組織ディレクトリ (任意の Microsoft Entra ディレクトリ - マルチテナント) と個人の Microsoft アカウント (Skype や Xbox など) のアカウントを選択する必要があります。

Microsoft Graph API に対してクエリを実行する場合は、Web API にアクセスするように新しいアプリケーションを構成します。 このアプリケーションの API のアクセス許可を選択する場合、ユーザーに関する基本情報を収集してオンボード プロセスがスムーズかつ自動的に実行されるようにするには User.Read の既定値で十分です。 管理者以外のすべてのユーザーがランディング ページにアクセスするのをブロックするため、管理者の同意が必要とラベル付けされた API アクセス許可を要求しないでください。

オンボードまたはプロビジョニング プロセスの一環として昇格されたアクセス許可が必要な場合は、Marketplace から送信されたすべてのユーザーが最初にランディング ページと対話できるように、Microsoft Entra ID の増分同意機能を使用することを検討してください。

開始点としてコード サンプルを使用する

Microsoft は、Microsoft Entra ログインを有効にした単純な Web サイトを実装するサンプル アプリをいくつか提供しています。 アプリケーションが Microsoft Entra ID に登録されると、[クイック スタート] ブレードに一般的なアプリケーションの種類と開発スタックの一覧が表示されます (図 1)。 環境に合うものを選択し、ダウンロードとセットアップの手順に従います。

"図 1:Azure portal の [クイック スタート] ブレード"

Illustrates the Quickstart blade in the Azure portal.

コードをダウンロードし、開発環境を設定したら、前の手順で記録したアプリケーション ID、テナント ID、クライアント シークレットを反映するように、アプリの構成設定を変更します。 正確な手順は、使用しているサンプルによって異なります。

ID トークンにエンコードされている要求から情報を読み取る

OpenID Connect フローの一部として、Microsoft Entra ID は、ユーザーがランディング ページに送信されたときに要求に ID トークンを追加します。 このトークンには、アクティブ化プロセスで役立つ複数の基本情報が含まれています。これには、次の表に示す情報などが含まれます。

Value 説明
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 アクセス許可には、既定では次の情報が含まれます。

Value Description
displayName ユーザーのアドレス帳に表示される名前。
givenName ユーザーの名です。
jobTitle ユーザーの役職。
mail ユーザーの SMTP アドレス。
mobilePhone ユーザーの携帯電話番号 (代表)。
preferredLanguage ユーザーの優先する言語の ISO 639-1 コード。
姓 ユーザーの姓です。

その他のプロパティ (ユーザーの会社の名前やユーザーの場所 (国/地域) など) を選択して、要求に含めることができます。 詳細については、「ユーザー リソースの種類のプロパティ」を参照してください。

Microsoft Entra ID に登録されているほとんどのアプリは、会社の Microsoft Entra テナントからユーザーの情報を読み取る委任されたアクセス許可を付与します。 それらの情報を取得するための Microsoft Graph への要求にはすべて、認証としてのアクセス トークンを指定する必要があります。 アクセス トークンを生成するための具体的な手順は、使用しているテクノロジ スタックによって異なりますが、サンプル コードには例が含まれています。 詳細については、「ユーザーの代わりにアクセスを取得」を参照してください。

Note

MSA テナント (テナント ID は 9188040d-6c67-4c5b-b112-36a304b66dad) のアカウントでは、ID トークンで既に収集されている内容より詳細な情報は返されません。 そのため、これらのアカウントでは Graph API へのこの呼び出しをスキップできます。

次のステップ