Uso e Criação de Grupos no Lumis Portal

Objetivos

Compreender o processo para a decisão da estrutura de grupos necessária para o Portal, bem como os aspectos que podem influenciar nessa decisão.
Aprender a utilizar as interfaces administrativas de grupos globais e locais para a criação e definição da hierarquia de grupos.
Entender as particularidades dos grupos padrão do Lumis Portal.

Referências complementares

Grupos de usuários no Lumis Portal
Grupos dinâmicos
Grupos globais e grupos locais
Controle de acesso
Permissões

Definição da estrutura de grupos do Portal

Um dos pontos a se considerar sempre durante a arquitetura de um Portal é a definição da hierarquia de grupos a se utilizar. É fundamental que essa estrutura seja definida com uma granularidade adequada, coerente com a natureza do acesso ao Portal, de modo que fique clara e permita todas as variações de acesso que sejam necessárias. Uma boa estruturação nesse sentido pode facilitar muito a manutenção e o dia a dia de utilização do Portal.

Vantagens da utilização de grupos na definição do controle de acesso

Embora o Lumis Portal permita que todo controle de acesso, em todos os seus níveis, seja definido para grupos e/ou usuários, é altamente recomendável que utilizemos apenas grupos nesse tipo de configuração, fora raríssimas exceções.

A vantagem de utilizarmos apenas grupos é, basicamente, a possibilidade de reaproveitamento da configuração realizada. Quando utilizamos um usuário na definição de controle de acesso, se precisarmos incluir outro usuário que possua o mesmo conjunto de permissões precisaremos realizar a configuração novamente para esse novo usuário, aumentando o esforço necessário e as chances de erro. Se utilizamos grupos, bastaria incluir esse novo usuário nos mesmos grupos a que pertence o primeiro usuário.

Mesmo que o conjunto de permissões não seja rigorosamente igual, o mecanismo de atribuir e negar permissões no controle de acesso permite que, ao colocar um usuário em um grupo nós estejamos apenas removendo algumas permissões deste. Dessa forma, se estivermos em um cenário que possua uma arquitetura de grupos bem definida, fica fácil atribuir a um novo usuário um controle de acesso “parecido” com o controle definido para outros usuários previamente existente. Mesmo nesses casos é sempre recomendável que a restrição seja feita através de grupos e não especificamente sobre o usuário, de modo que, caso o cenário ocorra novamente para outro usuário, nós possamos reaproveitar a configuração já realizada.

Consideremos o seguinte cenário. Temos um Portal com cinco áreas distintas. Até o momento foram identificados dois tipos de perfis de usuários, aqueles que têm acesso às áreas 1, 2 e 3, e aqueles que têm acesso às áreas 3, 4 e 5. Assim foram criados dois grupos, A e B, para representar esses perfis:

Grupo A = Permite acesso às áreas 1, 2 e 3.

Grupo B = Permite acesso às áreas 3, 4 e 5.

Em um segundo momento surge a necessidade de que um usuário específico tenha acesso apenas às áreas 1 e 2. Uma solução tecnicamente possível seria colocar esse usuário no grupo A e simplesmente negar acesso explicitamente a ele na área 3.

O mais aconselhável, no entanto, seria criar um terceiro grupo C, que apenas negasse o acesso à área 3.

Grupo C = Nega o acesso à área 3.

Assim, lembrando que uma permissão negada se sobressai a uma permissão atribuída caso um usuário possua as duas, basta que esse usuário pertença aos grupos A e C que ele possuirá acesso apenas às áreas 1 e 2.

Dessa forma, caso em algum momento surja um novo usuário que deva possuir acesso às áreas 1 e 2 basta colocá-lo também nos grupos A e C. Além disso, caso em algum momento tenhamos também a necessidade de que um usuário tenha acesso apenas às áreas 4 e 5, podemos colocá-lo nos grupos B e C que teremos o resultado esperado.

Ainda que uma determinada situação se mostre absolutamente improvável de se repetir, argumento que poderia ser utilizado para que a definição de controle de acesso seja realizada pontualmente sobre um usuário específico, o cenário acima nos mostra que continua sendo interessante realizar a configuração sempre utilizando grupos.

Como o esforço para realizarmos a configuração de controle de acesso com usuários e grupos é o mesmo e o trabalho para atribuir um usuário como membro de um determinado conjunto de grupos é pequeno, a recomendação de utilizarmos sempre grupos no controle de acesso é válida para quase todos os cenários.

Repare que existem diversas formas diferentes de estruturarmos os grupos existentes para chegarmos ao resultado esperado acima. Na prática não existe uma regra geral que possamos utilizar para a modelagem dos grupos de um Portal. O mais importante é que os grupos definidos façam sentido conceitualmente, de modo que sua utilização seja clara. A seguir vemos algumas variações de cenários que ilustram diferentes estratégias para essa modelagem.

A definição da granularidade ideal para a arquitetura de grupos

No exemplo acima, temos um Portal com cinco áreas em que precisamos criar três grupos para representar todas as variações de perfil necessárias. Dependendo dessa necessidade, a estratégia poderia ter sido diferente.

Se considerarmos todas as possibilidades de combinações que podemos realizar com as cinco áreas acima, cada combinação definindo um perfil, vemos que poderíamos chegar a um cenário em que seriam necessários até trinta e um grupos.

Em um cenário assim, em que houvesse a necessidade de atribuir cada uma dessas combinações a diferentes usuários, provavelmente faria muito mais sentido simplesmente criarmos cinco grupos, cada um definindo o acesso a uma única área e, para cada usuário, colocá-lo como membro de um ou mais desses cinco grupos, aumentando a clareza e facilitando a manutenção do ambiente.

O que indicará, portanto, a granularidade ideal para a hierarquia de grupos é a necessidade de diversificação de perfis. Independente do tamanho do Portal, se verificarmos que os conjuntos de permissões necessárias para os usuários existentes respeitam padrões bem definidos, provavelmente fará sentido utilizarmos um grupo para representar cada um desses padrões, definindo perfis, de modo que cada usuário pertença a poucos grupos ou mesmo a um único grupo. Certamente sempre haverá exceções, mas que podem ser resolvidas sem fugir conceitualmente da estratégia definida, como mostramos no exemplo acima de restrição a uma área.

Um cenário em que normalmente essa abordagem faria sentido é o de um Portal de Intranet de uma empresa. Como é voltado para os funcionários, nesse tipo de cenário é mais fácil identificar perfis comuns. Normalmente usuários de cargos ou posições iguais possuirão acesso às mesmas áreas. Assim provavelmente se utilizarmos grupos para representar esses perfis, sendo que cada grupo possui acesso a diversas áreas diferentes, estaremos melhorando a legibilidade e facilitando a manutenção para os casos de necessidade de inclusão de novos usuários ou de alteração no cargo do funcionário na empresa.

No entanto, se percebermos que os conjuntos de permissões não respeitam padrões e que potencialmente teremos um número muito grande de combinações diferentes necessárias (ou mesmo que todas as combinações podem existir), o ideal talvez seja aumentar a granularidade ao máximo, criando um grupo para cada área e atribuindo diversos grupos a cada usuário, um para cada área que ele possuir acesso. Nesse caso os grupos não representam perfis e sim acesso a áreas pontuais. O perfil de um usuário nesse caso é representado pelo conjunto de grupos aos quais ele pertence.

Um cenário em que seja possível para um usuário, por exemplo, delegar permissões a outros usuários com base nas permissões que ele possui, é um exemplo em que provavelmente essa segunda abordagem é mais adequada, permitindo controle total sobre as possibilidades de controle de acesso, sendo possível gerar todas as combinações existentes.

Outro tipo de cenário em que esse tipo de estratégia pode ser interessante é em cenários em que as configurações de acesso dos usuários sejam definidas por um elemento autorizador externo ao Portal, sobre o qual não se possui controle. Nessa situação pode ser interessante prever que qualquer combinação de acesso pode ser necessária a qualquer momento. A segunda abordagem permite essa flexibilidade e, portanto, é a ideal nesse caso.

Mais uma vez, o mais importante é que os grupos definidos na arquitetura façam sentido. Ser capaz de explicar conceitualmente o que o grupo faz é uma boa forma de validar se a arquitetura está bem definida. Se precisarmos explicar a existência de um grupo dizendo simplesmente que ele é o grupo que dá acesso às áreas 2, 5 e 17, provavelmente a arquitetura precisa ser revista ou podem surgir problemas no futuro durante a manutenção do Portal.

Grupos padrão do Lumis Portal

O Lumis Portal possui alguns grupos padrão que podem ser utilizados para compor a definição da arquitetura de grupos e controle de acesso de um ambiente. Os grupos padrão não podem ser modificados ou excluídos e possuem algumas particularidades. São eles:

Administradores do Portal = Grupo que, por default, possui todas as permissões de acesso ao Portal. Embora essas permissões possam ser removidas desse grupo, todo elemento que possui controle de acesso (canais, páginas, instâncias de serviço, etc) precisa sempre ter ao menos um grupo ou usuário que possua permissão para controle total sobre o objeto (Gerenciar segurança), de modo que essas permissões não podem ser removidas do grupo Administradores do Portal sem serem atribuídas a outro grupo.
Usuários cadastrados = Grupo que contém todos os usuários do Portal, exceto o usuário guest. Todo usuário criado é automaticamente definido como membro do grupo “Usuários cadastrados”, atribuição que não pode ser removida. Esse grupo é útil quando se deseja atribuir uma determinada permissão apenas para os usuários que estão autenticados.
Todos os usuários = Grupo que contém todos os usuários do Portal. Pode ser visto como a união do grupo Usuários cadastrados com o usuário guest. Útil quando se deseja atribuir uma permissão a todos usuários de fato, independente de estarem autenticados ou não.
Publicadores = Grupo conceitualmente definido para conter os usuários com permissão de publicação de conteúdo no Portal. Apenas os usuários que fazem parte desse grupo podem realizar preview de conteúdo utilizando o mecanismo de preview padrão do Portal.
Desenvolvedores = Grupo conceitualmente definido para conter os usuários com permissão de desenvolvimento para o Portal. No entanto, trata-se apenas de uma abstração conceitual, não possuindo nenhuma particularidade que o diferencie de um grupo comum.

Utilizando tipos de grupos customizados na arquitetura

O Lumis Portal permite que sejam criados tipos de grupos, representados por uma classe customizada que saiba calcular os seus membros. Além disso, a implementação dessa classe permite parametrização, de modo que utilizando uma mesma classe é possível definir vários tipos de grupos diferentes. O tipo de grupo é selecionado no momento da criação de um grupo.

A utilização de tipos de grupos customizados é especialmente útil quando precisamos definir o controle de acesso de um elemento do Portal a um conjunto de usuários que obedeça a algum critério que possa ser calculado programaticamente com o objetivo de reduzir o custo de manutenção da atribuição de usuários a grupos tradicionais manualmente.

Por exemplo, se existe a necessidade de permitir o acesso a uma área a todos os usuários cujo nome comece com a letra “A”. Uma solução seria simplesmente criarmos um grupo que representasse esse conjunto de usuários e atribuirmos todos os usuários cujo nome se inicie com a letra “A” manualmente no grupo. Mas a partir daí todo usuário criado no Portal precisaria ser avaliado para também ser atribuído manualmente a esse grupo caso atendesse ao critério.

Utilizando um tipo de grupo customizado é possível criar uma classe que automaticamente selecione todos os usuários que atendam a esse critério e os definam como membros do grupo. Assim, caso um usuário novo seja criado com o nome começando com “A”, ele automaticamente fará parte desse grupo.

Outro exemplo seria caso fosse necessário que os membros de um determinado grupo, utilizado para definir acesso a alguma área do Portal, fossem determinados pelo conteúdo de um arquivo físico, atualizado periodicamente no servidor por um elemento autorizador externo. Nesse caso bastaria que a classe sempre lesse esse arquivo e a partir dele definisse os seus membros.

A criação de tipos de grupos customizados é realizada no Gerenciador de Tipos de Grupos, existente no menu Módulos -> Usuários e Grupos. A interface está representada abaixo:

Caso a classe que define esse tipo de grupo permita parametrização, na interface acima será exibido um ícone ao lado do ID do grupo para acessar a interface que permite que seja realizada essa parametrização.

Por padrão ela possui apenas o tipo de grupo padrão. Para adicionar novos tipos deve ser usado o botão Adicionar, que chama a interface abaixo:

Essa interface possui os seguintes campos:

ID = Identificador único para o tipo de grupo.
Nome = Nome que será exibido na interface de criação e atualização de grupos, para seleção do tipo de grupo que se deseja criar ou atualizar.
Descrição = Campo opcional para melhor definir o objetivo do Tipo de Grupo.
Group Membership Provider = Nome da classe que realizará o cálculo dos membros do tipo de grupo criado.

O mecanismo nativo de grupos dinâmicos existente no Lumis Portal é uma implementação de tipo de grupo customizado que já permite que seja feita essa seleção baseada em diversos critérios, parametrizáveis no momento da criação do tipo de grupo.

Durante a definição da estrutura de grupos de um Portal recomenda-se sempre a avaliação para identificar se alguma configuração de controle de acesso respeita uma regra que possa ser definida dessa forma, situação no qual a utilização de grupos dinâmicos ou de outras implementações de tipos de grupos customizados pode ser bastante útil. Em especial em cenários nos quais a criação e alteração de usuários sejam muito dinâmicas, onde esse tipo de recurso pode reduzir drasticamente o custo de manutenção da estrutura de acesso do Portal.

Administração de grupos no Portal

Toda administração de grupos do Portal pode ser realizada no Gerenciador de Grupos, presente no menu Módulos -> Usuários e Grupos. A interface de gerenciamento está ilustrada abaixo:

Nessa interface vemos os grupos padrão do Lumis Portal citados acima além de todos os demais grupos criados, sejam eles globais ou locais. Os grupos locais podem ser identificados por possuírem em seu apelido o prefixo que identifica o canal ao qual pertencem. No exemplo acima, além dos grupos padrão, vemos dois grupos globais “Grupo A” e “Grupo B” e um grupo local cujo apelido é “AP.administradores”, pertencente a um canal cujo prefixo definido é “AP”.

Mesmo os grupos locais podem ser alterados ou excluídos a partir dessa interface global, exceto pelo prefixo no apelido, que não pode ser alterado. No entanto a criação de grupos locais só pode ser realizada no canal em questão.

Nessa interface é possível adicionar novos grupos, editar ou excluir grupos existentes, controlar o acesso aos grupos e definir membros.

O botão Adicionar permite a criação de novos grupos globais, utilizando a interface abaixo:

Os campos que definem um grupo são:

Apelido = É o identificador do grupo para o Lumis Portal, e deve ser único para todo o Portal.
Nome = Nome completo do grupo. É o campo utilizado para identificar o grupo nas interfaces para o usuário final.
Descrição = Uma descrição opcional para melhor definir o objetivo do grupo.
Tipo de Grupo = Nesse campo pode ser selecionado um tipo de grupo customizado ou, para grupos tradicionais, o tipo “Tipo de Grupo Padrão”.

Na edição de grupos todos os campos podem ser modificados, exceto o tipo do grupo, como vemos abaixo:

O botão Controlar Acesso chama a interface que permite configurar o controle de acesso sobre esse grupo, exibida abaixo:

Repare que o controle de acesso sobre um grupo significa definir quais usuários ou grupos tem acesso para realizar modificações no grupo em questão. Um erro comum é confundir esse tipo de configuração com a configuração de controle de acesso de outros elementos do Portal que pode utilizar esse grupo.

A definição de membros de um grupo pode ser realizada de duas maneiras, atribuindo o grupo como membro de outros grupos ou atribuindo membros a esse grupo. A interface chamada pelo botão “Membro de” exibe todos os grupos dos quais o grupo selecionado faz parte, direta ou indiretamente, como vemos abaixo:

Nesse exemplo, o Grupo A selecionado foi definido explicitamente como membro do Grupo B. Como o Grupo B também foi definido como membro do grupo Administradores do Portal e como o grupo Administradores do Portal é membro dos grupos Publicadores e Desenvolvedores, o Grupo A passa a ser membro indiretamente desses três últimos. Repare que a lista de Grupos Indiretos não é administrável, ela é composta automaticamente a partir da lista de Grupos Diretos, essa sim que pode ser alterada. Para adicionar um grupo como membro de outro é acionado o botão Adicionar, que chama a interface abaixo:

Aqui o usuário pode selecionar o grupo do qual deseja que o grupo selecionado seja membro. O filtro Domínio é utilizado para selecionar apenas grupos globais ou grupos locais, filtrando pelo prefixo de cada canal configurado para permitir grupos locais.

Já o botão Membros presente no Gerenciador de Grupos, permite adicionar ou excluir membros do grupo selecionado, que podem ser usuários ou grupos, através da interface abaixo:

Repare que aqui são exibidos apenas membros diretos. No exemplo acima, no qual selecionamos o Grupo B para administração de seus membros, caso o Grupo A possua usuários ou grupos como membros de si, estes também serão, indiretamente, membros do Grupo B, embora não sejam exibidos nessa interface.

O botão de Adicionar dessa interface chama a interface de seleção de usuários e grupos abaixo, similar a que vimos acima para a seleção de grupos e que também permite filtrar pelo domínio:

Todas as interfaces que vimos acima foram acessadas a partir do Gerenciador de Grupos global, que também permite atualizar e excluir grupos todos os grupos locais do Portal. Como veremos abaixo a administração dos grupos locais é muito similar.

Administração de grupos locais

Para que um canal permita a utilização de grupos locais, em primeiro lugar essa configuração precisa ser realizada na interface de propriedades de um canal, acessada a partir do right-click. Essa configuração é realizada na aba “Avançado” dessa interface, como vemos abaixo:

Deve ser marcado o checkbox “Habilitar Grupos Locais”, o que faz com que seja exibido o campo Prefixo, no qual deve ser definido o prefixo que será utilizado para identificar os grupos locais pertencentes a esse canal.

A partir do momento em que um canal está configurado para habilitar grupos locais, a administração de grupos passa a ser exibida na lista de administrações de um canal. Para acessar essa lista basta clicar sobre o canal na estrutura de canais e página.

Podemos ver que a interface para gerenciamento de grupos locais é idêntica a interface de Gerenciador de Grupos global, no entanto duas diferenças de comportamento precisam ser destacadas. A primeira delas é que nessa interface são exibidos apenas os grupos locais do canal em questão.

A segunda diferença é na criação de grupos. Para grupos locais não é possível definir tipos de grupos customizados, todos os grupos locais são do tipo de grupo padrão, como podemos ver na interface de adicionar abaixo, chamada a partir do botão Adicionar:

Embora grupos locais possam, tecnicamente, ser utilizados na definição de controle de acesso de canais externos ao canal ao qual pertençam, essa prática é altamente desaconselhável, por razões de legibilidade da arquitetura definida. O ideal é que o escopo de atuação dos grupos locais se restrinjam ao canal a que pertencem e a seus sub-canais, de modo que o conceito do grupo local seja preservado.

Principais pontos para abordagem prática

Definição da estrutura ideal de grupos globais e locais para um determinado cenário
Exercício de criação dos grupos globais e locais

Autor: Tiago Porcher (Lumis)