요약

  • Nancy Cam-Winget가 공동 집필한 RFC 9967은 SET으로 전달되는 SCIM 보안 이벤트를 정의한다. SET은 SCIM 서비스 공급자에서 상태 변경이 발생했음을 알리며, 이벤트 수신자는 이를 명령으로 취급하지 않고 자신만의 로컬 후속 조치를 선택한다.
  • 비동기Set-Txn값은202 Accepted응답과 이후 이벤트의txn클레임을 연결한다. 이 상관 관계, 이벤트의 지속 저장, 또는 포함된 자원 표현이 수신자가 매칭하고, 조정하고, 조치했으며 현재 동일한 상태를 보유한다는 영수증은 아니다.

비동기 신원 자동화에서 위험한 표현은 종종완료됨이다. 호출자는202 Accepted를 받고,Set-Txn헤더를 확인하고, 나중에 같은txn을 담은 SET을 발견한다. 그러면 이 일련의 과정을 하나의 안심 구절로 압축하고 싶어진다. 즉, 변경이 모든 곳에서 완료되었다는 식으로. 그러나 RFC 9967은 그렇게 말하지 않으며, 그 신중한 문구가 그 이유를 설명해 준다.

RFC 9967,System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs)은 SET을 SCIM 서비스 공급자에서 발생한 상태 변경에 대한 정보로 규정한다. 이는 가치 있는 사실이다. 모든 의존 수신자가 맹목적으로 폴링하도록 요구하는 대신, 공급자가 비동기 채널로 변경을 발행할 수 있게 해 준다. 그러나 바로 다음 문장이 중요한 경계다. 수신자는 SET을 명령으로 해석하지 않고 자신의 맥락에서 가장 적절한 로컬 후속 조치를 결정한다. RFC는 이 예시로 도메인 간 스키마 및 자원 유형 조정을 든다.

이 예시는 장식이 아니다. 공급자와 수신자는 서로 다른 자원 식별자, 데이터 모델, 수명 주기 명칭 또는 로컬 규칙을 사용할 수 있다. 수신자는 이벤트의 URI를 인식하고 내부 표현을 갱신할 수 있다. 이벤트가 가리키는 로컬 자원이 없다고 판단할 수도 있다. 합의된 공급자 기본 URI를 사용해 SCIMGET을 수행해야 할 수도 있는데, 이는 URI를 매칭할 수 없을 때 RFC 9967이 명시적으로 허용하는 옵션이다. 또는 별도의 로컬 프로세스가 평가하는 동안 복구용으로 이벤트를 보존할 수도 있다. 공급자 측 변경은 실재하지만, 그것이 자동으로 수신자 측 결과가 되는 것은 아니다.

비동기 상관 필드 역시 마찬가지로 범위가 좁다. SCIM 클라이언트가 비동기 응답을 요청하면, RFC 9967은202 Accepted, 응답 본문 없음,Set-Txn헤더를 요구한다. 그 값은 이후 SET의txn클레임과 일치해야 하며, 클라이언트는 이를 통해 대응하는 완료 이벤트를 찾을 수 있다. 이는 훌륭한 감사 조인이다. 비동기 처리를 위해 수락된 요청과 공급자의 이후 진술을 연결해 주기 때문이다. 그러나 전역 영수증은 아니다. RFC는txn과jti를 구분한다.jti는 개별 토큰을 식별하는 반면,txn은 재전송이나 복수 수신자에 대한 발행 전반에서 동일하게 유지될 수 있다. 일치하는 값은 검토자에게 무엇이 상관되었는지는 알려 주지만, 어느 수신자가 무엇을 조정했는지는 알려 주지 않는다.

이벤트 페이로드도 과잉 해석을 막는다.data와attributes중 정확히 하나만 나타날 수 있다.data는 트랜잭션 이후의 표현을 담고,attributes는 생성 또는 수정된 속성을 식별한다. 전체 표현조차 수신자의 매핑과 정책을 필요로 할 수 있다. 변경된 속성 통지 역시 조회를 필요로 할 수 있다. 어느 쪽도 수신자가 표현을 수락했다거나, 권한이 강제되었거나, 다운스트림 시스템이 이제 동의한다는 것을 선언하지 않는다. 이들은 수신자의 통제 아래 있는 별개의 관찰이다.

지속 저장 역시 중요하지만 성격이 다른 조인이다. RFC 9967은 이벤트 수신자가 확인(acknowledge)하기 전에 자신의 로컬 복구 요구를 위해 이벤트를 직접 또는 간접적으로 지속 저장하도록 요구한다. 이 규칙은 수명이 긴 이벤트 스트림을 순간적인 전달 실패와 재시도로부터 보호한다. 이는 복구 규율이지 조치 영수증이 아니다. 내구성 있는 수신함은 수신자가 이벤트를 보존했다는 사실은 정직하게 증명할 수 있지만, 매칭이 성공했거나, 사람 또는 정책 엔진이 변경을 승인했거나, 현재 로컬 자원이 공급자의 표현과 일치한다는 것은 증명하지 못한다.

이것은 축소판 Running-Code Primacy 문제다. 프로토콜 아티팩트는 자신이 노출하는 상태 전이를 정확히 그만큼만 증명하도록 허용되어야 한다. 수락된 요청, 상관 토큰, 수신된 SET, 토큰 식별자, 내구성 있는 이벤트 기록, 로컬 매칭, 콜백 결과, 정책 결정, 관찰된 수신자 상태는 모두 별개의 증거 조각이다. 이들의 라벨을동기화됨같은 대시보드 단어로 합쳐 버리면, 운영자가 나중에 검토해야 하는 바로 그 실패 면이 가려진다.

더 강한 실천은 RFC 9967을 불신하거나 단일 중앙 결정을 요구하는 것이 아니다. 결과가 실제로 발생하는 곳에 권한을 유지하는 것이다. SCIM 서비스 공급자는 자신의 변경을 보고한다. 수신자는 자신의 모델 안에서 그 정보를 해석하고 사용하는 방식을 결정한다. 결과를 감수하는 조직은 자동화 워크플로가 외부 효과를 갖기 전에 무엇을 조정해야 하는지 정의한다. 그 결과 기록은 경로의 어느 부분이 발생했고 어느 부분이 여전히 알려지지 않았는지를 정확히 말할 수 있다.

출처