取引可能な 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 を使用して新しいアプリケーションの作成をブロックします。
詳細については、「 Important: Azure AD Graph の廃止と Powershell モジュールの廃止に関するページを参照してください。
概要
ランディング ページは、サービスとしてのソフトウェア (SaaS) オファーのための "ロビー" と考えることができます。 オファーをサブスクライブした後、購入者はコマーシャル マーケットプレースによってランディング ページにリダイレクトされ、そこで SaaS アプリケーションのサブスクリプションをアクティブにして構成します。 これは、購入内容とアカウントの詳細を購入者が確認するための注文確認手順と見なすことができます。 Microsoft Entra ID と Microsoft Graph を使用すると、購入者に対してシングル サインオン (SSO) を有効にし、購入者の名前、メール アドレス、組織など、サブスクリプションの確認とアクティブ化に使用できる購入者に関する重要な詳細を取得します。
サブスクリプションのアクティブ化に必要な情報は制限されており、Microsoft Entra ID と Microsoft Graph によって提供されるため、基本的な同意以上の情報を要求する必要はありません。 アプリケーションに関する追加の同意を必要とするユーザーの詳細が必要な場合、これらの情報は、サブスクリプションのアクティブ化が完了した後に要求する必要があります。 そうすることで購入者はスムーズにサブスクリプションをアクティブ化でき、中止のリスクが減少します。
通常、ランディング ページには次の要素が含まれます。
- 購入したオファーとプランの名前、および支払方法を表示する。
- 購入者のアカウントの詳細 (姓と名、組織、メールなど) を表示する。
- さまざまなアカウントの詳細を確認または置換するよう購入者に促す。
- アクティブ化の後、それに続く手順へ購入者を導く。 たとえば、ウェルカム メールを受信したり、サブスクリプションを管理したり、サポートを受けたり、ドキュメントを参照したりします。
Note
また、アクティブ化した後で購入者がサブスクリプションを管理する場合も、このランディング ページに移動させられます。 購入者のサブスクリプションがアクティブになった後、SSO を使用してユーザーがサインインできるようにする必要があります。 アカウントのプロファイルまたは構成ページにユーザーを移動させることをお勧めします。
次のセクションで、ランディング ページを作成する手順について説明します。
- ランディング ページの Microsoft Entra アプリ登録 を作成します。
- アプリの開始点としてコード サンプルを使用します。
- 2 つの Microsoft Entra アプリを使用して、運用環境のセキュリティを強化します。
- コマーシャル マーケットプレースによって URL に追加されたマーケットプレース購入 ID トークンを解決する。
- サインイン後に Microsoft Entra ID から受信した ID トークンでエンコードされた要求から、要求と共に送信された情報を読み取ります。
- 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 を使用して新しいアプリケーションを登録します
作業を開始するには、新しいアプリケーションの登録に関する記事の手順に従います。 他の企業のユーザーがアプリにアクセスできるようにするには、アプリケーションを使用できるユーザーを指定するように求められたときに、マルチテナント オプションの 1 つを選択する必要があります。
Microsoft Graph API に対してクエリを実行する場合は、Web API にアクセスするように新しいアプリケーションを構成します。 このアプリケーションの API アクセス許可を選択する場合、オンボード プロセスをスムーズかつ自動的に実行するのに必要な購入者に関する基本情報は、User.Read の既定値で十分に収集できます。 [needs admin consent]\(管理者の同意が必要\) というラベルが付けられている API アクセス許可を要求しないでください。要求すると、管理者以外のユーザーは誰もランディング ページにアクセスできなくなります。
オンボードまたはプロビジョニング プロセスの一環として昇格されたアクセス許可が必要な場合は、マーケットプレースから送信されたすべての購入者が最初にランディング ページと対話できるように、Microsoft Entra ID の incremental consent 機能の使用を検討してください。
開始点としてコード サンプルを使用する
Microsoft Entra ログインを有効にした単純な Web サイトを実装するサンプル アプリがいくつか用意されています。 アプリケーションが Microsoft Entra ID に登録されると、図 1 に示すように、 Quickstart ブレードに一般的なアプリケーションの種類と開発スタックの一覧が表示されます。 環境に合うものを選択し、ダウンロードとセットアップの手順に従います。
"図 1:Azure portal の [クイック スタート] ブレード"
![Azure portal の [クイック スタート] ブレードの表示。](../media/marketplace-offers/azure-ad-saas/azure-ad-quickstart-blade.png)
コードをダウンロードし、開発環境を設定したら、前の手順で記録したアプリケーション ID、テナント ID、クライアント シークレットを反映するように、アプリの構成設定を変更します。 実際の手順は使用しているサンプルによって異なることに注意してください。
2 つの Microsoft Entra アプリを使用して運用環境のセキュリティを強化する
この記事では、コマーシャル マーケットプレース SaaS オファー用のランディング ページを実装するためのアーキテクチャの簡略化されたバージョンについて説明します。 運用環境でページを実行する場合は、セキュリティで保護された別のアプリケーションのみを通して SaaS Fulfillment API と通信して、セキュリティを強化することをお勧めします。 そのためには、次の 2 つの新しいアプリケーションを作成する必要があります。
- 1 つ目は、ここまでで説明したマルチテナント ランディング ページ アプリケーションです。ただし、SaaS Fulfillment API に接続する機能はありません。 この機能は、次に示す別のアプリケーションにオフロードされます。
- 2 つ目は、SaaS Fulfillment API との通信機能を持つためのアプリケーションです。 このアプリケーションはシングル テナントでなければならず、自分の組織によってのみ使用されます。また、API へのアクセスをこのアプリだけに限定するためにアクセス制御リストを確立できます。
これにより、懸念事項の分離の原則を遵守したシナリオでこのソリューションを使用できるようになります。 たとえば、ランディング ページでは、最初に登録された Microsoft Entra アプリを使用してユーザーをサインインさせます。 ユーザーがサインインすると、ランディング ページは 2 番目の Microsoft Entra ID を使用して、SaaS フルフィルメント API を呼び出して解決操作を呼び出すアクセス トークンを要求します。
マーケットプレース購入 ID トークンを解決する
購入者がランディング ページにリダイレクトされると、URL パラメーターにトークンが追加されます。 このトークンは、Microsoft Entra ID 発行トークンとサービス間認証に使用されるアクセス トークンの両方とは異なり、 SaaS フルフィルメント API の入力として使用 サブスクリプションの詳細を取得するための呼び出しを解決します。 SaaS フルフィルメント API に対するすべての呼び出しと同様に、サービス間の要求は、サービス間認証用のアプリの Microsoft Entra アプリケーション ID ユーザーに基づくアクセス トークンで認証されます。
Note
ほとんどの場合、2 つ目のシングル テナント アプリケーションからこの呼び出しを行うことをお勧めします。 「 2 つの Microsoft Entra アプリを使用して運用環境のセキュリティを強化する この記事の前半を参照してください。
アクセス トークンの要求
SaaS フルフィルメント API を使用してアプリケーションを認証するには、Microsoft Entra ID OAuth エンドポイントを呼び出すことによって生成できるアクセス トークンが必要です。 「公開元の承認トークンを取得する方法」を参照してください。
解決エンドポイントを呼び出す
SaaS Fulfillment API では、解決エンドポイントを実装します。これを呼び出すことで、マーケットプレース トークンの有効性を確認することや、サブスクリプションに関する情報を返すことができます。
ID トークンにエンコードされている要求から情報を読み取る
OpenID Connect フローの一部として、受け取ったテナントID値を https://login.microsoftonline.com/{tenant}/v2.0 に入力します。 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 | ユーザーの役職。 |
| メール | ユーザーの SMTP アドレス。 |
| mobilePhone | ユーザーの携帯電話番号 (代表)。 |
| preferredLanguage | ユーザーの優先する言語の ISO 639-1 コード。 |
| 姓 | ユーザーの姓です。 |
追加のプロパティ (ユーザーの会社の名前やユーザーの場所 (国/地域) など) は、要求に含めるために選択できます。 詳細については、user リソースの種類のプロパティを参照してください。
Microsoft Entra ID に登録されているほとんどのアプリは、会社の Microsoft Entra テナントからユーザーの情報を読み取る委任されたアクセス許可を付与します。 その情報を取得するための Microsoft Graph へのすべての要求には、認証のためのアクセス トークンが必要です。 アクセス トークンを生成するための具体的な手順は、使用しているテクノロジ スタックによって異なりますが、サンプル コードには例が含まれています。 詳細については、「ユーザーの代わりにアクセスを取得」を参照してください。
Note
MSA テナント (テナント ID は 9188040d-6c67-4c5b-b112-36a304b66dad) のアカウントでは、ID トークンで既に収集されている内容より詳細な情報は返されません。 そのため、これらのアカウントでは Graph API へのこの呼び出しをスキップできます。
関連するコンテンツ
ビデオ チュートリアル