Melhores Práticas para a Gestão de Utilizadores

Princípios recomendados

• Facilitar a compreensão, mostrando junto nas listagens as coisas que estão relacionadas entre si.
• Facilitar a pesquisa, minimizando o recurso a astericos - *.
• Abstrair de forma útil os detalhes dos outros níveis, de forma a que cada nível de relação seja compreensível por si só.

Grupos

1. O nome dos grupos deve ser separado por espaços.

2. O nome dos grupos deve ser hierarquizado, de forma a coisas relacionadas serem ordenadas por proximidade.

   Isto é, deve-se preferir FUNC STI e FUNC STI Admin em vez de FUNC STI e FUNC Admin STI.

3. Os grupos são caracterizados pelos prefixos FUNC e ORG:

   • FUNC: utilizados para atribuir perfis capazes de garantir o acesso a recursos.
   • ORG: servem apenas para classificar as pessoas dentro da organização. Não atribuem perfis.

Perfis

Numa fase inicial da plataforma da CoB, existia a tendência de agrupar num único perfil muitas permissões. Contudo, com o passar do tempo, começou-se a criar perfis mais pequenos. Apesar da inevitável proliferação de perfis, estes últimos passaram a ser mais facilmente compreendidos e combinados em diferentes grupos.

A tentativa é que seja possível, ao consultar um grupo, perceber o que é que os seus perfis lhe permitem, sem ser necessário consultar os detalhes das permissões. Eis em seguida alguns conselhos para a criação de perfis:

1. O nome dos perfis deve ser separado por hífens (-), no caso de querermos separar secções, ou espaços para tudo o resto.

2. O nome dos perfis deve ser hierarquizado, de acordo com o formato <produto> - <tema> - <capacidade>.

   A secção produto é necessária para perceber a listagem de perfis de um Grupo.

   Exemplos de temas:

   • Nome da definições do RecordM
   • modules para UI
   • action e script para o IntegrationM.
   • equips para o DeviceM.

3. Os perfis devem representar a capacidade de fazer coisas em termos dos produtos, não em termos de negócio.

   Exemplo: rm - Ausências - read está correcto, rm-gp-admin não!

Permissões

No caso das permissões, a sua principal diferença é que o nome segue o esquema do framework de segurança Apache Shiro e portanto aqui manipulamos a descrição.

Na prática, a experiência diz-nos que a descrição é bastante importante nas permissões do RecordM - módulo da CoB para gestão de informação - relacionadas com as definições porque os IDs das definições não têm como destinatários seres humanos. Mas os outros casos de permissões são relativamente explícitos. Só falham por não permitirem uma ordenação por tópicos (capaz de agrupar por temas semelhantes).

1. A descrição das permissões deve ser separada por hífens (-), no caso de querermos separar secções, ou espaços para tudo o resto.

2. A descrição das permissões deve ser hierarquizada, de acordo com o formato <tema> - <capacidade>

   Exemplos de temas:

   • Nome da definições do RecordM.
   • modules para UI
   • action e script para o IntegrationM.
   • equips para o DeviceM.

3. Devem ser evitadas permissões compostas.

   Apesar de parecerem poupar trabalho, na verdade são mais difíceis de compor.

   Exemplo: definitions,instances:*:54,55 não permite o reaproveitamento da expressão se quisermos separar a leitura da edição de dados. E o facto de na listagem aparecerem juntas todas as permissões referentes a uma definição acaba por dificultar o trabalho. Isto porque não é possível escrever uma descrição que ordene esta definição perante duas outras definições que possa afectar.