Acesso baseado em função a recursos para um serviço RESTful

Question

Acesso baseado em função a recursos para um serviço RESTful

#1 resposta do (5 votos)

5

Ainda estou pensando no REST, mas gostaria de saber se alguém pode ajudar com sugestões ou abordagens para o controle de acesso baseado em função de um serviço RESTful, especialmente do ponto de vista de proteger os dados e como os URLs podem Veja. Provavelmente, é melhor considerar um exemplo:

Digamos que eu tenha um serviço REST para os clientes e queira dividir os usuários desse serviço REST nas funções de administrador, editor e leitor:

Os administradores podem alterar todos os atributos de um recurso do cliente
Editores podem alterar apenas alguns
Os leitores só podem visualizá-los.

Os direitos de controle de acesso são atribuídos às entidades Clientes individualmente. Assim, por exemplo, um usuário do serviço pode ter direitos de administrador para os clientes 1,2 e 3, mas o acesso do Editor para 4,5 e o acesso do Leitor para 7,8,9.

Agora considere o usuário que está chamando o serviço. O que é uma boa maneira de separar a lista de clientes do usuário atual?

GET / Customer - isso pode gerar uma lista de todos os clientes aos quais o usuário atual tem acesso Admin \ Editor \ Reader. Mas, em seguida, em cada cliente, o consumidor precisaria de uma indicação do papel que eles têm.

Ou seria "melhor" ter algo como

GET / Customer / Admin - retorna todos os clientes aos quais o usuário atual tem acesso de administrador.

Apenas procurando por alguns indicadores de alto nível ou lendo de maneira decente para proteger \ filtrar os recursos com base nas funções do usuário atual.

architecture rest web-services

por mutex 23.10.2013 / 06:19

fonte

1 resposta

Tags architecture rest web-services

Desenvolvendo uma solução melhor, vindo da base de código existente [duplicata] Por que a função max construída do Haskell é mais rápida do que a minha?

score 5 · Accepted Answer

Um método que usei com grande sucesso para expor o nível de acesso ou as funções que o usuário autenticado possui em relação a um recurso específico é expô-lo como verbos HTTP na própria entidade.

Por exemplo, solicitando uma lista de todos os clientes:

GET /customers
{
   customers: [
     {
        id: "/customers/1"
        allowed: ["GET", "UPDATE", "PUT", "DELETE"]
     },
     {
        id: "/customers/2"
        allowed: ["GET"]
     }
   ]
}

O acesso de leitura indicado por GET UPDATE, PUT, DELETE indicaria o acesso Editor e / ou Administrador com base na semântica da sua API. Se esse tipo de abstração não funcionar no seu caso, você poderá fazer o lançamento diretamente.

Além disso, você pode fornecer um filtro para a solicitação do cliente

GET /customers?role=admin

Retornaria apenas os clientes para os quais o usuário autenticado tem a função "admin".