チュートリアル: SCIM エンドポイントを検証する

このチュートリアルでは、Microsoft Entra SCIM Validator を使って、プロビジョニング サーバーが Azure SCIM クライアントと互換性があることを検証する方法について説明します。 このチュートリアルは、SCIM 互換サーバーを構築して、Microsoft Entra プロビジョニング サービスで ID を管理する必要がある開発者を対象としています。

このチュートリアルでは、次の作業を行う方法について説明します。

前提条件

• アクティブなサブスクリプションを持つ Microsoft Entra アカウント。 無料でアカウントを作成できます。
• SCIM 2.0 標準に準拠し、プロビジョニング サービス要件を満たす SCIM エンドポイント。 詳細については、「チュートリアル: Microsoft Entra ID の SCIM エンドポイントのプロビジョニングを開発および計画する」を参照してください。

テスト方法を選択する

最初の手順では、SCIM エンドポイントを検証するテスト方法を選択します。

1. Web ブラウザーを開き、SCIM Validator https://scimvalidator.microsoft.com/ に移動します。

2. 3 つのテスト オプションのいずれかを選択します。 既定の属性を使用する、スキーマを自動的に検出する、またはスキーマをアップロードすることができます。

   

既定の属性を使用する - システムでは既定の属性が用意されており、ニーズに合わせてこれを変更します。

スキーマを検出する - エンドポイントで /Schemas がサポートされている場合、このオプションによって、サポートされている属性をツールで検出できます。 このオプションを使用すると、アプリのビルド時にアプリを更新するオーバーヘッドが軽減されるため、このオプションをお勧めします。

Upload Microsoft Entra Schema (Microsoft Entra スキーマのアップロード) - Microsoft Entra ID 上のサンプル アプリからダウンロードしたスキーマをアップロードします。

テスト方法を構成する

テスト方法を選択したら、次の手順ではこれを構成します。

1. 既定の属性オプションを使用している場合は、指定されたすべてのフィールドに入力します。
2. スキーマの検出オプションを使用している場合は、SCIM エンドポイントの URL とトークンを入力します。
3. スキーマをアップロードする場合は、アップロードする .json ファイルを選択します。 このオプションには、Microsoft Entra 管理センター上のサンプル アプリからエクスポートした .json ファイルを指定できます。 スキーマをエクスポートする方法については、「方法: プロビジョニング構成をエクスポートし、既知の良好な状態にロールバックする」を参照してください。

4. 属性リストの末尾にある [属性の追加] オプションと、ページの右側にあるマイナス (-) 記号を使用して、ユーザーとグループの両方の種類のリスト属性を必要に応じて編集します。
5. ユーザー属性とグループ属性の両方の一覧から結合プロパティを選択します。

SCIM エンドポイントを検証する

最後に、エンドポイントをテストして検証する必要があります。

1. [Test Schema] (スキーマのテスト) を選択してテストを開始します。

2. 合格したテストと失敗したテストの概要を含む結果を確認します。

3. [詳細の表示] タブを選択し、問題を確認して修正します。

4. すべてのテストに合格するまで、スキーマのテストを続行します。

   

SCIM バリデーターが実行する検証内容を確認してください

新しいユーザーの作成

• POST /Users – 完全な JSON ペイロードを持つ新しいユーザーを作成します。
  • エンドポイントから HTTP 201 が返される
  • POST 応答に作成されたユーザー ID が含まれています
• GET /Users?filter={joiningProperty} eq "value" – 結合プロパティをフィルター処理して作成を検証します。
  • GET は作成されたユーザーを返します
  • GET から返される値は、POST 要求から渡された値と一致します (エンドポイントによって異なります)
• DELETE /Users - テスト ユーザーをクリーンアップします。 -ハード削除がサポートされている場合にのみ呼び出されます

重複するユーザーの作成

• POST /Users – 既存のユーザーと同じペイロード (同じ一意/結合属性を持つ) を使用してユーザーを作成しようとします。
  • 最初の作成要求で HTTP 201 を返す
  • 2 回目の作成要求で HTTP 409 を返す

属性の追加

• POST /Users - ユーザー リソースを作成します
  • HTTP 2xx の成功
• PATCH /Users/{id} – JSON パッチ ドキュメント (追加操作を含む) を使用して、追加の必須ではない属性を挿入します。
• GET /Users?filter={joiningProperty} eq "value" – 追加された属性を確認するユーザーを取得します。
  • ユーザーが返される
  • 挿入された属性がユーザーに存在するようになりました

ユーザー属性の置換

• POST /Users - ユーザー リソースを作成します
  • HTTP 2xx の成功
• PATCH /Users/{id} – JSON パッチ ドキュメント (置換操作を使用) を送信して、1 つ以上の属性を更新します。
• GET /Users?filter={joiningProperty} eq "value" – 更新された属性が正しく適用されていることを確認します。
  • ユーザーが返される
  • 更新された属性がユーザーに存在する

結合プロパティの更新

• POST /Users - ユーザー リソースを作成します
  • HTTP 2xx の成功
• PATCH /Users/{id} – JSON パッチ ドキュメントを使用して結合プロパティ (userName など) を更新します。
• GET /Users?filter={joiningProperty} eq "newValue" – 結合プロパティが更新されたことを確認します。
  • ユーザーに対して結合プロパティが更新されます

アクティブな属性を False に更新する

• POST /Users/ - スキーマに基づいてリソースを作成します
  • HTTP 2xx の成功
  • GET 要求で無効なユーザーを返す必要がある
• PATCH /Users/{id} – "active" 属性を false に設定する JSON パッチ ドキュメントを発行します。
  • HTTP 2xx の成功
• GET /Users?filter={joiningProperty} eq "value" – アクティブな属性が false になったことを確認するためにユーザーを取得します。
  • 返されたユーザー レコードは、ACTIVE=FALSE である必要があります。

新しいグループの作成

• POST /Groups – 完全な JSON ペイロードを持つ新しいグループを作成します。
  • エンドポイントから HTTP 201 が返される
  • POST 応答に作成されたグループ ID が含まれています
• GET /Group?filter={joiningProperty} eq "value" – 結合プロパティをフィルター処理して作成を検証します。
  • GET は作成されたグループを返します
  • GET から返される値は、POST 要求から渡された値と一致します (エンドポイントによって異なります)
• DELETE /Groups - テスト ユーザーをクリーンアップします。
  • ハード削除がサポートされている場合にのみ呼び出されます

重複するグループを作成する

• POST /Groups – 既存のグループと同じペイロード (同じ一意/結合属性を持つ) を使用してグループを作成しようとします。
  • 最初の作成要求で HTTP 201 を返す
  • 2 回目の作成要求で HTTP 409 を返す

グループ属性の更新

• POST /Groups - 属性を更新する新しいグループ リソースを作成します。
  • POST は HTTP 2xx を返します
• PATCH /Groups/{id} – 置換操作を使用して JSON パッチ ドキュメントを送信し、既存のグループの 1 つ以上の属性 (メンバーを除く) を更新します。
  • PATCH が成功を返す (HTTP 2xx)
• GET /Groups?filter={joiningProperty} eq "value" – グループの属性が正しく更新されたことを確認します。
  • GET は、修正プログラムが適用されたグループを返します
  • 返されたグループの属性は、PATCH 要求で変更された属性と一致します

新しいグループ リソースを作成する

• POST /Groups - メンバーを追加する新しいグループ リソースを作成します
  • POST は HTTP 2xx を返します
• POST /Users – グループ メンバーとして使用する新しいユーザー リソースを作成します。
  • POST は HTTP 2xx を返します
• PATCH /Groups/{id} – JSON パッチ ドキュメントを使用して、新しく作成されたユーザーの識別子をグループに追加します。
  • PATCH 成功を返します

SCIM Validator での式の使用

SCIM Validator では、式を使用して属性に必要な値を生成できます。

式を使用する方法

1. [属性] ページに移動します。
2. カスタマイズする属性の値の列に希望の式を入力します。
3. テストの実行

利用可能な式

次の表は、使用可能な式の一覧を示しています。

式の前または後に値を追加して目的の結果を得ることができます。たとえば、{% generateRandomString 6 %}@contoso.com を userName 属性の値フィールドに追加すると、contoso.com ドメインを保持しながらすべてのテストで新しい userName 値が生成されます。

リソースをクリーンアップする

テストで作成した Azure リソースが不要になった場合は、必ず削除してください。

Microsoft Entra SCIM Validator に関する既知の問題

• 論理的な削除 (無効化) はまだサポートされていません。
• タイム ゾーン形式がランダムに生成されるため、この検証を試みるシステムではエラーが発生します。
• パッチ ユーザーの削除属性によって、特定のシステムの必須属性の削除が試行される場合があります。 このようなエラーは無視する必要があります。

次のステップ

• Microsoft Entra アプリ ギャラリーにないアプリの追加方法の詳細