アカウント登録時の独自バリデーションとデータ補完

SAP CIAMを採用される企業の多くは、標準提供される「Screen-Sets」や「Schema」を活用し、スピーディーにID認証基盤を構築しています。これら標準機能の充実がIDaaSの強みですが、エンタープライズの複雑なビジネス要件においては、標準機能だけでは対応しきれないケースが存在します。
例えば、「登録時に入力された招待コードが、現在有効なキャンペーンかリアルタイムにチェックしたい」というバリデーション要件や、「登録と同時に、バックエンドシステムで独自の会員IDを採番し、Schemaに保存したい」というデータの自動補完要件です。
今回は、SAP CIAMの標準フローに独自のサーバーサイドロジックを割り込ませることができる機能、「Extensions」について解説します。具体例として、アカウント登録直前に処理をフックする OnBeforeAccountsRegister を用いた2つの開発アプローチ（検証と補完）をご紹介します。

技術的課題：フロントエンド処理と非同期処理の限界

外部システムと連携した複雑な登録制御やデータ付与を実装しようとした際、以下の2つのアプローチを検討しますが、どちらも課題が残ります。

フロントエンド（JavaScript）での処理：

Screen-Setsのイベント（onSubmitなど）を使って外部APIをコールする方法です。しかし、この方法はブラウザ上で処理が完結するため、悪意のあるユーザーによって簡単に改ざんやスキップされてしまうセキュリティリスクがあります。

Webhooks（非同期通信）の利用：

SAP CIAMのWebhooksを使えば、サーバーサイドで安全に連携できます。しかし、Webhooksは「非同期」であるため、イベントを受け取った時点で「すでにCIAM上にはユーザーが作成されてしまっている」という致命的なタイミングのズレが生じます。
つまり、必要なのは「ユーザーがDBに保存される直前」に、「サーバーサイドで安全に」、「同期的に」実行される独自のロジックとなります。

解決策：Extensionsによる「同期的」なインターセプト

この要件を満たすのが、SAP CIAMの「Extensions」機能です。
Extensionsは、CIAMの標準APIフロー（登録、ログイン、プロファイル更新など）の特定のポイントで処理を一時停止し、お客様が用意した外部のエンドポイントへHTTPリクエストを送信する仕組みです。
その中でも、アカウントの新規作成時に頻繁に利用されるのが OnBeforeAccountsRegister で、「accounts.register APIが呼ばれた直後、かつデータベースに保存される前」にトリガーされます。
この機能は、大きく分けて「バリデーション（検証）」と「Enrich（データの補完）」の2つの役割を担うことができます。

参考】その他の主要なExtensionsエンドポイント

Extensionsでは、登録時以外にも様々なタイミングで処理を割り込ませることが可能です。

OnBeforeAccountsLogin：ログイン直前にトリガーされます。外部システムによる追加のリスク評価や、特定条件下でのログインブロックなどに活用されます。
OnBeforeSetAccountInfo：プロフィール更新直前にトリガーされます。ユーザーが入力した住所や電話番号が正しいか、外部APIでバリデーションする際などに利用されます。

実装例①：外部システム照合による「バリデーション」

まずは「有効な招待コード（キャンペーンコード）を入力しないと登録させない」というバリデーションのメカニズムです。

処理のフック：ユーザーがScreen-Setsでメールアドレスや「招待コード」を入力して登録ボタンを押すと、CIAMはデータベースへの保存処理を一時停止し、入力データを独自のエンドポイント（AWS Lambda等）へ送信します。
独自ロジックの実行：独自エンドポイントで自社のキャンペーン管理システムのAPIを叩き、入力された招待コードの有効性（実在するか、使用済みでないか等）を確認します。
結果の返却：無効・使用済みの場合、{“status”: “FAIL”} と共に、特定フィールドに対するエラーメッセージ（例：「無効な招待コードです」）を返却します。
UIへのフィードバック： CIAMは登録処理をブロックし、Extensionsから返ってきたエラーメッセージをScreen-SetsのUI上に表示させ、ユーザーに再入力を促します。

実装例②：Enrich機能による「データの自動補完・登録」

Extensionsのもう一つの使い方が、EnrichによるSchema項目へのデータ自動登録です。
例えば、「ユーザーが登録した際、裏側で独自の「会員ID」を採番し、CIAMのSchemaに保存しておきたい」という要件があるとします。これはユーザーに入力させるわけにはいかないため、バックエンドで処理する必要があります。

独自ロジックでのデータ生成： OnBeforeAccountsRegister で呼び出された独自エンドポイント内で、基幹システムと連携して新しい会員ID（例：MEM12345）を採番します。
データの書き込み（Enrich）：独自エンドポイントからCIAMへレスポンスを返す際、{“status”: “OK”} とするだけでなく、data オブジェクトを含めて返却します。
```
{
  "status": "OK",
  "data": {
      "memberID": "MEM12345"
  }
}
```
Schemaへの自動保存： CIAMはこのレスポンスを受け取ると、フロントエンドから送信されたユーザー情報に、上記のデータを裏側でマージ（Enrich）し、そのままデータベース（Schema）へ保存します。

これにより、クライアント側（ブラウザ）を経由することなく、安全かつ確実に必要なメタデータをユーザープロファイルに付与することができます。

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

Extensionsは非常に強力な機能ですが、認証フローの「クリティカルパス（同期処理）」に組み込まれるため、設計・実装には注意が必要です。

①厳格なタイムアウト設計

Extensionsの呼び出しには、SAP CIAM側で短いタイムアウト時間（デフォルトで1秒）が設定されています。呼び出し先の独自APIの処理が遅延するとタイムアウト・エラーとなり、登録処理が予期せず失敗する可能性があります。独自API側の処理応答速度を考慮して設定する必要があります（最大10秒まで設定可能）。

②フォールバック（Fallback）戦略

もし独自API側のサーバーがダウンしていた場合、「登録をブロックしてエラーにする（Fail Closed）」のか、「チェックやデータ補完をスキップして一旦登録を許可する（Fail Open）」のか、ビジネス要件に合わせてExtensionsの設定（Fallback Behavior）を適切に定義しておく必要があります。キャンペーンコードの有効性確認や会員ID採番を行う場合は、一貫性を保つために登録をブロックしてエラーにする（Fail Closed）設定が必要となるケースが一般的です。

③Enrichする項目のSchema定義

Enrich機能でデータを保存する場合、返却するJSONのキーが、CIAM側のとして事前に正しく定義されている必要があります。Schemaに存在しないフィールドへデータを書き込もうとした際はエラーとなるため、Schemaへの事前登録が必要です。

④外部エンドポイントとのセキュアな通信（カスタムヘッダ）

CIAMから独自エンドポイント（Lambda等）へリクエストを送信する際、それが本当にCIAMからの正当なリクエストであるかを検証する必要があります。
Extensionsの設定では、任意の「カスタムヘッダ」をリクエストに付与することが可能です。独自エンドポイント側でこのヘッダを簡易的に検証することで、不正アクセスを防ぎます。

図1：Extensions設定画面

⑤リクエストの正当性検証（JWSシグネチャ検証）

カスタムヘッダによる検証に加えて、より強固なゼロトラスト・セキュリティが求められる場合、SAP CIAMから送信されるリクエストのペイロード検証が可能です。
CIAMから外部システムへ送信されるデータは、JWS（JSON Web Signature）形式でデジタル署名されています。独自エンドポイント側でSAPの公開鍵を使用してこの署名を検証することで、「リクエストが確実にSAP CIAMから送信されたこと」および「通信途中でデータが改ざんされていないこと」を保証できます。

図2：JWS

図3：デコードされたヘッダ

図4：デコードされたペイロード

おわりに

SAP CIAMの「Extensions」は、標準機能の枠を超えて、自社の複雑なビジネスルールをID認証フローに安全に組み込むための切り札となります。
単なる「登録前のエラーチェック」にとどまらず、今回ご紹介した「Enrich機能」によるデータの自動補完を組み合わせることで、よりセキュアで、外部システムと密に連携した高度なID基盤の構築が可能になります。
SAP CIAMについてもっと詳しく話を聞きたい、相談したい、という方は、弊社までお問い合わせください。