Welcome to the Cookbook

loading...

5.1.1 Entendendo como ACL trabalha

Poderosas coisas requerem controle de acesso. Lista de controle de acesso são uma forma de gerenciar as permissões da aplicação com alta granularidade, ainda de fácil manutenção e sustentável.

Lista de Controle de Acesso ou ACL (Access Control List), lida com dois conceitos principais: coisas que querem coisas inúteis, e coisas que são desejadas. No ACL, coisas (na maioria das vezes usuários) que pretendem usar coisas são chamados acesso de requisição de objetos ou AROs. Coisas no sistema que são desejadas (na maioria das vezes ações ou dados) são chamados de Controle de Acesso de Objetos ou ACOs. As entidades são chamados 'objetos' porque algumas vezes a requisição de objetos não é uma pessoa - as vezes você pode quer limitar o acesso a certos controladores do Cake tem que iniciar a lógica em outras partes da sua aplicação. ACOs pode ser qualquer coisa que você queira controlar, de uma action de uma controladora, até um web service, para uma linha em seu blog grandma's.

Revisando:

  • ACO - Controle de acesso de objetos - Qualquer coisa que é necessária
  • ARO - Requisição de acesso a objetos - Qualquer coisa que necessita de algo

Essencialmente, ACL é o que é usado para decidir quando um ARO quer ter acesso a um ACO.

A fim de ajuda-lo aentender como tudo funciona em conjunto, vamos usar um exemplo prático. Imagine, por um momento, um sistema de computador usado por um grupo familiar de aventureiros do Senhor dos Anéis Rings. O líder do grupo, Gandalf, quer gerenciar os bens do grupo enquando mantém uma boa quantidade de privacidade e segurança para os outros membros do grupo. A primeira coisa ele precisa criar uma lista de AROs envolvidos:

  • Gandalf
  • Aragorn
  • Bilbo
  • Frodo
  • Gollum
  • Legolas
  • Gimli
  • Pippin
  • Merry

Perceba que o ACL não é a mesma coisa que autenticação. ACL é o que acontece depois que um usuário está autenticado. Embora os dois são geralmente usados em conjunto, ele é importante para realizar a diferença entre saber quem é (autenticação) e saber o que ele fez (ACL).

A próxima coisa que Gandalf precisa fazer é uma lista inicial de coisas, ou ACOs, o sistema irá tratar. Essa lista pode ser algo como:

  • Weapons
  • The One Ring
  • Salted Pork
  • Diplomacy
  • Ale

Tradicionalmente, sistemas eram gerenciados usando uma matriz, que mostrava basicamente os usuários e permissões relacionado a objetos. Se essa informação estava armazenada numa tabela, que poderia parecer com a seguinte tabela:

Weapons The Ring Salted Pork Diplomacy Ale
Gandalf Allow Allow Allow
Aragorn Allow Allow Allow Allow
Bilbo Allow
Frodo Allow Allow
Gollum Allow
Legolas Allow Allow Allow Allow
Gimli Allow Allow
Pippin Allow Allow
Merry Allow

A primeira vista, parece que esse tipo de sistema poderia funcionar bem. Atribuições podem ser feitas para proteger a segurança (apenas Frodo pode ter acesso ao anel) e proteger contra acidentes. Parece de granularidade suficiente, e mesmo assim fácil de ler, certo?

Para um sistema pequeno como esse, talvez uma matriz iria trabalhar. Mas com o crescimento do sistema, ou o sistema com uma grande quantidade de recursos (ACOs) e usuários (AROs), uma tabela pode se tornar pesada rapidamente. Imagine tentando controlar o acesso de centenas de acampamentos de guerra e tentando gerenciá-los por unidade. Outro inconveniente de matrizes é que você não pode agrupar logicamente por grupo de usuários ou fazer permissão em cascata mudando para grupos de usuários baseados nesses agrupamentos lógicos. Por exemplo, seria bom permitir automaticamente aos hobbits acesso para o ale e pork uma vez que a batalha acabou. Fazendo isso um usuário indivualmente, seria tediosa e propensa a erros. Fazendo permissão em cascata mudando para todos 'hobbits' seria mais fácil.

ACL é geralmente implementado numa estrutura de árvore. Existe geralmente uma árvore de AROs e uma árvore de ACOs. Para organizar seus objetos em árvores, permissões podem ser tratadas de forma granulada. Como líder, Gandalf elege ACL para usar no seu novo sistema, e organiza seus objetos como nas seguintes linhas:

  • Fellowship of the Ring™
    • Warriors
      • Aragorn
      • Legolas
      • Gimli
    • Wizards
      • Gandalf
    • Hobbits
      • Frodo
      • Bilbo
      • Merry
      • Pippin
    • Visitors
      • Gollum

Usando uma estrutura de árvore ARO permite Gandalf definir permissões que são aplicadas para entrada de grupos de usuários de uma só vez. Então, usando sua árvore ARO, Gandalf pode mudar um pouco as permissões baseado em grupo:

  • Fellowship of the Ring
    (Deny: all)
    • Warriors
      (Allow: Weapons, Ale, Elven Rations, Salted Pork)
      • Aragorn
      • Legolas
      • Gimli
    • Wizards
      (Allow: Salted Pork, Diplomacy, Ale)
      • Gandalf
    • Hobbits
      (Allow: Ale)
      • Frodo
      • Bilbo
      • Merry
      • Pippin
    • Visitors
      (Allow: Salted Pork)
      • Gollum

Se nós queremos usar o ACL para ver se o Pippin tinha permissão para acessar a cerveja, nós primeiro temos que obter o caminho na árvore, que é Fellowship->Hobbits->Pippin. Então nós vemos diferentes permissões que se encontram presente em cada um desses pontos, e usa a mais específica permissão relacionada com Pippin e Cerveja.

ARO Node Permission Info Result
Fellowship of the Ring Deny all Denying access to ale.
Hobbits Allow 'ale' Allowing access to ale!
Pippin -- Still allowing ale!

Desde que o nó 'Pippin' na árvore ACL não especifica permissão negada para a cerveja ACO, o resultado final é que nós permitimos acesso para aquele ACO.

A mesma árvore nos permite fazer finos ajustes para um controle mais granular - embora ainda mantendo a habilidade de fazer grandes mudanças para os grupos AROs:

  • Fellowship of the Ring
    (Deny: all)
    • Warriors
      (Allow: Weapons, Ale, Elven Rations, Salted Pork)
      • Aragorn
        (Allow: Diplomacy)
      • Legolas
      • Gimli
    • Wizards
      (Allow: Salted Pork, Diplomacy, Ale)
      • Gandalf
    • Hobbits
      (Allow: Ale)
      • Frodo
        (Allow: Ring)
      • Bilbo
      • Merry
        (Deny: Ale)
      • Pippin
        (Allow: Diplomacy)
    • Visitors
      (Allow: Salted Pork)
      • Gollum

Esta abordagem permite-nos tanto a capacidade de fazer alterações de grande alcance nas permissões, mas também ajustes finos. Isso permite-nos dizer que todos os hobbits podem ter acesso a cerveja, com uma exceção; Merry. Para ver se Merry pode acessar a cerveja, nós temos que procurar seu caminho na árvore: Fellowship->Hobbits->Merry e trabalhar nosso caminho, e manter o rasto de permissões relacionadas a cerveja:

ARO Node Permission Info Result
Fellowship of the Ring Deny all Denying access to ale.
Hobbits Allow 'ale' Allowing access to ale!
Merry Deny 'ale' Denying ale.