Как я могу выразить контроль доступа через сервис в стиле REST? - PullRequest
Новая
       14

Как я могу выразить контроль доступа через сервис в стиле REST?

1 голос
/ 28 марта 2012

Я пытаюсь создать семейство сервисов в стиле REST, которые будут использоваться различными внутренними системами.Службы поддерживают внутреннюю систему контроля доступа, которая определяет, есть ли у пользователя доступ для выполнения действий с конкретными ресурсами.

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

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

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

РЕДАКТИРОВАТЬ:

Я думал о добавлении «поддерживаемых действий» к ссылкам в моих ресурсах: 

<contact>
    <addresses href="/contact/12345/addresses" actions="GET" />
</contact>

Если у вызывающей стороны нет доступа к ресурсу, ссылка не будет в документе.

Это заставляет меня четко указывать действия, доступные на каждом ресурсе, и что клиенты должны читатьэта информация содержится в каждой ссылке, которую я предоставляю, и это не облегчает обработку запросов PUT (поскольку вы будете указывать URL-адрес, с которым хотите работать).

Это кажется разумным?Есть ли лучшее соглашение для достижения этого?

РЕДАКТИРОВАТЬ:

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

Для создания новых ресурсов с помощью запросов PUT это было немного сложнее, так как ресурсы еще не существуют для описания через URL.В этих случаях я решил использовать «дочернюю» ссылку, которая описывает механизм «добавления»: 

<contact>
    <addresses href="/contact/12345/addresses" actions="GET">
        <add href="/contact/12345/addresses/[name]" actions="PUT"/>
    </addresses>
</contact>

Это немного близко к описанию интерфейса в стиле RPC, но этоописывает действие (чтобы добавить новый ресурс как дочерний элемент адреса), и его отсутствие в документе (в первом примере) будет использоваться для указания того, что у вас нет доступа к ресурсу.

Кроме того, я попытаюсь поддержать ОПЦИИ, чтобы клиенты могли проверять ресурс за ресурсом, если они в этом нуждаются.

1 Ответ

1 голос
/ 28 марта 2012

Мне не известны какие-либо соглашения REST для запроса ролей.

Я бы лично внедрил систему, в которой я бы выполнил (скажем) /users/johndoe/roles и получил бы список доступных ролей.

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

РЕДАКТИРОВАТЬ: Исходя из вашей дополнительной информации, вы можете посмотреть метод HTTP OPTIONS (если ваши клиенты могут его поддерживать.) Если вы уже обрабатывали аутентификацию через HTTP и вы хотите знать, какие из методов HTTP (GET, POST и т. д.) вы можете выполнить с данным ресурсом, OPTIONS можно использовать для передачи этой информации клиентам. Например: 

OPTIONS /resource HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 28 Mar 2012 14:44:47 GMT
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Connection: close
...