SCIMディスカバリエンドポイント
SCIM 2.0は、IDプロバイダーが手動ですべての操作を試すことなく、SCIMサーバーが何をサポートするかを学べる3つのディスカバリエンドポイントを定義します。SecureCodingHubは3つすべてを提供します。ほとんどのIdPは、初期接続テスト中にそれらを自動的に呼び出します。
3つのエンドポイント
3つすべてが、SCIM APIの残りと同じプレフィックスの下にあります。{base}をhttps://api.limeplate.com/api/sch/scim/v2に置き換えてください:
| エンドポイント | 目的 |
|---|---|
{base}/ServiceProviderConfig | SCIM Service Provider Configドキュメント。サーバーがサポートする操作 (PATCH、フィルタリング、bulk、sort、change passwordなど) と、その境界をIdPに伝えます。 |
{base}/Schemas | このテナントが提供するSCIMスキーマを返します。Core UserとCore Groupスキーマ、および任意の拡張を含みます。 |
{base}/ResourceTypes | このテナントが公開するリソースタイプ (User、Group) と、それぞれのURLプレフィックスを返します。 |
それらが必要なとき
ほとんどの場合、必要ありません — OktaとAzure ADの両方が、SCIM接続テスト中および属性マッピングセットアップ中にこれらのエンドポイントを自動的に呼び出し、レスポンスを見ることはありません。エンドポイントは次の場合に関連性があります:
- カスタムSCIMクライアントを書いており、フィルターパーサーが受け入れる演算子を知る必要がある場合。
- IdPの接続テストが失敗し、エラーが3つのディスカバリエンドポイントの1つを参照する場合 — 実際のレスポンスを見ると、ベンダードキュメントを読むよりも早く誤構成を表面化させることがよくあります。
- 監査員がテナントによってアドバタイズされるSCIM機能のドキュメントを要求する場合。3つのエンドポイントが一緒にそのドキュメントを形成し、リクエストごとに更新されます。
レスポンスが伝えること
ServiceProviderConfigは日々最も役立つ3つです。フィルター操作がサポートされているがeq演算子に制限されていること、PATCHがサポートされていること、bulk操作がサポートされていないこと、パスワード変更エンドポイントが実装されていないこと、SCIM側のドキュメントが存在する場所 (このサイト) をIdPに伝えます。ほとんどのSCIMバグは、IdPが何を期待しているかとSPが何ができると言うかの不整合です。設定レスポンスを読むことが、どちらの側が間違っているかを確認する最速の方法です。
認証
ディスカバリエンドポイントは、SCIM APIの残りと同じBearerトークンで保護されています。組織 → SSOから発行されたSCIMトークン — /Usersと/Groupsリクエストを処理するのと同じトークン — を使用してください。ディスカバリエンドポイントは、標準のapplication/scim+jsonコンテンツタイプで応答します。