Как представить управление доступом на уровне атрибутов RESTful? - PullRequest
Новая
       35

Как представить управление доступом на уровне атрибутов RESTful?

12 голосов
/ 22 декабря 2011

Я ломал голову и целую вечность гуглял, не придумав удовлетворительного способа справиться с этим.Я хочу написать хороший полностью RESTful-сервис для возврата ресурсов, но данные, которые у вас есть разрешение на чтение (или запись), различаются для каждого ресурса в зависимости от вашей роли.Так, например, пользователь может видеть свой личный номер телефона в своем профиле, как и администратор сайта, но другой пользователь этого не сделает.Анонимный посетитель может не увидеть реальное имя другого пользователя, но это могут сделать другие пользователи (и администратор сайта).Существует около 4 или 5 уровней доступа и правил, относительно которых атрибуты могут быть прочитаны или записаны.Письмо, которым я доволен, поскольку клиент может PUT-изменения, и сервер не обязан принимать их все (или вообще), но чтение - моя проблема. 

<user>
 <id>jimbob</id>
 <real-name>Jim Roberts</real-name> <!-- only logged-in users should see this -->
 <phone-number>+1 42424151</phone-number> <!-- only the user and admin users should see this -->
</user>

Я хочу получитьправильно кэшируемый ресурс профиля пользователя, который содержит все общедоступные данные, но как мне смоделировать все то, что могут видеть только определенные пользователи?Я мог получить до 4 ссылок на дополнительную информацию, большинство из которых возвращало бы несанкционированные ошибки для большинства пользователей, причем каждая ссылка содержала дополнительную информацию, связанную с ролью.Но это кажется очень неэффективным и также связывает клиентов с концепцией ролей, когда раньше все, что им нужно было знать, это пользователи.Есть какие-нибудь лучшие идеи? 

<user>
 <id>...</id>
 <link rel="more" href="extra-user-profile-data-for-logged-in-users"/>
 <link rel="more" href="extra-user-profile-data-for-senior-users"/>
 <link rel="more" href="extra-user-profile-data-for-admin-users"/>
 <link rel="more" href="extra-user-profile-data-for-superadmin-users"/>
</user>

Обратите внимание - я не борюсь ни с одной из

  • Аутентификация
  • Контроль доступа на уровне ресурсов
  • Реализация контроля доступа или авторизации на стороне сервера

Я борюсь с

  • Как представить ресурсы, которые на «нормальном» веб-сайте HTML выглядят по-разному для разныхлюди, по-настоящему НАСТОЯЩИМ.

Кажется, это действительно распространенная проблема, которая должна возникнуть у всех, но я ничего не могу найти по этому поводу!Пожалуйста, помогите!

1 Ответ

8 голосов
/ 23 декабря 2011

Если подумать, ресурс User, который видит клиент администратора (со всеми видимыми полями), точно такой же ресурс , который видит анонимный или менее привилегированный клиент.URI идентичен, но представление , которое они видят, отличается.

Это похоже на то, что клиентский запрос должен быть закодирован в JSON вместо XML через заголовок Accept: сервер может согласиться удовлетворить этот запрос, но это не обязательно.В вашем случае сервер должен вернуть представление, соответствующее предоставленным учетным данным клиента.

Следовательно, администратор может получить контент в типе носителя application/vnd.yourcompany.user.full+xml в качестве тела, возвращаемого GET на вашем Userресурс, и он будет содержать все возможные поля.

Однако анонимный пользователь может получить полезную нагрузку, закодированную как, скажем, application/vnd.yourcompany.user.limited+xml, которую ваша документация будет четко описывать как представление, которое может содержать или не содержать все элементы версии full.Клиенту пришлось бы использовать гибкий декодер или схему, которые допускали бы отсутствие определенных элементов вообще.

Кроме того, вы можете вернуть всю информацию о ресурсе, но использовать значение специального поля, чтобы указать, что конкретное значение было отредактировано: 

<user>
 <id>jimbob</id>
 <real-name>--FORBIDDEN--</real-name> 
</user>

Можно создать тип носителя для каждой роли, ноэто привело бы к сильной связи между вашей схемой безопасности и вашими представлениями, и это, вероятно, нежелательно.Гибкие схемы представления, в которых используются пропуски полей или редактирование значений, будут более удобными для поддержки в долгосрочной перспективе.

Окончательное решение, которое необходимо принять, заключается в том, следует ли возвращать ссылки на другие ресурсы, которые не будут доступны для навигации на основе учетных данныхклиент поставляется.По моему мнению, эти ссылки должны всегда возвращаться, даже если эти учетные данные не будут работать.Зачем?Потому что клиент может теоретически предоставить другие учетные данные при вызове этих URI.Даже если они этого не сделают, итоговая проблема 401 может привести к тому, что клиент в итоге предоставит их.Но если они никогда не получат URI, им будет запрещено принимать это решение.

...