SCIM Discovery 엔드포인트
SCIM 2.0은 신원 공급자가 모든 작업을 수동으로 시도하지 않고도 SCIM 서버가 무엇을 지원하는지 알 수 있도록 하는 세 가지 디스커버리 엔드포인트를 정의합니다. SecureCodingHub는 세 가지 모두를 제공합니다. 대부분의 IdP는 초기 연결 테스트 중에 자동으로 호출합니다.
세 가지 엔드포인트
세 가지 모두 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의 연결 테스트가 실패하고 오류가 세 가지 디스커버리 엔드포인트 중 하나를 참조합니다 — 실제 응답을 보는 것이 종종 공급업체 문서를 읽는 것보다 잘못된 구성을 더 빠르게 표시합니다.
- 감사관이 테넌트가 광고하는 SCIM 기능의 문서를 요청합니다. 세 가지 엔드포인트가 함께 그 문서를 형성하며 모든 요청에서 새로 고쳐집니다.
응답이 알려주는 것
ServiceProviderConfig가 세 가지 중 일상적으로 가장 유용합니다. 필터 작업이 지원되지만 eq 연산자로 제한된다는 것, PATCH가 지원된다는 것, bulk 작업이 지원되지 않는다는 것, password-change 엔드포인트가 구현되지 않았다는 것, 그리고 SCIM 측 문서가 어디에 있는지(이 사이트)를 IdP에 알려줍니다. 대부분의 SCIM 버그는 IdP가 하기를 기대하는 것과 SP가 할 수 있다고 말하는 것 사이의 불일치입니다. 구성 응답을 읽는 것이 어느 쪽이 잘못되었는지 확인하는 가장 빠른 방법입니다.
인증
디스커버리 엔드포인트는 SCIM API의 나머지와 동일한 Bearer 토큰으로 보호됩니다. 조직 → SSO에서 발급된 SCIM 토큰을 사용하세요 — /Users 및 /Groups 요청을 처리하는 동일한 토큰입니다. 디스커버리 엔드포인트는 표준 application/scim+json 콘텐츠 유형으로 응답합니다.