Sistema de Gestão de Logins: Proposta de sistema para unificação de usuários na rede acadêmica PUC Minas

Pontifícia Universidade Católica de Minas Gerais Programa de Pós Graduação Lato Sensu Engenharia de Software - Turma 32

Giovanni Cândido da Silva

Sistema de Gestão de Logins: Proposta de sistema para unificação de usuários na rede acadêmica PUC Minas

Belo Horizonte 2016

Giovanni Cândido da Silva

Sistema de Gestão de Logins: Proposta de sistema para unificação de usuários na rede acadêmica PUC Minas Trabalho de Diplomação apresentado ao Instituto de Educação Continuada da Pontifícia Universidade Católica de Minas Gerais como requisito parcial para obtenção do título de especialista em Engenharia de Software.

Orientador: Nelson

Belo Horizonte 2016

Maria Augusta Vieira

Lista de abreviaturas e siglas AD

Active Directory

FCA

Faculdade de Comunicação e Artes

HTTP

Hypertext Transfer Protocol

ICEI

Instituto de Ciências Exatas e Informática

IEC

Instituto de Educação Continuada

LDAP

Lightweight Directory Access Protocol

OU

Organisational Unity

SGL

Sistema de Gestão de Logins

SMTP

Simple Mail Transfer Protocol

SQL

Structured Query Language

REST

Representational State Transfer

LDAP

Lightweight Directory Access Protocol

Sumário 1

INTRODUÇÃO

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.1

Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2

Objetivos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2.1

Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2.2

Objetivo Específico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2.3

Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2

FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . .

7

2.1

Arquitetura de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.1.1

Padrões Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3

CONSTRUÇÃO DO APLICATIVO . . . . . . . . . . . . . . . . . . . 11

3.1

Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1

Importação de pessoas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.2

Acompanhar Situação de importação em tempo real

3.1.3

Adicionar pessoas no AD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.4

Auditoria de operações do sistema . . . . . . . . . . . . . . . . . . . . . . 13

3.1.5

Configurar acesso Ldap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.6

Controle de acesso e segurança . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.7

Criar usuário no Active Directory

3.1.8

Filtros de pesquisa de pessoas . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.9

Listar e pesquisar Pessoas . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.10

Manter regiões de importação e operação . . . . . . . . . . . . . . . . . . 14

3.1.11

Relatório de importação de alunos . . . . . . . . . . . . . . . . . . . . . . 14

3.1.12

Testar conexão com AD . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.13

Reset de senha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.14

Trocar senha de usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2

Casos de Uso Chave . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1

Importar Pessoas no AD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1.1

Desafios Técnicos de Unificação . . . . . . . . . . . . . . . . . . . . . . . .

18

3.2.1.2

Forma de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.2.2

Auditoria de operações do sistema . . . . . . . . . . . . . . . . . . . . . . 23

3.2.3

Reset de senha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.4

Controle de acesso e seguranca . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3

Fatores Arquiteturais Relevantes . . . . . . . . . . . . . . . . . . . . . 24

3.4

Soluções Arquiteturais e de Design . . . . . . . . . . . . . . . . . . . 30

. . . . . . . . . . . . 13

. . . . . . . . . . . . . . . . . . . . . . 14

3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6

Importar Pessoas no AD . . . . Proposta alternativa . . . . . . . Auditoria de operações . . . . . Reset de senha . . . . . . . . . Controle de acesso e segurança . Implantação . . . . . . . . . . . Visão Geral . . . . . . . . . . .

4

CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4.1.1

REFERÊNCIAS

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

30 33

39 41 45 46 46

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

APÊNDICE A – CÓDIGOS FONTE . . . . . . . . . . . . . . . . . . 54 APÊNDICE B – APRESENTANDO O PROJETO DE AUDITORIA 55 APÊNDICE C – SCRIPT PARA TESTE DE CARGA DE EMAIL . 56 APÊNDICE D – MENSAGEM ORIGINAL DE EMAIL . . . . . . . 57 APÊNDICE E – CONFIGURAÇÕES DO SISTEMA . . . . . . . . . 59 APÊNDICE F – PARÂMETROS DE CONFIGURAÇÃO DE EMAIL 60 APÊNDICE G – CONFIGURAÇÃO DE AGENDAMENTO DE IMPORTAÇÃO . . . . . . . . . . . . . . . . . . . . . 61

1 Introdução Esse trabalho tem como objetivo a modelagem de um sistema de informação capaz de integrar informações de login de usuários em uma rede Active Directory (AD). Tem como partida a necessidade de unificação de informações sobre alunos da universidade PUC - Minas, em sua rede acadêmica, através da importação de dados de outros sistemas existentes.

1.1 Justificativa A rede acadêmica da universidade é um ambiente dinâmico e de grandes dimensões, que encontra-se espalhada por diversos campos no estado de Minas Gerais. Existem inúmeros equipamentos de rede e sistemas que são de uso coletivo como laboratórios, acesso wireless, impressoras, sistemas de controle de laboratórios, firewall, sistemas como o acesso ao portal capes, entre outros. Esses equipamentos e sistemas muitas vezes necessitam autenticar usuários como alunos, professores e funcionários. Sem uma fonte de dados central diversos desafios solucionados localmente pelas equipes distribuídas são enfrentados, para prover acesso a tais sistemas, gerando várias identificações desconectadas. O ciclo de vida de um usuário também não é controlado de forma efetiva, gerando ocasiões em que uma pessoa não está mais em um papel, no entanto continua com o acesso, ou quando deve possuir um acesso mas não foi cadastrado no mesmo. Controlar e cadastrar manualmente, esses acessos diversas vezes entre os setores da rede acadêmica, tem afetado negativamente um número aproximado de 60 mil usuários. Praticamente todo sistema que seja amplamente utilizado na universidade pede uma autenticação global e um controle de ciclo de vida.

1.2 Objetivos 1.2.1 Objetivo Geral O objetivo geral desse trabalho é modelar um sistema capaz de importar e consolidar informações sobre alunos, professores e funcionários de diversas bases autoritativas, mantendo usuários em sistema Active Directory como resultado.

1.2.2 Objetivo Específico Como objetivos específicos do trabalho pode ser citado:

6 • Levantar requisitos arquiteturais; • Projetar a arquitetura do sistema; • Propor a integração dos sistemas utilizando mensagens assíncronas; • Implementar uma prova de conceito. O sistema modelado tem como objetivos específicos: • Centralizar a administração de usuários; • Integrar sistemas diversos; • Integrar-se em um portal de sistemas.

1.2.3 Organização do Trabalho O Capítulo 2 apresenta os conceitos fundamentais em que o trabalho foi embasado, falando principalmente das abordagens de integração de sistemas e de arquitetura de sistemas. O Capítulo 3 descreve o sistema, seus requisitos e design. Sendo dividido em 3 (três) partes de requisitos e uma parte de design, sendo elas: A seção 3.1 - Apresenta e descreve brevemente os casos de usos do sistema. A seção 3.2 - Descreve os casos de uso principais para arquitetura do sistema em mais detalhes. A seção 3.3 - Faz um levantamento de fatores funcionais e não funcionais relevantes para o sistema. A seção 3.4 - Apresenta as soluções propostas para cada caso de uso chave procurando levar em consideração os fatores arquiteturais levantados. Também descreve como o sistema pode ser implantado.

2 Fundamentação Teórica Este capítulo tem como objetivo apresentar as tecnologias que serão utilizadas e os ambientes em que elas se aplicam, bem como suas nomenclaturas, com o intuito de facilitar a leitura do presente trabalho.

2.1 Arquitetura de Sistemas Bass, Clements e Kazman (2003) definem a arquitetura de software como sendo a estrutura do sistema composta de elementos de software, as propriedades externas visíveis desses elementos, e o relacionamento entre eles. O Institute of Electrical and Electronics Engineers (IEEE) Working Group Architecture define arquitetura como sendo “o conceito de mais alto nível de um sistema em seu ambiente”(IEEE, 2000) essa definição está presente no padrão ISO (International Organization for Standardization)1 /IEEE 14712000. As duas definições acima são explicitas quanto ao papel de abstração da arquitetura de software, observando o sistema com base em suas partes modulares ou funcionais. Essa abstração facilita o entendimento do sistema, traz uma visão do sistema como um todo, incluindo suas interfaces externas, ambiente de usuário e de desenvolvimento, ajudando a resolver problemas complexos. Além disso a arquitetura de sistemas serve como base para metodologias de software como Rational Unified Process (RUP) e o OpenUp2 . O RUP possibilita o desenvolvimento iterativo e incremental, guiado por casos de uso e centrado na arquitetura (JACOBSON; BOOCH; RUMBAUGH, 1998). Já o processo OpenUp por ser baseado no RUP também considera a arquitetura um de seus pontos chaves, colocando com um de seus princípios o foco na evidenciação arquitetural: Sem uma fundamentação arquitetural, um sistema evoluirá de forma ineficiente e casual. Tais sistemas normalmente são difíceis de evoluir, reusar, ou integrar sem que exista um substancial retrabalho. Também é difícil organizar ou comunicar idéias sem o foco técnico comum que a arquitetura fornece. Assim, use a arquitetura como um ponto focal para que desenvolvedores possam alinhar seus interesses e idéias ao evidenciar decisões técnicas essenciais através da arquitetura em desenvolvimento. (OPENUP, 2008). 1 2

International Organization for Standardization OpenUP é um processo de desenvolvimento de software de código aberto projetado para equipes pequenas e co-localizadas que querem ter uma abordagem ágil para desenvolvimento, esse processo é produzido e documentado com o apoio da ferramenta eclipse process framework. Para mais informações acesse http://epf.eclipse.org/wikis/openuppt/index.htm

8 As representações arquiteturais não estão limitadas a uma visão geral do sistema podendo possuir múltiplas visões, cada qual focando em uma parte ou aspecto do sistema. Por exemplo pode-se ter uma visão em camadas gerais, da implantação do sistema, das chamadas de procedimentos ou serviços, entre outros. A Figura 1 é um exemplo de uma visão de arquitetura.

Figura 1 – Exemplo de visão arquitetural Fonte: Cunha, 2011

2.1.1 Padrões Arquiteturais Existem soluções para problemas de arquitetura de sistemas conhecidos, esses padrões formam uma infra-estrutura arquitetural (middleware). Uma estrutura arquitetural ou uma infra-estrutura arquitetural (middleware) é um conjunto de componentes com os quais você pode construir um determinado tipo de arquitetura. Muitas das principais dificuldades arquiteturais devem ser resolvidas na estrutura ou na infraestrutura, geralmente direcionada a um domínio específico (OPENUP, 2008).

Os padrões que mais são utilizados no desenvolvimento de software de integração são: Modelo Visão Controlador (MVC) - Segue o princípio de arquitetura em camadas dividindo o sistema em três camadas distintas com o objetivo principal de reduzir o acoplamento entre a interface de usuário com o restante do sistema. A camada

9 de visão é responsável pela interface do usuário com o sistema. Os modelos são responsáveis pelas regras de negócio da aplicação e persistência e dados relativos. Os controladores formam a cola entre modelo e visão recebendo requisições e instanciando os modelos corretos, sendo o local ideal para implantar regras de acesso e segurança. (GAMMA et al., 1994) Mensagem de evento - Padrão utilizado para integração de sistemas de forma assíncrona e confiável, onde uma mensagem é gerada e enviada em um canal de comunicação. Um observador recebe e processa a mensagem. Vários sistemas de mensagens existem no mercado que oferecem garantias de entrega para os observadores. (HOHPE; WOOLF, 2012). Base de dados Compartilhada - Trata-se do uso de uma base de dados comum para troca de informações entre aplicações. (HOHPE; WOOLF, 2012). Segundo Hohpe e Woolf (2012) As várias abordagens de integração de sistemas podem ser sumarizadas em quatro estilos de integração principais: Transferência de arquivos, base de dados compartilhada, invocação de procedimento remoto, mensagens. Cada padrão tem os mesmos problemas e objetivos mas cada um é construído apartir de onde o outro parou, buscando uma maior sofisticação para resolver limitações nos anteriores. A integração utilizando base de dados compartilhada fornece uma forma rápida e consistente de integração. Em casos de atualizações simultâneas de dados, as bases de dados compartilhadas fornecem um sistema transacional que pode cuidar do acesso concorrente de forma elegante. O uso prevalente de base de dados relacionais SQL (Structured Query Language), torna fácil o uso de bases compartilhadas. (HOHPE; WOOLF, 2012) Uma das grandes dificuldades com o uso de bases de dados compartilhadas está em ter um esquema que atenda as necessidades das múltiplas aplicações que o utilizam, embora o uso de arquivos compartilhados seja pior nesse caso, pois o formato de dados é menos restrito. Segundo (HOHPE; WOOLF, 2012): Frequentemente isso representa problemas sutis de representação de negócios que podem ter um grande impacto. Uma base de dados geológica pode definir um poço de petróleo como um único furo que pode ou não produzir óleo. Uma base de dados de produções pode definir poço como múltiplos furos cobertos por uma única peça de equipamento. Esses casos de dissonância semântica são muito mais difíceis de se lidar, do que inconsistência de formatos de dados.3

Um sistema de mensagens possui os seguintes conceitos básicos: 3

Often these represent subtle business issues that can have a huge effect. A geological database may define an oil well as a single drilled hole that may or may not produce oil. A production database may define a well as multiple holes covered by a single piece of equipment. These cases of semantic dissonance are much harder to deal with than inconsistent data formats.

10 Canais - Os dados são transmitidos através de um canal que conecta as aplicações. O canal pode ser criado como tópicos a serem subscritos. Mensagem - Uma mensagem é um envelope imutável transmitido em um canal. As aplicações devem definir o formato da mensagem e subdividi-las (HOHPE; WOOLF, 2012). Diversos sistemas em produção com o Amazon Message Queue Service fornecem garantias de entrega, mas não de ordem das mensagens (Amazon Inc, 2016). Entrega em múltiplos passos - Em casos simples a entrega é feita diretamente entre quem enviou e quem irá receber, no entanto ações podem ser tomadas no meio do caminho por outros sistemas, antes que a mensagem chegue ao destino. Por exemplo transformações e validações da mensagem. Rota - Em sistemas empresariais de larga escala, uma mensagem pode ter que passar por diversos canais antes de atingir o seu destino. A aplicação de origem pode ter que enviar a mensagem para um roteador de mensagens que irá determinar como navegar a topologia e entregar a mensagem Transformação - Aplicações podem não acordar no formato de uma mensagem com mesma semântica. Para resolver esse problema a mensagem pode passar por um filtro intermediário que irá transformá-la de um formato em outro. Pontos Finais - São programações nas aplicações que criam uma camada de comunicação e sabem como o sistema de mensagens funciona, fazendo com que as regras da aplicação e do sistema funcionem em conjunto. Os pontos de mensagem fazem com que a aplicação envie e receba mensagens. Diversos padrões de projetos derivam de sistemas de mensagens, esse trabalho não faz uso de todos eles, o conhecimento dos conceitos básicos deve ser o suficiente para entender a soluções propostas na Seção 3.4.

3 Construção do Aplicativo Para modelagem e construção foram levantados requisitos funcionais e não funcionais que servirão como base. Para os requisitos funcionais foi feito levantamento de casos de uso. A Figura 2 apresenta as principais funcionalidades de sistema que são explicadas brevemente na seção 3.1. A Tabela 1 resume os atores que interagem com o sistema. Dos casos de uso existentes foram selecionados como casos de uso chave para arquitetura do sistema.

• Importar Pessoas no AD. Que inclui: Importar alunos IEC, Importar alunos SGA, Importar funcionários, Importar Professores, Acompanhar situação de importação em tempo real. 3.2.1; • Auditoria de operações do sistema. Seção 3.2.2; • Reset de senha. Seção 3.2.3; • Controle de acesso e segurança. Seção 3.2.4.

Ator Aluno Funcionário Professor Técnico Administrativo Técnico de Informática

Usuário Acadêmico

Descrição Aluno da universidade, seja matriculado ou formado Funcionário da universidade Professor da universidade Responsável pelo atendimento de primeiro nível a alunos, professores e funcionários Responsável pelo atendimento e manutenção de redes, computadores e equipamentos gerais Também presta suporte à alunos, professores e funcionários em assuntos relacionados a rede acadêmica da universidade Representa todos os usuários finais da rede acadêmica Tabela 1 – Atores Fonte: Elaborado pelo Autor

12

Figura 2 – Casos de Uso Fonte: Elaborado pelo Autor

3.1 Casos de uso 3.1.1 Importação de pessoas Principal Funcionalidade do sistema. Esse caso de uso é explicado em mais detalhes na Seção 3.2.1.

13

3.1.2 Acompanhar Situação de importação em tempo real Em tempo real o progresso da importação deve ser enviado a todos os navegadores conectados na tela de importação de sistemas. Todos os analistas conectados que estejam com a tela de importação aberta irão ver o progresso da importação.

3.1.3 Adicionar pessoas no AD Cria contas de usuário no Active Directory. As contas podem ser: Alunos, professores, funcionários ou terceiros. O cadastro deve conter: nome, login, email, local, grupos de usuário Local é uma localização dentro da árvore do AD. Geralmente tida como o curso da pessoa. A organização atual do AD deve ser refletida no cadastro. Os grupos de usuário podem ser deduzidos quando a pessoa é um aluno ou usuário terceiro. Professores devem ter seus grupos selecionados, os grupos são os grupos existentes no Active Directory, que foram criados pela importação (geralmente um grupo por curso).

3.1.4 Auditoria de operações do sistema Permite auditar as operações do sistemas e saber todas as ações realizadas por usuários em um determinado período de tempo. Esse caso de uso é melhor detalhado na Seção 3.2.2.

3.1.5 Configurar acesso Ldap Como administrador do sistema é necessário configurar uma conexão LDAP. Essa configuração é utilizada em todo o sistema para conectar com o Active Directory e consiste de: • IP ou host do servidor; • Porta; • Se porta usa SSL (Secure Socket Layer) para conexão; • usuário e senha; • Domínio; • Base de Procura - Consiste em uma OU (Unidade Organizacional) onde todas as operações do aplicativo ficarão salvas. Ao criar um usuário ele será criado dentro desta OU. O sistema pode criar novas OU dentro da hierarquia para organizar as operações.

14

3.1.6 Controle de acesso e segurança É necessário controlar o acesso ao sistema de forma centralizada. Todo acesso será controlado pelo servidor Keycloak e a aplicação deve integrar-se ao mesmo. Os grupos de usuários são: • Técnico - Informática; • Analistas; • Técnico - Administrativo; Mais detalhes podem ser encontrados na Seção 3.2.4.

3.1.7 Criar usuário no Active Directory Um formulário contento informações sobre o usuário é preenchido e salvo no AD. O Usuário recém criado contém senha de acesso padrão e deve trocá-la no primeiro login.

3.1.8 Filtros de pesquisa de pessoas Filtrar pessoas por critérios como unidade organizacional, tempo de expiração, etc.. A combinação dos filtros é possível e se dá de forma lógica AND, ou seja um filtro quando combinado com outro limita ainda mais o escopo da pesquisa.

3.1.9 Listar e pesquisar Pessoas Pessoas cadastrados no AD devem ser listadas. Deve ser possível filtrar a lista por nome ou por número de pessoa/login. O sistema deve mostrar como resultado o nome completo da pessoa, o curso que frequenta (se aluno) e o número de pessoa.

3.1.10 Manter regiões de importação e operação Utilização de mais de um active directory que estará associado ao login do usuário que o conectar, com isso todas as operações do sistema se darão no active directoryassociado. Motivação: Operações em active directory locais não precisam esperar o tempo de replicação para serem efetivadas.

3.1.11 Relatório de importação de alunos Após cada importação do sistema, informações de sucesso, falha e causa são mantidas para consulta posterior. O relatório deve identificar cada operação feita com a conta da

15 pessoa durante a importação como por exemplo: Pessoa movida, atributos atualizados, usuário bloqueado, etc.. Esse relatório deve ser acessado apenas por usuário com perfil analista. Deve permitir o filtro por data e status e apresentar um resumo sobre o número de sucesso e falhas.

3.1.12 Testar conexão com AD Ao salvar uma conexão em configurações gerais, pode-se testar a comunicação com o AD utilizando as informações preenchidas.

3.1.13 Reset de senha Qualquer usuário do sistema (aluno, professor, funcionário) deve poder resetar a própria senha no sistema. Fluxo Principal: 1. Usuário acessa a página de reset de senha; 2. Usuário informa o seu número de pessoa; 3. Sistema envia um email para o usuário com um link de ativação; 4. Usuário acessa o link de ativação; 5. Sistema valida o token de ativação e apresenta página para reset de senha; 6. Usuário entra com a nova senha e confirma reset; 7. Sistema altera a senha do usuário; Pós condição: Senha do usuário é trocada no Active Directory.

3.1.14 Trocar senha de usuário Como usuário não técnico do sistema é necessário ter uma forma de alterar a senha do aluno. Quando a senha é trocada, uma senha aleatória padrão é gerada e exibida na tela para ser repassada para o aluno. O AD deve ser instruído a trocar a senha do aluno no primeiro login do mesmo.

16

3.2 Casos de Uso Chave Esta seção apresenta em detalhes os casos de uso chave para a solução proposta. Cada caso de uso pode incluir requisitos não funcionais que foram julgados importantes para o sistema. O caso de uso Importar Pessoa no AD tem uma explicação mais detalhada, tendo em vista que a realidade da universidade e algumas limitações técnicas impostas pelo AD o tornam mais complexo, e alguns problemas são levantados. A solução proposta tenta minimizar esses problemas onde possível.

3.2.1 Importar Pessoas no AD A principal funcionalidade do sistema é a importação de pessoas no AD. O objetivo final é integrar bases distintas e unificar os logins de todos os envolvidos: Alunos, Professores e Funcionários com acesso a rede Acadêmica da PUC Minas. Durante o desenvolvimento do trabalho a importação de funcionários foi retirada do escopo do projeto pela gestão da Universidade. No entanto optou-se por manter as referências já citadas. No cenário atual, diversos sistemas são responsáveis pela origem dos dados, esses sistemas são criados e mantidos por equipes e setores distintos cuja cooperação no projeto se dá de forma passiva. Essa restrição será importante na definição dos meios de integração dos sistemas. Inicialmente a única forma de comunicação com o sistemas era via arquivos. Um arquivo de importação em formato CSV (Comma Separated Values) é enviado para o servidor que inicia um processo em lote para importar cada aluno para o Active Directory configurado. Informações como curso, número de matrícula período, etc, constam no arquivo. As equipes acordaram em manter uma base de dados compartilhada. Mais informações na subseção 3.4.1. Regras de negócio serão aplicadas ao importar alunos, algumas regras em discussão são: 1. Ao ser importado o usuário deve ser associado a um grupo de usuário do curso em que frequenta ou dá aula. 2. Os grupos professores e alunos e alunosIEC devem ser criados e os respectivos usuários associados. 3. Não deve ser importado o aluno caso esteja com situação irregular. 4. Pessoas podem ser bloqueadas ou removidas dependendo da situação em que se encontrarem.

17 O objetivo do sistema será extrair essas informações e consolidá-las em uma base Active Directory, conforme visualizado na Figura 3. A hierarquia proposta está representada na Figura 5, explicada a seguir: • Alunos de especialização estarão em uma OU única chamada IEC; • Alunos de graduação, mestrado e demais cursos provindos do sistema autoritativo SGA, estarão na hierarquia Unidade/Faculdade/Curso; • Professores estarão em uma OU única chamada Professores;

Figura 3 – Objetivos Fonte: Elaborado pelo Autor Para concluir o objetivo cada base de dados autoritativa será abordada em incrementos de desenvolvimento. A importação será feita de forma a acomodar diferentes formatos de entrada de dados, e fazer diferentes mapeamentos. As partes que variam nesse fluxo são: • Entrada de dados. Diferentes bases autoritativas fornecem diferentes arquivos de dados de entrada;

18 • Mapeamento de dados. Diferentes classes de objetos (alunos, professores, funcionários) possuem diferente mapeamento final. Por exemplo: Alunos podem ser mapeados para um caminho que inclui seu curso e unidade, enquanto professores podem estar associados a um departamento, um professor dá aula em mais de um curso e unidade simultaneamente, etc.; • Tratamento de dados. Durante o processo de importação, cada classe de objetos tem tratamento diferenciado dos demais. Por exemplo um aluno com situação irregular pode ser removido ou bloqueado do Active Directory, um professor que não dá mais aula em um curso pode ter seu grupo de usuários alterado, etc.; As partes que se mantém são: • Deve-se reportar o progresso da importação. • Deve-se fazer operações no Active Directory, como a inclusão, remoção alteração de grupos, etc. • A operação pode ser cancelada. • Podem ocorrer diversos erros durante o processo, associados a aplicação ou a persistência de dados. Importante também enfatizar que uma pessoa pode ocupar diferentes papéis simultaneamente na universidade. É comum um sujeito ser aluno e funcionário ao mesmo tempo, também pode acontecer de ser professor e funcionário administrativo, em alguns casos pode ser os três, também pode fazer mais de um curso simultâneo. Essa flexibilidade traz alguns desafios na unificação que serão abordados a seguir. 3.2.1.1 Desafios Técnicos de Unificação A base de dados de destino, Active Directory é, por diversos motivos a forma mais apropriada para armazenamento de informações, o principal deles sendo o fato de já estar implantado um AD para controle de login nos laboratórios. Toda a rede acadêmica, é controlada por políticas de acesso determinadas no AD. Por exemplo: Acesso a máquinas de laboratório, políticas de acesso na rede wifi, mapeamento de dispositivos, permissões de pastas compartilhadas, entre outros. Nesse sentido o AD não é apenas uma base de informações mas um sistema que controla a rede. O objetivo principal é unificar essas políticas e administração entre unidades distintas, posteriormente, a unificação abre margem para autenticação de sistemas importantes para a universidade, que fornecem serviços adicionais. No entanto, ela sofre de limitações que contribuem para complexidade na importação de pessoas e unificação, as limitações identificadas nesse trabalho são:

19 1. Identificação única do objeto. As bases de dados autoritativas distintas devem fornecer um identificador único para a pessoa, isso está fora do controle do sistema. 2. Múltiplos papeis. O active directory possui duas formas básicas de organização e controle: Grupos de usuários - São usados para atribuir permissões de grupo. Um usuário pode ter múltiplos grupos, e um grupo pode conter múltiplos usuários. Organisational Units (OU) - Estrutura hierárquica parecida com pastas de sistema, no qual os usuários são organizados. Um objeto pode estar em apenas uma unidade organizacional. O problema de identificação única poderia ser resolvido através do CPF da pessoa, no entanto, essa é uma informação que fica exposta na rede, descartando-se qualquer número pessoal sigiloso. A única identificação que atende ao requisito de unicidade entre sistemas é o número de pessoa, que é gerado para todos os alunos, professores e funcionários da PUC Minas, não se repete e não conflita entre origens de dados. Também não difere de alunos de professores e funcionários, mesmo que o sujeito tenha vários papeis, seu numero de pessoa não altera. Qualquer outra identificação avaliada pode entrar em conflito gerando o mesmo número para pessoas distintas. Por exemplo, o mesmo número de matrícula de uma aluno pode ser gerado para alunos da Pós graduação, da graduação, para professores e funcionários simultaneamente, identificando quatro sujeitos distintos como sendo a mesma pessoa. O problema então está em como representar um sujeito único no Active Directory, utilizando-se Unidades Organizacionais. Ao utilizar-se de grupos não há problema, pois um mesmo objeto pode conter vários grupos, o que não é verdade no caso de unidade organizacional, que possui apenas uma por objeto. As OU’s são utilizadas para distribuir políticas de segurança chamadas Group Policy Objects (GPO). Elas são importantes para administração da rede e permite executar diversas operações, como mapeamento de recursos compartilhados, restringir ações em máquinas de rede, padronizar configurações de proxy de navegadores, instalar software remoto, entre muitas outras ações. Portanto o estado de um usuário depende de sua localização na hierarquia de OU Para o sistema isso se reflete em dois problemas práticos: 1 Onde mapear os usuários? 2 O que fazer em casos de conflito?

20 Para exemplificar o problema, vejamos como o sistema pode se comportar ao importar um usuário 1234 que é aluno e funcionário ao mesmo tempo. Para isso considerar uma hierarquia hipotética representada na Figura 4

Figura 4 – Estrutura de AD hipotética Fonte: Elaborado pelo Autor Regras aplicadas em uma hierarquia acima refletem em todas abaixo. Se um administrador quiser aplicar uma regra para todas as pessoas de Belo Horizonte, o fará na OU Belo Horizonte, se quiser de um curso específico, fará em cada curso de cada unidade, e assim sucessivamente. No caso do usuário 1234, se o deixarmos na OU de aluno ele perderá todas as restrições e direitos de funcionário na rede, se fizermos o contrário o resultado será o mesmo passando a ter as GPO de funcionário aplicadas e as de aluno esquecidas. Nesse caso, opta-se pela restrição de maior privilégio a de funcionário.

21 Agora vamos supor que ele seja aluno em um curso e professor em outro. Aqui o problema se torna mais grave, pois não importa onde seja alocado ele pode perder acesso a informações importantes. Se for professor, poderia dar aula em Belo Horizonte e Poços de Caldas, movendose entre eles no mesmo dia, como não pode ser representado em mais de um local, ele teria acesso a pastas compartilhadas em um local como professor e perderia em outro. Ao importar usuários, o sistema irá se deparar com essas situações, quando um objeto já existe em outra OU, ele deve tomar decisões que permitam continuar com a operação, mas como visto é impossível manter uma representação da realidade e um login único, manter logins múltiplos para cada cenário é no mínimo, inconveniente para o usuário e vai de encontro ao objetivo de unificação. Não utilizar um mínimo de organização provida pelas OU’s faz a administração da rede extremamente difícil. Não importa qual desenho de hierarquia for feito, sempre haverá problemas. Portanto há um trade off : Quanto mais organizado a estrutura, melhor para aplicação de GPO’s e pior para representar a realidade de usuários. O sistema será modelado para acomodar qualquer estrutura, mas sofrerá forte influencia dela no processo de importação. Para minimizar os problemas sugere-se a hierarquia representada na Figura 5. Nela existe um nível base para o sistema, esse nível separa as operações do sistema de objetos sensíveis do AD como a conta de Administrador geral. Abaixo da OU de sistema existe uma organização de nível razo para Professores, e Funcionários, que não distingue unidade ou curso, isso é necessário pois um mesmo professor está alocado em diversas unidades e cursos simultaneamente. No mesmo nível, há a OU Unidades, onde todos os alunos serão salvos, ela subdividese nas OU’s: Unidade Física (Belo Horizonte, Poços de Caldas, Betim, entre outros), institutos (ICEI, FCA, entre outros) e cursos. Isso permite a aplicação de GPO’s nesses 3 níveis. 3.2.1.2 Forma de comunicação As únicas formas de comunicação disponíveis na escrita desse trabalho são: 1. Através de exportação de arquivos CSV (Comma Separated Values). Essa integração será utilizada inicialmente devido a pressões de projeto. 2. Através de base de dados compartilhada. A comunicação via arquivos possui diversas desvantagens tais como: • Demora - Para exportar os arquivos e importá-los no sistema, um processo burocrático de solicitações é feito, para cada base autoritativa existe uma pessoa responsável

22

Figura 5 – Estrutura de AD sugerida Fonte: Elaborado pelo Autor por gerar o arquivo e um chamado formal deve ser feito. Em alguns casos deve-se explicar o porque do acesso já que os dados pedidos são sensíveis, esses dados são explicados na Tabela 2. Esse processo leva dias. • Falta de sincronia. Por ser um processo com intervenção manual, está sujeita a demora na sincronia não importando o quão disciplinado sejam as pessoas responsáveis e o quão rápido seja a obtenção do arquivo. A burocracia envolvida só agrava a situação. • A operação do processo, por natureza em batch, é lenta. Por efetuar muitas conexões no AD e em bases para completar as informações vindas do arquivo (por exemplo: associar o código do curso à um nome), a performance do sistema é baixa.

23 Campo Nome Código de Pessoa Email Papéis

Descrição Nome da pessoa Número de identificação usado no login de usuário O email é principalmente utilizado para fornecer um auto atendimento na troca de senha, de forma segura Cada grupo de usuários tem papéis distintos que devem ser mapeados. Por exemplo: Alunos e professores estão vinculado a cursos, unidades e institutos, funcionários a centros de custos. Essas informações variam conforme a base autoritativa, nem sempre todas as bases fornecem todas as informações Tabela 2 – Dados para importação Fonte: Elaborado pelo Autor

• Segurança limitada - O arquivo passa por diversos indivíduos antes de chegar no destino, podendo ser desviado com ou sem intenção no meio do caminho. Nada impede também de ser manualmente alterado. Para o presente trabalho, será modelado duas soluções para comunicação entre os sistemas. A primeira modelagem utiliza processos em batch e importação via base de dados compartilhada. A segunda modelagem apresenta uma solução com os seguintes critérios: 1. Uma pessoa criada fora do sistema deve ter sua conta habilitada no Active Directory em até 5 min. 2. Eventos emitidos pelos sistemas autoritativos devem ter garantia de entrega, ou seja, 100% dos eventos devem ser eventualmente entregues e processados. Em casos de falha na comunicação os sistemas devem ser capazes de resumir e sincronizar dados com uma janela de até 2 dias. 3. A informação entre os sistemas deve ser protegida contra acesso e modificações indevidas.

3.2.2 Auditoria de operações do sistema Operações efetuadas pelo sistema devem ser auditadas. O sistema deve manter um registro contendo quais operações foram feitas, e qual o usuário que o fez. Existem vários sistemas desenvolvidos e mantidos pela equipe, seria interessante se a auditoria pudesse ser centralizada, e os eventos enviados de cada aplicação gerados e monitorados de forma similar, diminuindo custos de manutenção e de desenvolvimento.

24

3.2.3 Reset de senha Um usuário anônimo deve ser capaz de resetar a sua senha do Active Directory. O envio de email é uma operação com performance cara, pois necessita de conexão de rede com servidor de SMTP (Simple Mail Transfer Protocol). Para cada email uma sessão SMTP é aberta e fechada o que pode demorar alguns segundos, dependendo das condições de rede. Foi levantado a preocupação sobre a performance da operação nos casos em que muitas pessoas tentem trocar suas senhas simultaneamente, fazendo com que a fila de requisições seja grande, já que em uma operação síncrona o servidor executaria uma envio de email por vez. Essa operação deve ser assíncrona e o numero de conexões simultâneas deve ser personalizado

3.2.4 Controle de acesso e seguranca O sistema deve controlar o acesso e as permissões de acesso dos usuários. Foram definidos 4 tipos de usuários: • ROLE_SGL_USER - Para ter acesso de login ao sistema é necessário estar nesse grupo de usuários. Demais grupos herdam as permissões deste. Também separa os usuários normais do Active Directory daqueles com acesso ao sistema, e define uma convenção para demais sistemas (ROLE_NOME_SISTEMA_USER) sendo que NOME_SISTEMA varia para cada sistema desenvolvido na empresa. • ROLE_ANALISTA - Representa todos os usuários com papel de ANALISTA. • ROLE_TECNICO_INF - Representa todos os usuários com papel de Técnico em Informática. • ROLE_TECNICO_ADM - Representa todos os usuários com papel de Técnico Administrativo.

3.3 Fatores Arquiteturais Relevantes A Tabela 3 define e explica cenários que são relevantes para a arquitetura do sistema. Esse fatores serão considerados nas soluções propostas na seção 3.2.4. Fator

Medidas e cenários de qualidade

Variabilidade (flexibilidade atual e evolução futura)

Impacto do fator

Prioridade para sucesso

Dificuldade ou risco

25

Funcionalidade - Aspectos Funcionais do Software Importar pessoas no AD

Deve haver uma integração com sistemas autoritários existentes na empresa

Flexibilidade Atual Os sistemas disponibilizam integração por arquivo, foi combinada com a equipe responsável uma integração por base de dados compartilhada.

Exigido para aceitação do produto.

Alto

Médio

Alto

Média

Alto

Evolução - Um cenário de integração em tempo real pode ser estratégico em alguns anos Auditoria operações

de

Deve ser possível auditar várias aplicações de forma centralizada

Flexibilidade atual A maioria das aplicações foi desenvolvida em Java com Spring Framework, embora haja aplicações em outras linguagens como PHP. Evolução - Aplicações em outras linguagens podem ser adicionadas

26

Reset de senha

Devido a migração da rede, o fluxo de pessoas executando a operação é desconhecido. Foi estipulado um acesso simultâneo máximo de 200 usuários com um service level de 5 min. Ou seja a pessoa deve receber o email dentro de 5min

Flexibilidade Atual - O envio de emails deve ser feito por serviço SMTP de terceiros.

Quando utilizada em tablets ou smarts fones a interface deve ser adaptavel.

Flexibilidade Atual - Sera usado api open source UIKit1 na confeccao das telas.

Alto

Alto

Baixo

Baixo

Alta

Baixo

Evolução - Número de usuário simultâneos tende há diminuir após a mudança da rede. Depois tende há aumentar gradativamente conforme aumento de ingressos na faculdade.

Usabilidade A recuperação de senha deve ser exibida em tablets e smart fones

Evolucao - Nao se aplica. Confiabilidade - Capacidade de Recuperacao

1



27

Resumir operações de importação

Em caso de falhas o sistema deve ser capaz de resumir as operações. O estado do sistema não deve ser inconsistente no caso de falhas

Flexibilidade Atual - Com uma carga em Batch o sistema pode resumir operações e saltar registros onde haja falhas. Evolução - Não se aplica.

Alto

Médio

Alto

Quando uma pessoa ingressa na universidade for cadastrada no sistema, esta deve ter seu acesso a rede acadêmica em até 48 horas.

Flexibilidade Atual - A carga do sistema deve ser feita seguindo recursos e padrões liberados por equipe de terceiros.

Alto

Alto

Alto

Performance Importação pessoas

de

Evolução Devido a quantidade de acessos dependentes do cadastro na rede acadêmica e a centralização de serviços, pode ser de interesse do negócio diminuir esse tempo, tanto para ingressos quanto para egressos.

28

Operação de troca de senha.

Quando uma troca de senha é efetuada pelo sistema, sua propagação deve acontecer em um tempo máximo de 3 minutos.

Flexibilidade Atual - A propagação de operações no Active Directory é feito por recursos próprios do mesmo. A princípio o sistema não efetua nenhum tipo de intervenção ou controle sobre esse aspecto. O sistema opera apenas no AD Master Evolução - Pode ser feito um cadastro de múltiplos Active Directory, para que a operação seja feita no AD mais próximo da pessoa que necessita o acesso, por exemplo, se a troca for feita por um técnico de uma unidade XPTO o AD XPTO é escrito.

Suportabilidade

Médio

Médio

Alto

29

Compatibilidade com navegadores

Segurança

O sistema deve ser compatível com navegadores Firefox 47 e Chrome 52. A tela de recuperação de senhas deve ser compatível com os navegadores Firefox >= 40, Chrome >=45, Internet Explorer >= 9 e Edge >= 21.

Flexibilidade Atual - A maior parte do acesso ao sistema é feito via intranet, sendo um ambiente mais controlado. Evolução - Não se aplica.

Médio

Médio

Baixo

30

Controle de acesso e segurança

De forma similar a auditoria, várias aplicações tem controle de acesso e o mesmo grupo de usuários. Sendo interessante manter um único login e perfis distintos para cada aplicação.

Flexibilidade Atual - Todos os usuários com acesso ao sistema possuem cadastro no Active Directory, podendo ser utilizado como fonte de autenticação.

Médio

Baixo

Baixo

Evolução - Gerenciar os perfis de usuário e acesso as aplicações, fornecer funcionalidades comuns como o cadastro, e reset de senha de forma centralizada.

Tabela 3 – Fatores Arquiteturais Relevantes

3.4 Soluções Arquiteturais e de Design Para cada caso de uso chave e requisito crítico foi projetado uma solução arquitetural. As soluções devem estar em sincronia com o projeto principal.

3.4.1 Importar Pessoas no AD A Tabela 4 apresenta os campos criados na base de dados compartilhada utilizada para comunicação entre os sistemas. A hierarquia do Active Directory será derivada dos campos: nome_curso, nome_unidade, nome_instituto. O campo nome_instituto não existe para todos os registros, nesses casos a classificacao_curso pode ser usada. Gerando a hierarquia prevista na Figura 5.

31 Campo cod_pessoa nome nome_curso papel classificacao_curso e_email nome_unidade nome_instituto data_carga origem_dado id

Descrição Código de Pessoa. Nome da pessoa. Nome do curso. Informa qual o papel da pessoa no curso, valores possíveis são: Professor e Aluno. Classifica o curso em: Graduação, Mestrado, Especialização, Doutorado, etc. Emails cadastrados para pessoa. Pode conter mais de um, sendo separados por ponto e vírgula. Nome da unidade onde o curso se encontra. Nome do instituto relacionado ao curso. Data em que o registro foi criado. A informação pode vir de vários sistemas, esse campo indica de qual sistema o dado originou. Id para registro. Pode ser gerado automaticamente, mas é obrigatório. Tabela 4 – Tabela Compartilhada Fonte: Elaborado pelo autor

Múltiplos registros são criados para a mesma pessoa, se esta possui múltiplos papeis, ou múltiplos cursos. Por exemplo, um professor dando aulas em mais de um curso irá aparecer múltiplas vezes. Para cada curso, será criado um grupo de mesmo nome. Para processar os dados, será criada um processamento em lotes combinado com um agendamento de quando o trabalho deve ocorrer. Foi convencionado que apenas registros com situação regular estarão na tabela, ou seja registros que existam no AD e não existam na tabela significam pessoas que não possuem mais ligação com a universidade, por exemplo: alunos que já formaram. Esses registros devem ser bloqueados ou removidos do AD. Isso representa um problema técnico: O processamento em lote lê cada registro da base e toma uma decisão, no entanto não tem a informação de quais registros existem no AD e não existem na base. Para solucionar esse caso foram levantadas duas opções: 1. Criar dois processamentos em lote. Um para entrada de dados, lendo da base para o AD, outro para remover dados lendo todos os registros do AD e comparando com a base. Essa opção possui uma performance muito baixa e estressa os servidores Active Directory. Por isso, se aplicada, a remoção deve ter um agendamento com intervalos de pelo ao menos uma semana entre eles; 2. Sincronizar a base do AD com a base compartilhada criando outra tabela. Desse modo a base de dados pode ser utilizada para fazer a intercessão dos conjuntos através de operações de join entre as tabelas. A sincronização do AD é uma operação

32

Figura 6 – Classes de apoio. Processo em Batch Fonte: Elaborado pelo autor mais rápida comparada com uma leitura inteira do mesmo. Essa abordagem é mais performática e possibilita tomar decisões antes de fazer operações no AD. Por exemplo, quando um registro permanece igual não há necessidade de nenhuma operação no AD, mas se o email de uma pessoa for atualizado ela pode ter apenas essa informação atualizada. A estrutura para processamento em lote está representada no diagrama de classes da Figura 6. As classes criam processamentos genéricos que podem vir de fonte de dados distintas (arquivo, base de dados, etc) e desacopla o processo linha a linha de sua lógica. A lógica varia e fica na classe PessoaProcessor que implementa a interface Processor. Estruturas como o feedback do processamento, o cancelamento e resumo do mesmo são abstraídas e desacopladas. Seu funcionamento pode ser resumido em alto nível no diagrama de sequência da Figura 7. O processo de importação está representado nas Figuras 8 e 9, que apresentam a sequência de negócios dos componentes envolvidos. Na Figura 8 a exportação e importação acontecem em momentos distintos. No momento da importação o sistema toma decisões para cada registro lido. Para montar o objeto conforme representado no sub-processo da Figura 9, determina-se o Distinguished Name do objeto. Um Distinguished Name é uma palavra única que indica o caminho hierarquico do objeto no Active Directory (Microsoft, Corporation, 2016). Portanto essa operação depende de qual o papel da pessoa e dos cursos associados a ela. Após determinar o Distinguished Name, uma lista de grupos de usuário é criada, sendo cada grupo correspondente ao papel e cursos da pessoa. Também são mapeados os atributos da pessoa (nome, email, etc.). Um objeto então é criado. Esse objeto representa

33

Figura 7 – Diagrama de Sequência. Processo em Batch Fonte: Elaborado pelo autor a pessoa e possui um mapeamento para o objeto do AD, ou seja, pode ser transformado de/para um objeto Active Directory. Além das classes envolvidas, foi criado uma biblioteca para abstrair operações de baixo nível no Active Directory. Essa biblioteca utiliza a linguagem Scala2 , a mesma escolhida para o desenvolvimento da aplicação, delega operações para a biblioteca UnboundID SDK3 . Mais informações na página do projeto em . O agendamento da importação pode ser configurado no sistema conforme Apêndice G.

3.4.1.1 Proposta alternativa Como proposta alternativa a importação via base de dados compartilhada, propõe-se uma comunicação via fila de mensagens. Essa comunicação se dá de forma assíncrona, sem impacto na performance das aplicações envolvidas. Em alto nível pode ser explicada pelas figuras 10 e 11. Na Figura 10, uma alteração de registro é detectada no sistema de origem, essa alteração pode ser: inclusão, alteração, remoção. Essa alteração gera um evento assíncrono que inicia o processo. Um objeto é criado representando o evento, esse objeto pode conter os campos conforme Tabela 5 e pode ser pensado como um delta no estado atual do registro, embora esse delta não precise ser calculado, pois as próprias operações de inclusão, alteração e remoção já possuem as informações suficientes. 2

3

Scala é uma linguagem funcional e orientada a objeto que possui compatibilidade com a Java Virtual Machine, podendo ser utilizada em conjunto com a linguagem Java. Mais informações: atuando como fachada para a mesma, e facilitando o desenvolvimento da aplicação

34

Figura 8 – Processamento em Lote de Importação Fonte: Elaborado pelo autor Recomenda-se que o evento seja criado em formato JSON (JavaScript Object Notation)4 . Depois de criado o evento, o sistema deve enviá-lo para fila. Nos casos em que a rede esteja fora do ar o evento é salvo temporariamente, sendo importante pois um evento perdido representa uma falta de sincronia entre os sistemas. Diversas abordagens podem ser criadas para que a entrega seja garantida. Nesse trabalho não irei aprofundar nessa questão, embora já tenha sido apresentado no processo uma solução simples. 4



35

Figura 9 – Montar Objeto Durante a Importação Fonte: Elaborado pelo autor Quando a comunicação com a fila é restabelecida o sistema recolhe os eventos salvos na base temporária e envia para ela. Diversos dos sistemas de mensagens disponíveis no mercado possuem uma robustez com relação a falhas, fazendo uma persistência temporária automática, replicações, entre outros recursos. O sistema RabbitMQ, utilizado na auditoria de operações possui configurações para diversos desses recursos (RabbitMQ, 2016). A mensagem permanece na fila até que o sistema SGL (Sistema de Gestão de Logins) as retire da fila e processe. Em casos de falha a mensagem é retornada para fila. O processamento da mensagem representado na Figura 11 primeiro determina o tipo de operação: inclusão de novo registro, alteração remoção. Depois cria um plano de execução baseado no tipo e com os atributos do evento, gerando o objeto no AD a ser persistido ou gerando operações. Basicamente representa o fluxo da Figura 9 mas como possui mais informação (tipo de operação) pode cortar caminhos e ser mais eficiente. Em seguida executa o plano de ação, criando, atualizando ou removendo o registro. Importante notar que o sistema de origem pode ser qualquer sistema, inclusive a origem pode ser de multíplos sistemas como é o caso da PUC Minas. Uma sofisticação é necessária no processamento da mensagem: A remoção de um objeto deve ser feita, apenas quando todos os sistemas de origem removerem o objeto.

36

Figura 10 – Fluxo de mensagens de eventos Fonte: Elaborado pelo autor

Figura 11 – Processo de mensagem no sistema de eventos Fonte: Elaborado pelo autor Com esse último detalhe o ciclo de vida de uma pessoa na rede pode ser descrita com o exemplo a seguir, reparar que os eventos são gerados em tempos distintos: Na aplicação de origem A: 1. Um aluno é criado no sistema, nome e código de pessoa são atribuídos; 2. Evento de criação vai para fila;

37 Atributo tipoOperacao atributos

Descrição Determina o que foi feito com o registro, criado, atualizado ou removido. Uma lista de atributos criados ou alterados. a lista deve seguir o conceito chave valor. E conter basicamente os atributos da Tabela 2. Tabela 5 – Proposta de evento Fonte: Elaborado pelo autor

3. Sistema executa um plano de ação que salva objeto no AD, em OU genérica Alunos. Adiciona-os nos grupos corretos. Referência de objeto é incrementada. 1. Pessoa tem turma alocada, um evento de alteração é criado com o nome do curso; 2. Evento de alteração vai para fila; 3. Sistema executa um plano de ação que move objeto para a OU de cursos. Na aplicação de origem B: 1. Pessoa tem sua caixa de email criada; 2. Evento de criação vai para fila; 3. Sistema executa plano que altera o registro da pessoa no AD adicionando o email. 1. Pessoa altera o seu endereço de email; 2. Evento de alteração vai para fila; 3. Sistema executa plano que altera o registro da pessoa. Na aplicação C: 1. Pessoa é contratada como professor. Aplicação gera evento com todas as informações como cursos em que dá aula, etc; 2. Evento de criação vai para fila; 3. Sistema executa plano de ação, movendo registro para OU professores. Adiciona-os nos grupos corretos. Referência de objeto é incrementada. 1. Pessoa é alocada em outras turmas; 2. Evento de alteração vai para fila; 3. Sistema executa plano de ação, adicionando os grupos corretos.

38 1. Contrato como professor acaba; 2. Evento de remoção vai para fila; 3. Sistema executa plano de ação, desfazendo as alterações de aplicação C. Referência de objeto é decrementada. E assim sucessivamente, notar três coisas importantes: 1. Eventos de criação incrementam a referência do objeto. Apenas quando a referência do objeto é zero, uma remoção é feita no AD. A criação de emails não incrementa a referência, ou seja, não conta para manter a pessoa com acesso a rede; 2. As aplicações de origem também podem consumir a fila. O evento de criação de aluno, pode ser redirecionado para a aplicação que cria seu email, que logo em seguida gera novo evento na fila; 3. A ordem dos eventos não importa. Se um evento de alteração chegar primeiro que um de criação o registro será criado. Desse modo pode-se afirmar que não importa quem produz e quem consome na fila, o estado de uma pessoa em todos os sistemas em um determinado tempo é dado pelo conjunto de eventos gerados para este. Aplicações podem ser plugadas e retiradas do ecossistema relativamente com facilidade. Como vantagens temos: Atemporal - Não é preciso sincronia entre a aplicação que gera os dados e a aplicação que os consome; Múltiplos consumidores Permite que múltiplas aplicações consumam os eventos de forma transparente e abre outras possibilidades. Embora não sejam exploradas nesse trabalho; Comunicação quase em tempo real - Não há atraso significativo entre um evento e sua efetivação no sistema. Permitindo casos de negócio em tempo real. É de conhecimento do mercado que sistemas de mensagens podem chegar a latências da ordem dos milisegundos mesmo em condições de grande volume; Escalabilidade - A performance e escalabilidade do sistema é superior; A aplicação de regras de negócio é simplificada - Geralmente, as regras de negócio avaliam apenas o evento para tomar uma decisão, que já tem todas as informações necessárias. Como desvantagens:

39 Infraestrutura Robusta - A infraestrutura também aumenta de complexidade pois deve garantir a eventual entrega da mensagem e ser monitorada com eficiência; Legado - É relativamente mais complexo alterar as aplicações existentes para gerar e consumir eventos na fila.

3.4.2 Auditoria de operações O padrão de mensagem de eventos foi utilizado na implantação do sistema de auditoria. Sendo dividido em 5 (cinco) partes principais: Audit AppClient - O componente AppClient é uma biblioteca utilizada para abstrair a criação de eventos no sistema, utilizando interceptações em Aspect Oriented Programming. Deve ser instalada e configurada em todas as aplicações que forem auditadas. Independente da linguagem utilizada é possível criar essas abstrações, no entanto para o trabalho foi feito uma biblioteca para Java utilizando-se o framework Spring Framework. O objetivo da abstração é apenas gerar os eventos de Auditoria, e publicar na fila de mensagens de forma assíncrona; Fila de mensagens RabbitMQ - Recebe os eventos de todas as aplicações e mantém em uma área intermediária, tratando acesso concorrente e oferecendo boa performance. Qualquer serviço de mensagens poderia ser utilizado, optou-se pelo RabbitMQ 5 pela simplicidade e robustez; Audit MQ Collector - É um processo que fica escutando mensagens novas na fila e as salva permanentemente na base de dados. Se a base estiver fora do alcance as mensagens são mantidas e o processo tenta novamente mais tarde; Audit View - Uma aplicação web para visualizar e filtrar os logs de auditoria; Base de dados Postgresql - Base de dados escolhida para salvar os eventos de auditoria. Os eventos serão salvos em uma tabela relacional, no entando a base Postgresql a partir da versão 9.4 abre a possiblidade de storage no formato JSON. Futuramente o projeto pretende flexibilizar os dados salvos tirando vantagem do formado JSON. Uma sexta parte pode ser mencionada, pois o componente Audit View delega sua autenticação para o servidor Keycloak6 mais informações na subseção 3.4.4. Esses itens podem ser visualizados no diagrama de componentes da Figura 12. O fluxo de auditoria está representado na Figura 13. Nela podemos observar que as aplicações auditadas enviam uma mensagem padrão para a fila, essa mensagem é então coletada e salva permanentemente. 5 6

https://www.rabbitmq.com/ http://keycloak.org

40

Figura 12 – Components para Auditoria Fonte: Elaborado pelo Autor A mensagem padrão deve cumprir o objetivo de identificar os responsáveis e as ações dentro do sistema. Para isso foi padronizado a mensagem disposta na Tabela 6. Essa mensagem deve ser interpretada da seguinte forma (na ordem da tabela): Campo id applicationName userName action

resource.resouceType

resource.resourceId

dateTime securityLevel description

Descrição O id é gerado automaticamente pelo storage. Um identificação da aplicação que gerou o evento. Deve ser único entre as aplicações. auditadas Nome do usuário que executou a ação. Ação executada, define o que aconteceu no sistema, representado por verbos. Deve ser padronizado entre as aplicações auditadas. Representa o tipo de recurso afetado pela ação, representada por sujeitos. Exemplos: pessoa, ordem de serviço, mensagem. Identificação para o recurso afetado. Múltiplos valores devem ser separados com “;”. Exemplos “1234”, “1234;456” Quando a ação foi executada. Uma forma de classificar a segurança do evento. Suporta apenas 3 valores: LOW, NORMAL, HIGHT. Uma descrição opcional para o evento. Tabela 6 – Evento de Auditoria Padrão Fonte: Elaborado pelo Autor

SGL - fooUser - ldap_enable - person - 123 - Sat May 21 08:14:59 10.0.1.1 - NORMAL - Habilitando usuário no AD. Que significa:

41

Figura 13 – Fluxo de Auditoria Entre Componentes Fonte: Elaborado pelo Autor O usuário fooUser executou a ação ldap_enable em uma person (pessoa) de identificação 123 na data Sat May 21 08:14:59, o usuário estava logado no ip 10.0.1.1, a segurança dessa operação é NORMAL, a operação é descrita como Habilitando usuário no AD.

3.4.3 Reset de senha A Figura 14 apresenta as classes principais que colaboram para o caso de uso reset de senha e em conjunto com a Figura 15 representa como a solução foi projetada. Conforme o fluxo da Figura 15, um usuário solicita a recuperação de senha no sistema, passando sua identificação (codigoPessoa) e um captcha captchaResponse, o sistema valida o captcha e o código de pessoa, então envia para o email da pessoa um link contendo um código de confirmação (Token). Com o Token é possível escolher uma nova senha que é trocada, o token é removido da base. O Token é válido se existir e foi criado em menos de 24 horas.

42 Um evento de auditoria é criado quando o sistema cria o token e quando a senha é modificada.

Figura 14 – Diagrama de classes: Troca de Senha Fonte: Elaborado pelo Autor O envio de emails, e a publicação de eventos são feitas de forma assíncrona. Foi criado um serviço a parte do sistema, para o envio de emails. Esse serviço foi criado por ser uma atribuição comum dos sistemas desenvolvidos, sendo portanto reaproveitável e de configuração centralizada. Além de poder ter hardware escalável de forma independente. O serviço utiliza o padrão REST (Representational State Transfer) para ser invocado, e delega o envio para um servidor SMTP. Para assegurar uma boa performance, o serviço cria um Thread Pool capaz de enviar um numero configurável de emails simultâneos e de mensagens em fila. Acima do número máximo de conexões na fila, um erro é retornado para o requisitante. Testes apontam que o serviço é capaz de entregar uma média de 1.61 emails/segundo usando 10 entregas simultâneas. Esse cálculo inclui o tempo de entrega do servidor SMTP utilizado nos testes. Ao aumentar o número de Threads de entrega, o servidor cria mais requisições SMTP

43

Figura 15 – Diagrama de sequência: Troca de Senha Fonte: Elaborado pelo Autor

44 simultâneas, no entanto o servidor SMTP deve enfileirar e entregar em um ritmo próprio, ou seja o número de entrega simultâneas deve ser ajustado para capacidade do serviço de SMTP, não sendo vantajoso manter um número alto. Em outras palavras, nos testes, aumentar o numero the Threads diminuiu a fila do servidor de mensagens mais rapidamente, mas sobrecarregou o serviço de SMTP que fez uma entrega final pior em alguns casos, como nos testes com 100 e 200 emails da Tabela 8. Não foi mensurado o tempo em que as mensagens são entregues na fila, ou seja o tempo que o sistema entrega para SMTP. Essa informação é baseada na percepção durante os testes. A metodologia de teste foi executada da seguinte maneira: 1. O software Apache HTTP server benchmarking tool 7 foi utilizado para gerar dois casos de testes, um com 10 (dez) clientes simultâneos e 10 conexões de entrega simultânea, outra com 10 (dez) clientes simultâneos e 50 conexões de entrega simultânea. Cada caso de teste foi combinado com os números de requisições: 10, 100, 200, 500; 2. Foi mensurado o numero de errors e de respostas do serviço; 3. Foi mensurado o tempo gasto para que todos os emails chegassem na caixa postal, verificando-se a data do último email. Existe uma limitação que faz os resultados não serem precisos, pois as mensagens não são bem ordenadas no servidor de recebimento, nem mesmo nos clientes de email que seguem a ordem que o servidor diz receber a mensagem. Isso acontece provavelmente porque o servidor recebe a mensagem mas pode processá-la (para verificar spam por exemplo) antes de entregar na interface. Isso faz com que o teste tenha uma margem de erro. Para o teste foi utilizado a data e hora no cabeçalho original da mensagem que diz quando o último servidor de email recebeu a mensagem conforme exemplo no Apêndice D. O resultados foram compilados nas Tabela 7 e Tabela 8, os tempos de teste e de entrega estão mensurados em segundos. Requisições/Emails 10 100 200 500

Temp. Teste 0.009s 0.055s 0.08s 0.185s

Falhas REST 0 0 0 0

Falhas Email 0 0 2 0

Temp. Entrega 18s 132s 281s 877s

Tabela 7 – Testes de envio de email 10 clientes simultâneos, 10 Threads de Entrega Fonte: Elaborado pelo autor 7



45 Requisições/Emails 10 100 200 500

Temp. Teste 0.06s 0.058s 0.08s 0.186s

Falhas REST 0 0 0

Falhas Email 0 0 5 10

Temp. Entrega 17s 467s 546s 409

Tabela 8 – Testes de envio de email 10 clientes simultâneos, 50 Threads de Entrega Fonte: Elaborado pelo autor Dessa forma conclui-se que o servidor pode ser ajustado para atender a demanda máxima de pico de 200 usuários simultâneos com tempo de entrega máximo de 5min, levantados na seção 3.3. O tempo de resposta para o cliente do serviço é muito baixo em todos os testes, isso se reflete em um tempo de resposta para a solicitação de troca de senha baixo. Conforme visto na Tabela 8 o envio de 500 mensagens, do ponto de vista de quem requisitou, demorou 186 milisegundos. A configuração dos parâmetros do sistema escolhida estão no Apêndice F.

3.4.4 Controle de acesso e segurança Parar cumprir o requisito de autenticação centralizada, as aplicações utilizaram o padrão OAuth2 8 para delegar a um componente controlador central de autenticidade. Esse componente será o servidor Keycloak 9 . Segundo o site oficial Red Hat, Inc (2016): Keycloak é uma solução de código livre para gerenciamento de acesso e identidade focada em aplicações e serviços modernos. Torna fácil prover segurança em aplicações e serviços com pouco ou até mesmo nenhum código. 10

O servidor Keycloak pode autenticar em diversos repositórios de dados, funcionando como um gateway de autenticação. Seguindo-se o protocolo OAuth2 (HARDT, 2012). Após ser autenticado a pessoa obtém um token de segurança, que é utilizado para identificá-la. Esse token também pode ser criptografado e conter informações como grupos de usuários, nome da pessoa, entre outros. Também possui integração oficial com o framework Spring Framework 11 e seu componente de segurança Spring Security 12 , sendo este utilizado para desenvolver a aplicação. Portanto facilitando o desenvolvimento da mesma. 8 9 10

11 12

Keycloak is an open source Identity and Access Management solution aimed at modern applications and services. It makes it easy to secure applications and services with little to no code.

46 O fluxo de autenticação do protocolo OAuth2 está representado na Figura 16

Figura 16 – Fluxo de Autenticação Fonte: Elaborado pelo Autor

3.4.5 Implantação Conforme apresentado no trabalho, a aplicação é composta de diversos componentes, muitos deles reaproveitáveis. Sugere-se a separação desses componentes em servidores distintos para a máxima performance e disponibilidade do sistema, conforme Figura 17. Em ambientes de computação em nuvem a alocação desses ambientes é transparente, e não necessariamente utiliza-se servidores físicos, ficando a critério do administrador do sistema a alocação dos recursos, que deve considerar outros fatores como custo. Em casos onde queira-se minimizar os custos, mas manter uma boa separação dos dados. Recomenda-se a implantação ilustrada na Figura 18, onde há servidores distintos apenas para autenticação, fila de mensagens, servidor de emails, e base de dados.

3.4.6 Visão Geral Para facilitar o entendimento do sistema e sua posição dentro da Universidade foi elaborado o diagrama da Figura 19. Nele é possível observar o Sistema de Gestão de Logins de verde no centro, e ao seu redor, todos os sistemas, redes e stakeholders que interagem direta ou indiretamente com ele. Notar que o stakeholder Funcionário não está no diagrama por ter sua importação de usuários removida do escopo do projeto.

47

Figura 17 – Diagrama de Implantação Fonte: Elaborado pelo Autor

48

Figura 18 – Diagrama de Implantação Enxuta Fonte: Elaborado pelo Autor

49

Figura 19 – Visão Geral Fonte: Elaborado pelo Autor

4 Conclusão Durante o desenvolvimento do projeto, houve a preocupação em reaproveitamento de sistemas. Nessa linha, foram utilizados e desenvolvidos serviços para um ecossistema comum de aplicações. Sendo eles: • Autenticação Central; • Envio de emails; • Auditoria Central. Esses serviços trazem benefícios para o setor, e para os usuários finais. Ao final do trabalho espera-se que os objetivos gerais e específicos tenham sido alcançados, em especial a integração em um portal de sistemas. E que com o tempo, tais aplicações possam evoluir para uma plataforma de sistemas pensada em conjunto, e não mais projetos isolados sem qualquer ligação. Cada componente em si tem simplicidade variada, deste simples a complexa, mas em conjunto demostram coesão, baixo acoplamento e uma capacidade de evolução e de agregação de valor considerável. Como vantagens da abordagem apresentada pode-se citar, dentre outras: • Usuários finais possuem apenas uma senha, a segurança pode ser fortalecida utilizandose autenticação em duas etapas 1 ; • Os usuários finais vêem um conjunto coeso de aplicações, a administração e delegação é simplificada; • Aplicações desenvolvidas não precisam se preocupar em como enviar emails. Gráficos e estatísticas podem ser gerados; • A auditoria das aplicações é facilitada, segura e robusta; • A adição de serviços comuns beneficia diversas aplicações, economizando tempo; • A performance pode ser melhor ajustada conforme a natureza do serviço. Como desvantagens podemos citar: • Uma maior complexidade de implantação; 1

Um artigo sobre o tema pode ser lido two-factor-authentication-what-you-need-to-know-faq/>

em

${ f i l e } . l o g echo " Terminado em " ‘ date ‘ >> ${ f i l e } . l o g echo " F i n i s h e d i n " ‘ date ‘ O arquivo email-post.data contém as informações para serem enviadas junto a requisição: to=email%40exemplo.com&message=corpo+do+email&token=9b932efc-31d5-44d0-8c6a45b41729651a&subject=ab+test

APÊNDICE D – Mensagem Original de Email D e l i v e r e d −To : xxx@atende . i n f o R e c e i ve d : by 1 0 . 1 7 6 . 1 . 2 2 with SMTP i d 22 csp879398uak ; Sat , 1 Oct 2016 1 0 : 3 9 : 4 4 −0700 (PDT) X−R e c e i ve d : by 1 0 . 2 0 0 . 3 5 . 1 1 7 with SMTP i d b50mr7464740qtb . 3 8 . 1 4 7 5 3 4 3 1 9 2 9 3 5 ; Sat , 01 Oct 2016 1 0 : 3 3 : 1 2 −0700 (PDT) Return−Path : R e c e i ve d : from na01−bn1−obe . outbound . p r o t e c t i o n . o u t l o o k . com ( mail−bn1bn0103 . outbound . p r o t e c t i o n . o u t l o o k . com . [157.56.110.103]) by mx . g o o g l e . com with ESMTPS id g9si16140123qtg . 9 0 . 2 0 1 6 . 1 0 . 0 1 . 1 0 . 3 3 . 1 2 f o r ( v e r s i o n=TLS1_2 c i p h e r=ECDHE−RSA−AES128−SHA b i t s =128/128); Sat , 01 Oct 2016 1 0 : 3 3 : 1 2 −0700 (PDT) Received−SPF : p a s s ( g o o g l e . com : domain o f xxx@pucminas . br d e s i g n a t e s 1 5 7 . 5 6 . 1 1 0 . 1 0 3 as p e r m i t t e d s e n d e r ) c l i e n t −i p = 1 5 7 . 5 6 . 1 1 0 . 1 0 3 ; A u t h e n t i c a t i o n −R e s u l t s : mx . g o o g l e . com ; s p f=p a s s ( g o o g l e . com : domain o f xxx@pucminas . br d e s i g n a t e s 1 5 7 . 5 6 . 1 1 0 . 1 0 3 as p e r m i t t e d s e n d e r ) smtp . mailfrom=xxx@pucminas . br A u t h e n t i c a t i o n −R e s u l t s : s p f=none ( s e n d e r IP i s ) smtp . mailfrom=xxx@pucminas . br ; R e c e i ve d : from 1 9 2 . 1 6 8 . 1 . 1 0 ( 1 7 9 . 2 3 6 . 6 7 . 1 0 3 ) by SC1PR80MB1902 . lamprd80 . prod . o u t l o o k . com ( 1 0 . 1 7 5 . 1 9 9 . 1 4 8 ) with M i c r o s o f t SMTP S e r v e r ( v e r s i o n=TLS1_2 , c i p h e r=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) i d 1 5 . 1 . 6 3 9 . 5 ; Sat , 1 Oct 2016 1 7 : 3 3 : 0 9 +0000 Date : Sat , 1 Oct 2016 1 4 : 3 2 : 5 5 −0300 From : To :

58 Message−ID :

APÊNDICE E – Configurações do Sistema Todo parâmetro de configuração do sistema listado no trabalho pode ser customizado por variáveis de ambiente ou por linha de comando. Por exemplo a chave para configurar o captcha é sgl.recaptcha.siteKey, que ficaria: • Variável de ambiente: SGL_RECAPTCHA_SITEKEY • Linha de comando: –sgl.recaptcha.siteKey=bla

APÊNDICE F – Parâmetros de configuração de email O serviço de email pode ser configurado com os parâmetros: async.corePoolSize Número de Threads async.maxPoolSize Número máximo de Threads. Se o numero máximo da fila queueCapacity for atingido, novas threads serão criadas até esse limite, quando a fila diminui elas são removidas async.queueCapacity Número máximo de requisições para fila de Threads. Após atingir o esse número novas requisições são negadas, a não ser que o existam Threads livres. Para o nível de serviço do sistema, foi utilizado a configuração a seguir:

async . c o r e P o o l S i z e =10 async . maxPoolSize=10 async . queueCapacity =200 Mais informações na documentação do projeto

APÊNDICE G – Configuração de Agendamento de Importação Para configurar quando a importação deve acontecer. Utilize o parâmetro sgl.cron. Exemplo: s g l . cron=0 0 22 ∗/2 ∗ ∗ Padrão: 0 0 22 */2 * * O padrão acima significa rodar as 22:00 horas a cada dois dias. Para mais informações veja