Обработка неподдерживаемых атрибутов SCIM в запросе PATCH

Я не уверен, как мой API должен реагировать, когда он получает запрос PATCH для добавления / обновления атрибута пользователя SCIM, если модель пользователя этого не поддерживает.

Предположим, что у моей модели User нет атрибута title, но у поставщика удостоверений (Azure AD) есть для него сопоставление. Во время подготовки Azure отправляет запрос PATCH для выполнения операции добавления SCIM для установки атрибута title. Как должен реагировать мой API в этом случае?

Я просмотрел спецификацию протокола SCIM (RFC-7644) и Схема ядра SCIM (RFC-7643), но ответ мне непонятен. Есть три варианта, которые я считаю потенциально допустимыми:

  1. Игнорируйте операцию и верните ответ 200 (при условии отсутствия других проблем)
  2. Вернуть ответ 400 с scimType = "invalidPath"
  3. Вернуть ответ 400 с scimType = "noTarget"

Раздел 3.12 спецификации протокола содержит информацию об обработке ошибок, включая определения scimType. за 400 отзывов.

Описание для invalidPath гласит:

Атрибут пути недействителен или имеет неправильный формат (см. Рисунок 7).

Описание для noTarget гласит:

Указанный путь не дал атрибута или значения атрибута, с которым можно было бы работать. Это происходит, когда указанное значение пути содержит фильтр, который не дает совпадений.

noTarget кажется очень близким к правильному ответу, но второе предложение (и другие описания в спецификации) заставляют меня думать, что это только для сложных типов атрибутов. invalidPath не кажется лучшим вариантом, потому что title является допустимым атрибутом для пользователя в соответствии со спецификацией SCIM. Мое приложение этого просто не поддерживает.

Обновление (28.08.2020): я решил просто проигнорировать атрибут и вернуть 200, если с операцией нет других проблем. Служба подготовки Azure AD отправит запрос, увидит успех и проигнорирует его, пока не будет внесено изменение. Изначально я беспокоился, что Azure будет постоянно повторно отправлять операцию обновления, пока значение не появится у пользователя, но это не так.

У меня до сих пор нет ответа на то, что указано в спецификации, но это работает. Были и другие операции, при которых мне казалось, что я вернул правильную ошибку в соответствии со спецификацией, но Azure неоднократно повторно отправлял неверный запрос.


scim scim2
person TimmyTango    schedule 21.08.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Как вы справедливо заявляете, если существует (неправильно сконфигурированное) сопоставление с неизвестным атрибутом, то это нормально игнорировать его. Возврат ошибки приведет к повторным попыткам, пока подготовка не будет полностью прервана. Нет никакого принуждения, чтобы клиент дважды проверял, действительно ли запрошенное изменение проявляется в ответе. Спецификация утверждает, что 204 тоже в порядке.

Также мы могли бы быть в сценарии, где атрибут действительно существует, но на данный момент доступен только для чтения. В конце концов, из-за изменения состояния объекта он может стать доступным для записи. Возврат этого факта с трудно воспроизводимой ошибкой приведет к ненужным попыткам исправления в сопоставлении.

Думайте об этом как о конечном пользователе, который пытается проявить смекалку и изменить какое-то значение в полезной нагрузке, которое пользовательский интерфейс не предлагает возможности изменить. Просто отбрось это.

person andekande    schedule 24.09.2020