アプリのマルチインスタンス化を構成する
アプリのマルチインスタンス化は、同じアプリケーションの複数のインスタンスをテナント内で構成することをいいます。 たとえば、組織に複数のアカウントが存在する場合、それぞれにはインスタンス固有の要求マッピングとロール割り当てに対処するための個別のサービス プリンシパルが必要となります。 また、顧客がアプリケーションのインスタンスを複数所有している場合、特殊な要求マッピングは必要ないものの、それぞれの署名キー用の個別のサービス プリンシパルが必要です。
サインイン方法
ユーザーは、次のいずれかの方法でアプリケーションにサインインできます。
- アプリケーションを直接使用します。これは、サービス プロバイダー (SP) によって開始されるシングル サインオン (SSO) と呼ばれます。
- ID プロバイダー (IDP) に直接移動します。これは、IDP Initiated SSO と呼ばれます。
ご自身の組織で使用されているアプローチに応じて、この記事で説明されている適切な手順に従ってください。
SP Initiated SSO
SP Initiated SSO の SAML 要求内では、指定される issuer は通常、アプリ ID URI になります。 SP Initiated SSO を使用しているときに、アプリ ID URI を利用した場合、アプリケーションのどのインスタンスが対象となっているかを顧客は判別できません。
SP Initiated SSO を構成する
サービス プロバイダー内で構成されている SAML シングル サインオン サービス URL をインスタンスごとに更新します。サービス プリンシパルの guid を URL の一部として追加してください。 たとえば、SAML 用の一般の SSO サインイン URL が https://login.microsoftonline.com/<tenantid>/saml2 である場合、特定のサービス プリンシパルが対象となるように、URL を https://login.microsoftonline.com/<tenantid>/saml2/<issuer> のように更新することができます。
"issuer" の値に指定できるのは、GUID 形式のサービス プリンシパル識別子のみです。 SAML 要求と応答に含まれる発行者はサービス プリンシパル識別子によってオーバーライドされますが、それ以外のフローは、通常どおりに実行されます。 これには 1 つ例外があります。要求に対する署名を必要とするアプリケーションでは、署名が有効であったとしても要求は拒否されます。 拒否の目的は、署名された要求の値が、なんらかの目的をもってオーバーライドされることによるセキュリティ リスクを回避するためです。
IDP Initiated SSO
IDP Initiated SSO 機能は、各アプリケーションに次の設定を公開します。
audience override オプション。クレーム マッピングまたはポータルを使用した構成用に公開されます。 ユース ケースとしては、複数のインスタンスのオーディエンスが同じであることを必要とするアプリケーションが想定されています。 アプリケーションのカスタム署名キーが構成されていない場合、この設定は無視されます。
issuer with application id フラグ。テナント単位ではなくアプリケーション単位の一意性が発行者に求められることを指定します。 アプリケーションのカスタム署名キーが構成されていない場合、この設定は無視されます。
IDP Initiated SSO を構成する
- クラウド アプリケーション管理者以上として Microsoft Entra 管理センターにサインインします。
- [ID]>[アプリケーション]>[エンタープライズ アプリケーション] の順に移動します。
- SSO 対応エンタープライズ アプリをどれか開き、SAML シングル サインオン ブレードに移動します。
- [ユーザー属性と要求] パネルの [編集] を選択します。
- [編集] を選択して、詳細オプション ブレードを開きます。
- 両方のオプションを必要に応じて構成し、[保存] を選択します。
次のステップ
- このポリシーを構成する方法の詳細については、アプリの SAML トークン クレームのカスタマイズに関する記事を参照してください。