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: SECKEY_DOMAIN_COMPANY_MANAGE SECKEY_DOMAIN_USERS_MANAGE Chaves de acesso as funções Sistema: SECKEY_COMPANY_USERSGROUP_MANAGE SECKEY_COMPANY_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 do banco de dados só porque a chave foi excluída do sistema. Essa limpeza de chaves que não estão mais em usa deverá ser feita manualmente no futuro. Ou mesmo ter alguma tarefa capaz de realizar esse tipo de atividade.

Medidas de Segurança

Além das chaves de acesso que permitem ou negam o acesso a partes do sistema, temos de tomar cuidado com algumas outras regras para não anular o funcionamento do sistema de acesso:

• O acesso à tela de Grupos de Acesso só é concedido aos participantes do grupo de Sistema Administradores da Empresa.
• A chave que permite acesso à tela Grupo de Acesso não é exibida na tela de definição de acesso, para que este acesso não seja manualmente concedido a nenhum outro grupo.

Desta maneira, apenas os administradores da empresa, que tem acesso a empresa toda, podem definir outros acessos. Garantimos assim, de forma bem restrita e poucas condições no código, que algum usuário possa ser dar mais acesso do que já tem.

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 induza 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 de Sistema e Segurança 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.

Ao criar novos grupos de Sistema e Segurança, tenha em mente um escopo bem definido da função que a pessoa exerce para receber tais atribuições. E faça uma boa descrição do para que este grupo servirá, tirando o máximo de dúvidas tanto dos clientes que vão atribuir seus usuários nesses grupos, quando dos desenvolvedores futuros que colocaram novas chaves dentro dos grupos existentes.

Escopo Pequeno de Acessos Dê sempre preferência para escopos relativamente pequenos de acessos. Por exemplo, ao invés de ter um grupo de "Administrativo", que englobaria qualquer função de administração da empresa (Cadastro de Itens, Contas à Pagar/Receber, Notas Fiscais, etc.), crie grupos separados como "Cadastradores de Itens", "Administrador de Contas à Pagar/Receber", "Administrador de Notas Fiscais", etc. E deixando a descrição detalhada do que entra ou não neste grupo.

Para visualizar e estudar os grupos já criados, basta utilizar a versão de desenvolvimento e executar a seguinte query:

select * from `bis_bis`.`k_usergroup` where type in ('SYSTEM', 'SECURITY')\G

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. Por padrão, quando não há uma Annotation definida no método, é que o usuário esteja autenticado em uma sessão válida. Ou seja, deve mandar a UUID como primeiro parâmetro do método Métodos que podem ser chamados sem uma autenticação prévia (como o método de Login) devem ter a annotation definida com a opção de byPass de Sessão.

Quando o UUID está presente, o BISFacadeInterceptor recupera a sessão e a registra automaticamente no BISSessionManager na Thread sendo utilizada. Deste modo em qualquer ponto depois da fachada fica fácil recuperar dados da sessão.

Fork de Thread e a sessão Quando há no código a utilização de Threads ou de trabalhos em Background, é necessário registrar a sessão nas novas Threads. Caso contrário partes do código podem não funcionar bem, como por exemplo o sistema de Log.

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.