マルチブランドの必須項目制御とMapped Site

SAP CIAMを採用されるエンタープライズ企業では、一つのID基盤に対して、ECサイト、モバイルアプリ、会員ポータルなど、多数のサービスが接続される構成が一般的です。
こうした「One ID」「マルチサービス」の環境下でID認証基盤を導入する際、認証フローの設計者を悩ませるのが、「認証の統合」と「データ要件の個別性」のジレンマです。
ID基盤側で認証を一元化できたとしても、各サービスがユーザーに求める情報は必ずしも同一ではありません。あるサービスでは「住所」が必須であり、別のサービスでは「生年月日」が必須となることがあります。
こうしたビジネス要件の差異は、単一のOIDCプロバイダー設定だけでは吸収しきれないケースが多々あります。
今回は、SAP CIAMのOIDC機能において、この課題を解決するための鍵となる機能「Mapped Site」に焦点を当てます。サービスごとに異なるコンテキストを定義し、適切なデータ検証とScreen-Setの出し分けを実現する方法について解説します。

技術的課題：親サイト認証における「コンテキストの不在」

SAP CIAMをOpenID Provider（OP）として稼働させる場合、技術的には「親サイト（Parent Site）」が認証の窓口となります。各サービス（Relying Party：以下 RP）からのAuthorize Requestは親サイトに対して行われ、発行されるIDトークンも親サイトの署名鍵に基づきます。
しかし、ここに実運用上のギャップが生じます。各サービス（RP）が本来求めているのは、「親サイトの汎用的なユーザー情報」ではなく、「特定のブランド（子サイト）における有効な会員情報」である場合が多いからです。
例えば、以下のような要件の違いを見てみましょう。

• RP 1（ブランドA）：商品配送のため「zipCode（郵便番号）」が必須
• RP 2（ブランドB）：年代確認のため「birthYear（生年月）」が必須

RPの設定で特段の指定を行わない場合、SAP CIAMは「親サイトのポリシー」で認証を完結させます。そのため、ユーザーがブランドA（RP 1）にログインしようとした際、たとえ郵便番号が未入力であっても、親サイトとしての認証が通ればトークンが発行されてしまいます。
結果として、RP側でトークン受領後にクレーム（Claims）の中身を精査し、不足があれば独自の入力画面へリダイレクトさせるという、「ID基盤を入れたはずなのに、アプリ側に登録ロジックが残る」という状況が発生します。

解決策：「Mapped Site」によるコンテキスト・スイッチ

この課題を、アプリ側の改修なしに解決するのが 「Mapped Site」機能です。
この機能は、SAP CIAM側のOIDC RP設定において、「このRPからのリクエストは、特定の子サイト（Child Site）へのアクセスとして扱う」と定義するものです。これにより、認証処理のコンテキスト（主語）を、親サイトから指定した子サイトへと強制的に切り替えることが可能になります。

設定パラメータ

SAP CIAMコンソールのOutbound Federation設定にて、以下のマッピングを行います。

• 設定箇所：Identity > Connect > Outbound Federation > OIDC > RP Settings
• 設定画面：RP（Client ID）ごとの設定詳細
• パラメータ：OIDC RP Settings画面内の「Mapped Site」

図1：SAP CIAM Console - OIDC RP Settings画面

（Mapped Siteの入力欄に、紐付けたい子サイトのAPI Keyを指定することで、コンテキストの切り替えが有効化されます。）

「Mapped Site」がもたらす2つの挙動変化

この設定を投入することで、OIDCの認証フローには以下の変化が生じます。

1. 不足情報登録（Registration Completion）の自動化

認証フローで、SAP CIAMは指定された子サイトのSchema（データ定義）を参照します。
もし、ログインしようとしているユーザーのプロファイルにおいて、その子サイトで 必須となっている項目が未入力の場合、SAP CIAMはトークン発行を保留し、自動的に不足情報登録フロー（Registration Completion）を割り込ませます。

図2：Mapped Site設定時の認証シーケンス

（通常フローとは異なり、コンテキスト切り替えによって子サイトのSchema検証が走り、不足項目がある場合は自動的に入力画面が表示されます。）

これにより、RPがIDトークンを受け取った時点では、「当該サービスに必要な必須項目はすべて登録済みである」ことが保証されます。

2. Screen-Setとポリシーの最適化

不足情報登録フロー（Registration Completion）で表示される画面や、新規登録時の画面は、マッピングされた子サイトのScreen-Set設定を利用します。
これにより、以下のような制御が設定ベースで可能になり、RPごとにScreen-Set表示時のパラメータを動的に書き換えるような複雑な実装は不要となり、構築、運用負荷を大幅に低減できます。

• RP Aの場合：ブランドA用デザイン（Child Site AのScreen-Set）を表示
• RP Bの場合：ブランドB用デザイン（Child Site BのScreen-Set）を表示

実装・検証時のチェックポイント

本機能を利用する際、単純な設定ミス以上に、「ユーザーがログインできなくなる（デッドロックする）」ケースや、「意図した規約が表示されない」といった論理的な不整合に注意が必要です。

1. SchemaとScreen-Setの乖離による「登録デッドロック」の回避

「Mapped Site」によって「Schema検証」が厳密になると、「Schemaでは必須だが、入力画面（Screen-Set）に入力項目が存在しない」という状態が致命的になります。

• 現象：「ユーザーがログイン」 → 「必須項目（例：郵便番号）の欠落を検知」 → 「 不足情報登録画面の表示」→ 「画面上に『郵便番号入力欄』が無い」 → 「ユーザーは不足情報を登録できず先に進めない」
• 対策：子サイト側の不足情報登録画面（Registration Completion）に、その子サイトのSchemaで 必須に設定されている全てのフィールドを含める必要があります。親サイトのScreen-Setを流用している場合などに発生しやすいため、サイトごとの整合性チェックが不可欠です。

2. Consent（同意）管理とバージョンアップ検証

「Mapped Site」は、データ項目だけでなく 「Consent（規約同意）」 のステータス管理も子サイトのコンテキストで行います。よって、ブランドA（RP 1）で利用規約を改定（バージョンアップ）した場合、ブランドAの次回ログイン時には正しく「再同意画面（Re-consent）」が表示されるか。また、規約変更のないブランドB（RP 2）へのログイン時には、影響を与えずスムーズにログインできるかの確認が必要になります。

おわりに

OIDC認証は「つながる」ことがゴールではなく、「適切な状態でつながる」ことがゴールです。 SAP CIAMの「Mapped Site」は、マルチブランド展開におけるデータガバナンスとUXを両立させる強力な機能のため、ぜひ活用を検討してみてください。
SAP CIAMについてもっと詳しく話を聞きたい、相談したい、という方は、弊社までお問い合わせください。