シナリオ - Microsoft Entra ID を使用して SAP プラットフォームおよびアプリケーションへのアクセスをセキュリティで保護する

このドキュメントでは、SAP Cloud Identity Services ユーザー認証のプライマリ サービスとして Microsoft Entra ID を使用するときの、SAP プラットフォームおよびアプリケーションの技術的な設計と構成に関するアドバイスを提供します。 SAP Cloud Identity Services には、Identity Authentication、ID プロビジョニング、ID ディレクトリ、および承認管理が含まれます。 認証の初期セットアップの詳細については、「Microsoft Entra シングル サインオン (SSO) と SAP Cloud Identity Services の統合に関するチュートリアル」を参照してください。 プロビジョニングとその他のシナリオの詳細については、「SAP ソースとターゲット アプリケーションのユーザー プロビジョニングに Microsoft Entra のデプロイ計画」と「SAP アプリケーションへのアクセスを管理する」を参照してください。

このガイドで使用する用語

概要

SAP と Microsoft のテクノロジ スタックには、ユーザーの認証と認可のシナリオで役割を果たすサービスとコンポーネントが多数あります。 下の図に、主要なサービスを示します。

構成するシナリオの候補には多数の組み合わせが存在するため、Microsoft Entra ID を最優先する戦略に沿った 1 つのシナリオに焦点をあてます。 以下のことを想定します。

• すべての ID を一元的に、Microsoft Entra ID からのみ管理しようと考えています。
• メンテナンス作業を可能な限り減らし、Microsoft と SAP の全体にわたって認証とアプリへのアクセスを自動化したいと考えています。
• IAS で構成された BTP および SAP SaaS アプリ上にデプロイされたアプリには、IAS を使用する Microsoft Entra ID の一般的なガイダンスがあてはまります。 BTP (例: Microsoft Entra グループでロール マッピングを使用) と SAP SaaS アプリ (例: ロールベースの承認に ID プロビジョニング サービスを使用) には、必要に応じて特定の推奨事項も提供されます。
• Microsoft Entra ID および、機能させるにはユーザーのプロビジョニングが必要であるすべての SAP システムに、ユーザーが既にプロビジョニングされていることも想定します。 その実現方法にはこだわりません。プロビジョニングは手動でも、オンプレミスの Active Directory から Microsoft Entra Connect 経由でも、SAP SuccessFactors のような人事システム経由でも実行できます。 したがってこのドキュメントでは、SuccessFactors は、(既存の) ユーザーがサインオンする他のどのアプリケーションとも同等のアプリケーションであると見なされます。 SuccessFactors から Microsoft Entra ID への、ユーザーの実際のプロビジョニングについては取り上げません。 SAP ワークロードで使用するため、Microsoft Entra ID にユーザーを持ち込む方法の詳細については、「SAP ソースとターゲット アプリケーションのユーザー プロビジョニングに Microsoft Entra のデプロイ計画」と「SAP アプリケーションへのアクセスを管理する」を参照してください。

これらの前提条件に基づいて、ほとんどの場合、下の図に示した製品とサービスに重点を置きます。 これらは、クラウドベースの環境での認証と認可に最も関連性が高いさまざまなコンポーネントです。

これまで SAP ID 管理 (IDM) を使ってきた場合は、ID 管理シナリオを SAP IDM から Microsoft Entra に移行できます。 詳しくは、「ID 管理シナリオの SAP IDM から Microsoft Entra への移行」をご覧ください。

Recommendations

まとめ

• 1 - SAP Business Technology Platform と SAP SaaS アプリケーションでは SAP ID 認証サービスを通してフェデレーション認証を使用する
• 2 - 認証に Microsoft Entra ID を、承認に IAS/BTP を使用する
• 3 - 承認に IAS/BTP のロール コレクション経由で Microsoft Entra グループを使用する
• 4 - 類似した ID 要件を持つアプリケーションに対してのみ単一の BTP サブアカウントを使用する
• 5 - すべてのエンド ユーザーの認証と認可に対して実稼働の IAS テナントを使用する
• 6 - SAML 署名証明書のロールオーバーのためにプロセスを定義する

1 - SAP Business Technology Platform と SAP SaaS アプリケーションでは SAP ID 認証サービスを通してフェデレーション認証を使用する

Context

BTP 内のアプリケーションは、信頼の構成を介して ID プロバイダーを使用し、BTP/XSUAA と ID プロバイダーの間で SAML 2.0 プロトコルを使用してユーザーを認証できます。 アプリケーション自体と BTP/XSUAA (このコンテキストでは重要ではありません) の間で OpenID Connect プロトコルが使用される場合であっても、SAML 2.0 だけがサポートされることに注意してください。

BTP では、SAP Cloud Identity Services - Identity Authentication (既定) に対して信頼の構成を設定することを選択できますが、権限のあるユーザー ディレクトリが Microsoft Entra ID であるときは、ユーザーが既存の Microsoft Entra アカウントでサインインできるようにフェデレーションを設定できます。

フェデレーションに加えて、BTP 内に Microsoft Entra ユーザーが前もってプロビジョニングされるように、必要に応じてユーザー プロビジョニングを設定できます。 ただし、これにはネイティブ サポートがありません (Microsoft Entra ID から SAP Identity Authentication サービスに対してのみ)。ネイティブ サポートがある統合ソリューションは BTP Identity Provisioning サービスになります。 ユーザー アカウントをあらかじめプロビジョニングすると、認可目的に便利な場合があります (例: ロールにユーザーを追加する)。 ただし要件によっては、Microsoft Entra グループを使用してこれを実現することもできます (以下を参照)。つまり、ユーザー プロビジョニングをまったく必要としないことになります。

フェデレーション関係の設定時には、複数のオプションがあります。

• BTP/XSUAA から直接 Microsoft Entra ID にフェデレーションを行うことを選択できます。
• IAS とフェデレーションを行うことを選択できます。それが次に、企業の ID プロバイダー ("SAML プロキシ" とも呼ばれます) としての Microsoft Entra ID とフェデレーションするように設定されます。

SAP SaaS アプリケーションの場合、IAS がプロビジョニングされて、エンド ユーザーが容易にオンボードできるよう事前に構成されます。 (この例には、SuccessFactors、Marketing Cloud、Cloud for Customer、Sales Cloud などが含まれています。)IAS はターゲット アプリに直接接続され、XSUAA にプロキシされないので、このシナリオの複雑さは低下しています。 いずれの場合も、IAS を使用する Microsoft Entra ID 全般については、この設定に同じ規則が適用されます。

推奨されていること

権限のあるユーザー ディレクトリが Microsoft Entra ID であるときは、BTP で IAS に対する信頼の構成を設定することをお勧めします。 IAS は次に、企業 ID プロバイダーとしての Microsoft Entra ID とフェデレーションするように設定されます。

BTP での信頼の構成については、[ログオン時にシャドウ ユーザーを作成する] を有効にすることをお勧めします。 このようにすると、まだ BTP 内に作成されていないユーザーは、IAS/Microsoft Entra ID を介して初めてサインインするときにアカウントを自動的に取得します。 この設定が無効にされると、事前にプロビジョニングされたユーザーのみがサインインを許可されます。

これが推奨される理由

フェデレーションを使用する場合は、BTP のサブアカウント レベルで信頼の構成を定義することを選択できます。 その場合、使おうとしている他のサブアカウントごとに構成を繰り返す必要があります。 IAS を中間の信頼の構成として使用することで、複数のサブアカウント間にわたり、一元化された構成を利用できます。また、リスクベースの認証や、一元的なアサーション属性のエンリッチメントなどの IAS 機能を使用できます。 ユーザー エクスペリエンスを保護するため、これらの高度なセキュリティ機能の適用は、1 つの場所でのみ行う必要があります。 これは、IAS にすることも、Microsoft Entra ID を権限のある唯一のユーザー ストアとして維持すること (このホワイト ペーパーでの前提と同様) もできます。後者のときは Microsoft Entra の条件付きアクセス管理によって一元的に処理されます。

注: IAS からは、そのサブアカウント内で 1 つ以上のアプリケーションをデプロイできる場合でも、すべてのサブアカウントが "アプリケーション" だと見なされます。 IAS 内では、そのようなアプリケーションすべてを、企業の同じ ID プロバイダー (この場合は Microsoft Entra ID) とのフェデレーション用に設定できます。

実装についてのまとめ

Microsoft Entra ID:

• 必要に応じて、シームレスにシングル サインオンするように Microsoft Entra ID を構成します (シームレス SSO)。これによってユーザーは、企業ネットワークに接続される企業デバイスを使用するときに自動的にサインインされます。 この機能を有効にすると、ユーザーは Microsoft Entra ID にサインインするためのパスワードの入力と、通常はユーザー名の入力も行う必要がなくなります。

Microsoft Entra ID と IAS:

• ドキュメントに従って、Microsoft Entra ID をフェデレーション (プロキシ) モードで IAS に接続します (SAP のドキュメント、Microsoft のドキュメント)。 UPN はメール アドレスであるとは限らないため、Microsoft Entra ID の SSO 構成にある NameID の設定に注意してください。
• [Conditional Authentication] ページに移動し、[Default Authenticating Identity Provider] を、Microsoft Entra ディレクトリを表す企業 ID プロバイダーに設定することで、Microsoft Entra ID を使用するように [Bundled Application] を構成します。

BTP 内:

• IAS に向けた信頼の構成を設定し (SAP ドキュメント)、[ユーザー ログオンで使用可能] と [ログオン時にシャドウ ユーザーを作成する] の両方が有効になっているようにします。
• 必要に応じて、ユーザーが常に Microsoft Entra ID 経由で認証され、ID プロバイダーを選択する画面が表示されないように、既定の [SAP ID Service] 信頼の構成の [Available for User Logon] を無効にします。

2 - 認証に Microsoft Entra ID を、承認に IAS/BTP を使用する

Context

Microsoft Entra ID へのフェデレーション経由で BTP と IAS がユーザー認証用に構成されているときには、承認を構成するためのオプションが複数あります。

• Microsoft Entra ID では、Microsoft Entra ID で SAP IAS インスタンスを表すエンタープライズ アプリケーションに Microsoft Entra ユーザーとグループを割り当てることができます。
• IAS では、リスクベースの認証を使用して BTP 内のアプリケーションへのアクセスを防止することによって、サインインを許可またはブロックできます。
• BTP では、ロール コレクションを使用して、アプリケーションにアクセスしてユーザーとグループを定義し、特定のロールを取得できます。

推奨されていること

Microsoft Entra 自体に承認を直接含めずに、Microsoft Entra ID で、エンタープライズ アプリケーションの [ユーザーの割り当てが必要] を明示的にオフにすることをお勧めします。 SAML アプリケーションの場合、この設定は既定で有効になっているため、明示的なアクションを実行して無効にする必要があることに注意してください。

これが推奨される理由

アプリケーションが IAS 経由でフェデレーションされているとき、Microsoft Entra ID の観点からは、ユーザーは本質的に、サインイン フロー中に "IAS に対して認証している" ことになります。 つまり、Microsoft Entra ID には、ユーザーがサインインしようとしている最終的な BTP アプリケーションに関する情報がありません。 Microsoft Entra ID での承認を使用できるのは、非常におおざっぱな承認を実行する目的のみであることも意味します (ユーザーがサインインできる BTP 内のアプリケーションを "すべて" や "なし" にするなど)。 ここでは、BTP のサブアカウント レベルでアプリと認証メカニズムを分離する SAP の戦略も重要視されています。

これは、[ユーザーの割り当てが必要] を使用する有効な理由になり得ますが、承認情報を保守する場所が 2 カ所になる可能性があることも意味します。この場合、エンタープライズ アプリケーションの Microsoft Entra ID (これは "すべて" の BTP アプリケーションに適用されます) と、それぞれの BTP サブアカウントの両方で、承認情報を保守する必要があるということです。 これは、認可の設定が 1 つの場所で更新されても他の場所では更新されないという、混乱や構成ミスにつながる可能性があります。 たとえば、ユーザーが BTP で許可されても Microsoft Entra ID でアプリケーションに割り当てられていないと、認証に失敗する結果になります。

実装についてのまとめ

IAS とのフェデレーション関係を表す Microsoft Entra エンタープライズ アプリケーションで、[ユーザーの割り当てが必要] を無効にします。 これは、ユーザーの割り当てを安全にスキップできることも意味します。

3 - 承認に IAS/BTP のロール コレクション経由で Microsoft Entra グループを使用する

Context

BTP アプリケーションの認可を構成するときには複数のオプションがあります。

• アプリケーション自体の内部で、サインインしたユーザーに基づいてきめ細かなアクセス制御を構成できます。
• ユーザーやグループの割り当てに基づいて、BTP でのロールとロール コレクションを通してアクセスを指定できます。

最終的な実装では、両方の戦略を組み合わせて使用できます。 ただし、ロール コレクションを通した割り当ての場合、それをユーザーごとに実行することも、構成済みの ID プロバイダーのグループを使用することもできます。

推奨されていること

きめ細かな承認のための権限のあるソースとして Microsoft Entra ID を使用する場合は、Microsoft Entra グループを使用し、それらを BTP のロール コレクションに割り当てることをお勧めします。 これにより、特定のアプリケーションへのアクセス権をユーザーに付与するために、IAS/BTP で追加構成を行う必要がなく、単にそれらを関連する Microsoft Entra グループに追加すれば済みます。

この構成では、グループの一意の識別子として、表示名 ("sAMAccountName") ではなく Microsoft Entra グループのグループ ID (オブジェクト ID) を使用することをお勧めします。 つまり、グループ ID を、Microsoft Entra ID によって発行される SAML トークン内で "グループ" アサーションとして使用する必要があるということです。 さらに、グループ ID は、BTP でのロール コレクションへの割り当てに使用されます。

これが推奨される理由

"ユーザー" を BTP のロール コレクションに直接割り当てると、Microsoft Entra ID で承認の決定を一元化することになりません。 これは、ユーザーが、BTP のロール コレクションに割り当てられる前に、既に IAS 内に存在している必要があることも意味します。また、ユーザーのプロビジョニングではなくフェデレーションをお勧めしているため、ユーザー割り当てを行う時点では IAS 内にユーザーのシャドウ アカウントがまだ存在しない可能性があります。 Microsoft Entra グループを使用して、それらをロール コレクションに割り当てると、この問題がなくなります。

ロール コレクションにグループを割り当てることは、"承認" に Microsoft Entra ID を使用しないという前出の推奨事項と矛盾するように思われるかもしれません。 ただしこの場合でも、承認の決定は引き続き BTP で行われます。決定が、Microsoft Entra ID で管理されているグループ メンバーシップに基づいて行われるようになるだけです。

Microsoft Entra グループの名前ではなく、そのグループ ID を使用することをお勧めします。グループ ID は、グローバルに一意で変更できず、後で別のグループに再利用できないためです。グループ名を使用すると、名前が変更されたときに問題につながる可能性があり、グループが削除され、同じ名前であるが、アプリケーションへのアクセス権を持たせないユーザーを含む別のグループが作成されるというセキュリティ上のリスクがあります。

実装についてのまとめ

Microsoft Entra ID:

• BTP 内のアプリケーションにアクセスする必要があるユーザーを追加できるグループを作成します (例: BTP 内のロール コレクションごとに Microsoft Entra グループを作成します)。
• IAS とのフェデレーション関係を表す Microsoft Entra エンタープライズ アプリケーションで、SAML ユーザーの属性とクレームを構成して、セキュリティ グループのグループ クレームを追加します。

  • [ソース] の属性を [グループ ID] に、[名前] を Groups に設定します (このように大文字の "G" で正確に書きます)。

  • さらに、クレームのペイロードを小さく抑え、Microsoft Entra ID が SAML アサーションのグループ クレーム数を制限するための制限値である 150 に達しないように、クレームに返されるグループを、明示的に割り当てたグループのみに制限することを強くお勧めします。

    • 「要求でユーザーに関連付けられているグループを返す必要がありますか?」で、「アプリケーションに割り当てられたグループ」と回答します。次に、要求として含めるグループに対して、[ユーザーとグループ] セクションを使用して [ユーザーとグループ]、[ユーザー/グループの追加] の順に選択してエンタープライズ アプリケーションに割り当てます。

    

IAS 内:

• [Corporate Identity Provider] 構成の [Identity Federation] オプションで、[Use Identity Authentication user store] が無効であることを確認します。それ以外の場合、Microsoft Entra ID のグループ情報が BTP に対する SAML トークン内に保持されず、承認が失敗します。

BTP 内:

• そのサブアカウント内のアプリケーションによって使用されるロール コレクションで、IAS の ID プロバイダーの構成を追加し、[Name] を Microsoft Entra グループのグループ ID (オブジェクト ID) に設定することで、ロール コレクションをユーザー グループにマップします。

4 - 類似した ID 要件を持つアプリケーションに対してのみ単一の BTP サブアカウントを使用する

Context

BTP 内では、各サブアカウントに複数のアプリケーションを含めることができます。 ただし、IAS の観点から見ると、"バンドルされたアプリケーション" は完全な BTP サブアカウントであり、その中のより小さな単位のアプリケーションではありません。 これは、信頼設定、認証、アクセス構成、IAS でのブランド化とレイアウトのオプションはすべて、そのサブアカウント内のすべてのアプリケーションに適用されることを意味します。 同様に、BTP での信頼の構成とロール コレクションはすべて、そのサブアカウント内のすべてのアプリケーションにも適用されます。

推奨されていること

複数のアプリケーションを 1 つの BTP サブアカウント内で組み合わせることは、ID レベル (ユーザー、グループ、ID プロバイダー、ロール、信頼の構成、ブランド化など) で同様の要件がある場合のみとすることをお勧めします。

これが推奨される理由

BTP の 1 つのサブアカウント内に、ID 要件が大きく異なる複数のアプリケーションを組み合わせると、安全でない構成ができてしまったり、構成ミスが発生しやすくなる可能性があります。 たとえば、BTP 内の 1 つのアプリケーションのために、ID プロバイダーのような共有リソースに対して構成変更を加えると、この影響は、この共有リソースに依存しているすべてのアプリケーションに及びます。

実装についてのまとめ

BTP 内の複数のサブアカウントにわたって複数のアプリケーションをグループ化する方法については、慎重に検討してください。 詳細については、SAP のアカウント モデルに関するドキュメントを参照してください。

5 - すべてのエンド ユーザーの認証と認可に対して実稼働の IAS テナントを使用する

Context

IAS を使用する場合は、一般に、実稼働と Dev/Test 用のテナントが存在しています。 BTP のさまざまなサブアカウントやアプリケーションのために、使用する ID プロバイダー (IAS テナント) を選択できます。

推奨されていること

エンド ユーザーとのいかなる対話についても、常に実稼働の IAS テナントを使用することをお勧めします。サインインする必要がある "アプリケーション" の開発/テスト用のバージョンや環境のコンテキストにおいても同様です。

その他の IAS テナントは、ID 関連の構成のテストにのみ使用することをお勧めします。これは、実稼働のテナントから切り離して実施する必要があります。

これが推奨される理由

IAS は、Microsoft Entra ID とフェデレーションするように設定された、一元化されたコンポーネントであるため、フェデレーションと ID の構成を設定し、保守する必要がある場所は 1 つのみです。 他の IAS テナントでこれを複製すると、環境間のエンド ユーザー アクセスの構成ミスや不整合が発生する可能性があります。

6 - SAML 署名証明書のロールオーバーのためにプロセスを定義する

Context

Microsoft Entra ID と IAS の間や、IAS と BTP の間にフェデレーションを構成すると、両者間で送信される SAML トークンの暗号化と暗号署名に使用される X.509 証明書が含まれている SAML メタデータが交換されます。 これらの証明書には有効期限があり、(たとえば証明書が侵害された場合の緊急時であっても) 定期的に更新する必要があります。

注: SAML アサーションに署名するために使用される初期 Microsoft Entra 証明書の既定の有効期間は 3 年です (Microsoft Entra ID のグローバル証明書によって署名される OpenID Connect や OAuth 2.0 のトークンとは異なり、証明書はエンタープライズ アプリケーションに固有であることに注意してください)。 有効期限が異なる新しい証明書を生成するか、独自の証明書を作成してインポートするかを選択できます。

証明書は、有効期限が切れると使用できなくなるので、新しい証明書を構成する必要があります。 したがって、SAML トークンに署名するために使用されようとしている実際の証明書によって、証明書利用者 (これが署名を検証する必要があります) 内の証明書の構成が最新の状態に保たれるように、プロセスを確立する必要があります。

場合によっては、証明書利用者はこれを、最新のメタデータ情報を動的に返すメタデータ エンドポイント、つまり、通常は一般にアクセスできる URL を提供することによって自動的に実行できます。証明書利用者は、そこから定期的にメタデータを取得し、内部の構成ストアを更新できます。

ただし、IAS は、メタデータ XML ファイルのインポート経由で設定する企業 ID プロバイダーのみを許可します。Microsoft Entra メタデータを動的に取得するためのメタデータ エンドポイント (https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id など) の提供はサポートされていません。 同様に、BTP 利用時には、IAS メタデータ エンドポイント (https://my-ias-tenant.accounts.ondemand.com/saml2/metadata など) から新しい信頼の構成を設定することはできません。メタデータ XML ファイルの 1 回限りのアップロードも必要です。

推奨されていること

任意の 2 つのシステム間 (Microsoft Entra ID と IAS、IAS と BTP など) に ID フェデレーションを設定するときは、使用される証明書の有効期限をキャプチャするようにしてください。 これらの証明書の置き換えが可能なことを事前に確認し、これらの証明書に依存するすべての証明書利用者に、新しいメタデータを更新するための文書化されたプロセスが存在することを確認します。

前述したように、BTP で IAS に対する信頼の構成を設定することをお勧めします。これは次に、企業 ID プロバイダーとしての Microsoft Entra ID とフェデレーションするように設定されます。 この場合、以下の証明書が重要です (これらは SAML の署名と暗号化に使用されます)。

• BTP でのサブアカウント証明書: これが変更されたら、IAS でのアプリケーションの SAML 2.0 構成を更新する必要があります。
• IAS のテナント証明書: これが変更されたら、Microsoft Entra ID のエンタープライズ アプリケーションの SAML 2.0 構成と、BTP の信頼の構成の両方を更新する必要があります。
• Microsoft Entra ID のエンタープライズ アプリケーション証明書: これが変更されたら、IAS の企業 ID プロバイダーの SAML 2.0 構成を更新する必要があります。

SAP では、SAP Cloud Integration を使用したクライアント証明書通知と有効期限が近づいた場合の操作に関する実装例が用意されています。 これを、Azure Integration Services または PowerAutomate を使用して適合させることができる場合があります。 ただしこれらを、サーバー証明書で機能するように適合させる必要があります。 そのようなアプローチでは、カスタム実装が必要になります。

これが推奨される理由

証明書の有効期限が切れるままになった場合や、それらが期間内に置き換えられても、それらに依存する証明書利用者が新しい証明書情報によって更新されていない場合、ユーザーはフェデレーション介してどのアプリケーションにもサインインできなくなります。 これは、メタデータの再構成によってサービスを復元する間、すべてのユーザーに膨大なダウンタイムが生じることを意味します。

実装についてのまとめ

Microsoft Entra ID で、証明書の有効期限のメール通知アドレスを追加し、送信先が 1 人の個人 (証明書の有効期限が切れようとしているときには、アカウントを持たなくなっている可能性さえあります) にならないように、それをグループのメールボックスに設定します。 既定では、エンタープライズ アプリケーションを作成したユーザーのみが通知を受信します。

証明書のロールオーバー プロセス全体を実行するように自動化を構築することを検討してください。 たとえば、有効期限が切れる証明書を定期的にチェックし、すべての証明書利用者を新しいメタデータで更新している間に、それらを置き換えることができます。

ID プロバイダーとしての Azure AD B2C の使用

Azure Active Directory B2C は、サービスとしての企業-消費者間 (B2C) ID が提供されます。 Azure AD B2C との統合が、Microsoft Entra ID を使用したサインインをエンタープライズ ユーザーに許可する方法と似ているとすると、顧客、消費者、市民に対して Azure AD B2C を使用して、それぞれが希望するソーシャル、エンタープライズ、またはローカルのアカウント ID の使用を許可するときにも、上記の推奨事項がほぼあてはまります。

ただし、いくつか重要な相違点があります。 IAS で企業 ID プロバイダーとして Azure AD B2C を設定し、両方のテナント間でフェデレーションを構成することについては、このブログ記事で詳しく説明されています。

Azure AD B2C での SAML アプリケーションの登録

Azure AD B2C には、IAS での企業 ID プロバイダーに対する信頼関係を簡単に構成するために使用できるエンタープライズ アプリケーションのギャラリーがありません。 代わりに、カスタム ポリシーを使用して、Azure AD B2C に SAML アプリケーションを登録する必要があります。 ただし、この SAML アプリケーションは、Microsoft Entra ID のエンタープライズ アプリケーションと同じ論理役割を果たすため、たとえば SAML 証明書のロールオーバーに関する同じガイダンスが適用されます。

Azure AD B2C での認可

Azure AD B2C は、アクセス権を割り当てることができるユーザーのコレクションを作成するためのグループの使用はネイティブにサポートしていません。つまり、承認に BTP のロール コレクション経由で Microsoft Entra グループを使用するためのガイダンスを異なる方法で実装する必要があります。

幸い Azure AD B2C は高度なカスタマイズが可能なので、IAS に送信する SAML トークンを構成して、カスタム情報を含めることができます。 認可要求のサポートに関するさまざまなオプションについては、Azure AD B2C アプリ ロールのサンプルに付随するドキュメントを参照してください。ただし、要約すると、その API コネクタの機能拡張メカニズムを通じて、必要に応じてグループ、アプリ ロール、カスタム データベースを使用して、ユーザーがアクセスできる対象を決定することができます。

認証情報の取得元に関係なく、これは、SAML トークン内の Groups 属性として生成できます。その場合、その属性名を要求スキーマでの既定のパートナー要求の種類として構成するか、出力要求でのパートナー要求の種類をオーバーライドします。 ただし、BTP がロール コレクションをユーザー属性にマップできるようにすることに注意してください。つまり、Groups 属性名を使用しない場合でも、すべての属性名を認可決定に使用できます。

次の手順

• 初期セットアップの詳細については、このチュートリアルで説明します
• SAP ソースとターゲット アプリケーションのユーザー プロビジョニングに Microsoft Entra のデプロイ計画 と
• SAP アプリケーションへのアクセスを管理する
• その他の Microsoft Entra ID を使用した SAP 統合シナリオなどを参照する