BISSecurity

O serviço de BISSecurity tem a finalidade de facilitar e centralizar o controle de acesso de usuários no sistema.

Chaves de Acesso

O controle de acesso é gerenciado por "chaves" de acesso. Cada chave tem a finalidade de definir o acesso a alguma ação no sistema. A ação pode ser de manipular algum dado, ou simplesmente de visualiza-lo, como gerar um relatório ou abrir uma tela de consulta, etc.

As chaves são cadeias de caracteres (strings) únicas no sistema. Todas as chaves de acessão são declaradas como constantes na classe BISSystem, onde a o nome da constante é o próprio nome da chave com o prefixo SECKEY_ por questões de organização e maior facilidade em caso de Refactory. Em todas as partes do sistema deve-se utilizar a constante como referência e nunca a String da chave sozinha.

Refactory de Chaves de Acesso Cuidado ao realizar o refactory da chave de acesso, pois embora no código elas estejam concentradas no BISSystem, no banco de dados elas estão escritas como texto fixo e precisarão ser renomeadas também. A mudança é feita em nas tabelas de acesso de todos os Schemas de empresas. Caso haja necessidade de renomear uma chave, considere renomear apenas o nome da constante, deixando o 'código' da chave estático. Considerando a sugestão acima, ao criar uma chave sempre verifique se o 'código' da chave ainda não existe (com uma busca simples na classe), mesmo sendo um caso difícil de acontecer é possível e daria muitos problemas de acesso.

Conflito de Chaves Para evitar o conflito ou a coincidência de chaves idênticas no sistema é aconselhável que as chaves sigam uma estrutura similar a usada nos pacotes de organização do código. Por exemplo: Chaves de acesso do domínio do BIS: DOMAINADMIN_COMPANY_MANAG DOMAINADMIN_USERS_MANAGE Chaves de acesso a funções do Kernel KERNEL_COMPANY_MANAGE KERNEL_USERSGROUP_MANAGE Chaves de acesso dos módulos do BIS ITEM_ITEMCATEGORY_MANAGE

Chaves de Acesso à Objetos

Por algumas vezes além definir o acesso do usuário à uma tela ou função, queremos que um determinado usuário tenha acesso à um objeto mas não a outro. Por exemplo, desejamos que um determinado usuário tenha acesso para fazer lançamentos em uma "conta caixa" que ele controla, mas não a fazer lançamentos em outras contas. Ver o saldo de uma determinada conta, mas não à outras. Para resolver esse tipo de acesso podemos criar as chaves de forma dinâmica e devolve-las junto com a hierarquia de chaves.

As chaves dinâmicas devem seguir as seguintes regras:

• Chaves de um mesmo tipo de objeto devem ter sempre a mesma 'secKey', ou identificador de chave, a única diferença entre elas é o ID do objeto que é passado em cada chave;
• Chaves de um determinado tipo devem ser todas filhas de uma mesma chave pai do tipo 'genérica';
• Nada impede que as chaves dinâmicas tenham chaves filhas, mas devem ser todas dinâmicas também;

Criação de Chaves Únicas Para manter a compatibilidade do código já existente, e mesmo manter simples o desenvolvimento atual, as chaves de segurança devem ser sempre únicas. Assim, ao criar um objeto SecureKeyVO para uma chave do tipo 'OBJECT' ele automaticamente concatenará a chave passada com o ID do objeto para gerar o ID da chave de acesso, no padrão <chave de acesso> + "_" + <ID do Objeto>. Assim, quando for salva no banco ou gerenciada solicitando permissão a chave estará sempre composta.

Exclusão de Chaves de Acesso O BIS por padrão não exclui acessos mesmo quando não detecta que a chave foi retornada pelo Plugin. Isso porque o BIS acredita que o algum módulo do Plugin ou mesmo o Plugin todo possa ter sido desabilitado temporariamente e excluir os acessos ocasionará falha no acesso quando os módulos ou plugins forem reativados. Por tanto, sempre quem plugin excluir uma chave de acesso, ou excluir o objeto de associado a uma chave de acesso, ele fica responsável por excluir os eventuais acessos dado para esta chave[/objeto]. Caso contrário o banco passará a ter registros e acessos sem utilidade.

Exibição de Chaves de Acesso Embora o BIS não apague os acessos dado às chaves que não estão mais disponíveis ele não exibe esses acessos nas telas de permissões. Isso porque se um plugin ou módulo foi desabilitado suas chaves e acessos não podem ser modificados, e nem utilizados.

Usuários e Grupos de Acesso

O BIS suporta a criação de usuários de acesso ao sistema e a Criação de Grupos de Acesso. Todas as permissões de acesso devem ser definidas em um grupo, por isso chamado de grupo de acesso. Uma vez definidos os acessos no grupo, devem ser colocados os usuários para que estes ganhem o acesso.

O BIS não permite definir acessos diretamente no usuário. Acreditamos que a definição de acesso no usuário conduza o usuário a erros e definição de permissões erradas, já que teria que redefinir os acessos toda vez que um novo usuário é criado.

Grupo de Sistema, Grupo de Segurança e Grupo de Usuário

Existem três tipos de grupos que o sistema suporta:

• Grupo de Usuário - Este grupo é criado e mantido pelo usuário conforme ele bem entender e achar necessário.
• Grupo de Segurança - Esse grupo é internamente criado pelo sistema. Este tipo de grupo não pode ser excluído do sistema, nem seu Nome e Descrição podem ser alterados. Ele oferece acessos predefinidos pelas atualizações do sistema, mas que podem ser alteradas pelo usuário para personalizar melhor este grupo conforme as necessidades do usuário. A vantagem em um grupo assim é que o sistema pode incluir automaticamente novas permissões nestes grupos conforme o sistema evolui, sem tirar a autonomia do usuário em adaptar o grupo a sua necessidade. Definir novas permissões automaticamente durante as atualizações é viável pois evita que após uma atualização seja necessário definir manualmente todas as novas permissões para um determinado grupo de acesso.
• Grupo de Sistema - Esse grupo é completamente fechado e não pode ser alterado em ponto algum pelo usuário. Nem ter suas permissões alteradas, nome alterado, descrição, etc. Apenas é permitido escolher quem participará deste grupo.

Identificação do Grupo Durante o desenvolvimento, os grupos criados devem receber um 'innerID' único utilizado para identificar o grupo. Isso porque o ID pode variar de uma instalação para outra, já que o usuário pode ter criado seus próprios grupos, e novos grupos de Segurança e Sistema receberem IDs diferentes em casa instalação do sistema.

Controle de Acesso à Métodos do Fachada

A fachada do BIS tem sua segurança implementada no BISFacadeInterceptor. Todos os métodos da fachada por padrão devem receber como primeiro parâmetro uma String com o UUID da sessão do usuário. Essa UUID é fornecida quando o usuário chama o método doLogin() da fachada. O método doLogin() não exige a UUID, por razões óbvioas.

Para configurar os métodos da fachada, o método deve usar a Annotation Security e utilizar uma de suas opções de autenticação. A exigência da sessão (mandar a UUID como primeiro parâmetro do método) é a autenticação padrão e não exige a presença a Annotation. Para que não seja exigida a UUID ou outros tipos de definições a Annotation é obrigatória.

Quando o UUID está presente, o BISFacadeInterceptor recupera a sessão e a registra automaticamente no BISSessionManager para a Thread sendo utilizada.

Obtendo dados da Sessão

A sessão do usuário pode ser obtida através da classe BISSessionManager. Esta classe mantém a sessão do usuário disponível. A sessão é associação à Thread em execução ao entrar no EJB, e fica disponível estaticamente durante toda a execução do método. Ao retornar do EJB a sessão é desvinculada já que a Thread é um pool do Glassfish e será reutilizada por outra chamada.

Atenção com Forks e Novas Thread Ao criar uma nova Thread para executar serviço em paralelo a sessão não será propagada automaticamente. Para isso necessário utilizar os métodos de registrar a Sessão à Thread manualmente, ou os métodos que solicitarem autenticação, bem como serviço de BISLogger, não encontrará as informações da sessão corretamente.