Biblioteca Digital do IPG: Projeto em contexto de estágio - Armis Group (Porto)

(1)

IREI

Polylechnic of Guarda

RELATÓRIO DE PROJETO

Licenciatura em Engenharia Informática

Diogo Francisco Comes Pinheiro

setembro

₁

2019

.4

(2)

Escola Superior de Tecnologia e Gestão

Instituto Politécnico da Guarda

R E L A T Ó R I O D E P R O J E T O E M

C O N T E X T O D E E S T Á G I O

DIOGO PINHEIRO

RELATÓRIO PARA A OBTENÇÃO DO GRAU DE LICENCIADO EM ENGENHARIA INFORMÁTICA

(3)

i

Agradecimentos

Queria começar por agradecer aos meus pais, irmão e restante família por me terem proporcionado esta oportunidade e por toda a ajuda que me deram ao longo da vida. Um agradecimento ao meu orientador, Doutor José Carlos Fonseca, por toda a disponibilidade mostrada ao longo deste trabalho e por todas as sugestões que tornaram este trabalho o melhor possível.

Um agradecimento especial à entidade de acolhimento, Armis Group, por me ter dado a oportunidade de trabalhar como estagiário numa área completamente nova, pelo conhecimento que me transmitiu e por todo o acolhimento que me proporcionaram ao longo deste estágio.

Agradeço também aos meus amigos, que desde sempre acreditaram e estiveram presentes quando eu precisei, para me dar força, ânimo e por todos os momentos que me proporcionaram ao longo destes últimos anos.

Por fim, agradeço á minha namorada, que esteve sempre presente para me dar força, ânimo, motivação, por nunca me deixar desistir, transmitindo-me sempre todo o apoio, paciência e amor.

(4)

(5)

iii

Ficha de identificação | Elementos Identificativos

Aluno

Nome: Diogo Francisco Gomes Pinheiro

Número: 1012171

Curso: Engenharia Informática

Estabelecimento de Ensino

Escola Superior de Tecnologia e Gestão – Instituto Politécnico da Guarda

Morada: Av. Dr. Francisco Sá Carneiro 50, 6300-559 Guarda

Telefone: 271220120 Fax: 271220150

Entidade de Acolhimento

Armis Group

Morada: Rua do Freixo 725, 4300-217, Porto

Telefone: 226002295

Duração do Projeto em Contexto de Estágio

Início: 15 de Julho de 2019

Fim: 2 de Setembro de 2019

Orientador do Projeto (Estabelecimento de Ensino)

Nome: José Carlos Fonseca

Grau Académico: Doutor

Orientador do Projeto (Entidade de Acolhimento)

(6)

(7)

v

Resumo

O presente documento tem como objetivo relatar o trabalho realizado no projeto em contexto de estágio realizado na empresa Armis Group, na área de segurança.

Este consistiu no desenvolvimento de uma aplicação web para dar suporte à criação e gestão de perfis de negócio. Ela é capaz de examinar identidades existentes, atributos de identidade e as respetivas permissões de cada utilizador através do processo de Role Mining, de forma a encontrar padrões relativos ao acesso e funções de cada um. Estas funcionalidades permitem definir as funções que cada utilizador deverá ter quando registado no sistema.

O objetivo final deste projeto em contexto de estágio foi obter uma gestão de segurança otimizada baseada na função que cada colaborador desempenha dentro da organização. Devido ao curto espaço de tempo do estágio, o objetivo deste projeto não era a implementação completa desta plataforma, mas sim apenas uma versão funcional, prevendo-se que fique completamente desenvolvida em dezembro do corrente ano.

Palavras-chave: Gestão de Perfis, Role Mining, AngularJS, ASP.NET, MSSQL Server,

(8)

(9)

vii

Abstract

This document aims to report all the work done on the project carried out at Armis Group, in the area of security.

This project aimed to develop a web application that supports the creation and management of business profiles. It is capable of examining existing identities, identity attributes and respective permissions of each user through the process of Role Mining in order to find patterns regarding access and roles. These features allow you to define the roles that each user should have when registered in the system.

The ultimate goal of this internship was to achieve optimized security management based on the role that each employee plays within the organization.

Due to the short timeframe of the internship, the objective of this project was not the full implementation of this platform, but only a functional version of it, which is expected to be fully developed in December this year.

Keywords: Identity Management, Role Mining, AngularJS, ASP.NET, MSSQL Server, PowerBI

(10)

Relatório de Estágio

viii

Índice geral

Agradecimentos ... i

Ficha de identificação | Elementos Identificativos ... iii

Resumo ... v

Abstract ... vii

Índice de Figuras ... xiii

Índice de Tabelas ... xv

Lista de siglas e acrónimos ... xvii

1 Introdução ... 1

1.1 Caraterização sumária da instituição ... 1

1.2 Motivação ... 2 1.3 Descrição do problema ... 2 1.4 Objetivos ... 3 1.5 Plano de estágio ... 4 1.6 Estrutura do documento ... 5 2 Estado de Arte ... 7 2.1 Gestão de Identidades ... 7 2.2 Role Mining ... 8 2.3 Trabalhos relacionados ... 8 2.3.1 Oracle... 10 2.3.2 Microsoft ... 11 2.3.3 Okta ... 12 3 Metodologia ... 13 3.1 Metodologia Scrum ... 13

(11)

ix

4 Análise de Requisitos ... 17

4.1 Diagrama de Contexto ... 17

4.2 Diagrama de Casos de Uso ... 18

4.3 Atores e respetivos Casos de Uso ... 19

4.4 Descrição dos Casos de Uso ... 21

4.4.1 Descrição do Caso de Uso “Inserir Aplicação” ... 21

4.4.2 Descrição do Caso de Uso “Consultar Aplicação” ... 22

4.4.3 Descrição do Caso de Uso “Editar Aplicação” ... 23

4.4.4 Descrição do Caso de Uso “Eliminar Aplicação” ... 24

4.4.5 Descrição do Caso de Uso “Importar CSV Aplicações” ... 25

4.4.6 Descrição do Caso de Uso “Atribuir funções ao utilizador” ... 25

4.4.7 Descrição do Caso de Uso “Remover funções ao utilizador” ... 26

4.5 Diagrama de Classes ... 27 4.6 Semântica de Classes ... 29 5 Tecnologias ... 31 5.1 AngularJS ... 31 5.1.1 Padrão MVC ... 31 5.1.2 Conceito SPA ... 32

5.1.3 Two-Way Data Binding ... 33

5.1.4 Injeção de dependências ... 34

5.1.5 Recursos de Diretiva ... 35

5.2 ASP.NET Core ... 37

5.3 Microsoft SQL Server ... 37

5.4 SQL Server Management Studio ... 37

5.5 Microsoft Power BI ... 38

5.6 Postman ... 38

(12)

Relatório de Estágio x 5.8 IIS ... 40 6 Implementação... 41 6.1 Base de dados ... 41 6.1.1 Modelo Entidade-Relacionamento ... 41 6.1.2 Triggers ... 43 6.2 Implementação do Back-end ... 44

6.2.1 Implementação do módulo “Applications” ... 44

6.2.2 Implementação do módulo “RM_Application” ... 46

6.3 Interfaces da Plataforma (Front-end) ... 46

6.3.1 Dashboard ... 47 6.3.2 Role Mining ... 48 6.3.2.1 Visualização de dados ... 49 6.3.2.2 Inserção de dados ... 50 6.3.3 Gestão de Perfis ... 51 6.3.3.1 Applications ... 51

6.3.3.1.1 Criação de uma aplicação ... 51

6.3.3.1.2 Importação de ficheiros ... 52

6.3.3.1.3 Eliminação de aplicações ... 52

6.3.3.1.4 Visualização das aplicações ... 52

6.3.3.1.5 Visualização dos detalhes ... 53

6.3.3.2 Repositories ... 55

6.3.3.3 Application Roles ... 56

6.3.3.4 Autenticação e Autorização ... 56

6.4 Implementação da PGPN num servidor da Armis, via IIS ... 57

7 Verificação e Validação... 58

7.1 Role Mining ... 58

(13)

xi

7.2.1 Verificações ao criar e editar elementos ... 60

7.2.2 Verificação ao eliminar elementos ... 62

8 Conclusões ... 64 Referências ... 66 Anexos ... 70 Anexo A1 ... 71 Dicionário de Dados ... 71 Classe Application ... 72 Classe Repository ... 73

Classe Application Role ... 74

Classe User ... 76

Classe Structure ... 78

Classe Functional Role ... 79

Classe Entitlement ... 80 Classe Structure_User ... 81 Classe FunctionalRole_User ... 82 Classe FunctionalRole_ApplicationRole ... 83 Classe RM_Application ... 84 Classe RM_ApplicationRole ... 85 Classe RM_Repository ... 86 Classe RM_User ... 87 Classe RM_Structure ... 89 Classe RM_Entitlement ... 90 Classe RM_Structure_User ... 91 Anexo A2 ... 92 Base de Dados ... 92

(14)

xii

Trigger Application Role Logs ... 95

Trigger User Logs ... 97

Trigger Reposiory Logs ... 100

Trigger Structure Logs... 102

Trigger Functional Role Logs ... 104

Trigger FunctionalRole_ApplicationRole Logs ... 106

Trigger FunctionalRole_User Logs ... 108

Trigger Entitlement Logs... 110

Trigger Structure_User Logs ... 112

Anexo A3 ... 114

Interfaces da plataforma ... 114

Interface Users ... 115

Interface Structures ... 116

(15)

xiii

Índice de Figuras

Figura 1 – Logótipo Armis Group ... 2

Figura 2 - Mapa de Gantt do plano de estágio ... 5

Figura 3 – Magic Quadrant for Acess Managment 2019 ... 9

Figura 4- Diagrama : Okta vs Office365 ... 12

Figura 5 - Processo Srum ... 13

Figura 6 - Diagrama de Contexto ... 17

Figura 7 - Diagrama Casos de Uso ... 18

Figura 8 - Diagrama de Classes da Plataforma (Gestão de Perfis) ... 28

Figura 9 - Diagrama de Classes da Plataforma (Role Mining)... 29

Figura 10 – Logótipo AngularJS ... 31

Figura 11 - Camadas Modelo MVC ... 32

Figura 12 - Diferença entre SPA e Multi Page ... 33

Figura 13 - Fluxograma Two Way Data Binding ... 34

Figura 14 - Dependências entre classes ... 35

Figura 15 - Diretivas do AngularJS ... 36

Figura 16 - Diferentes plataforma do Power BI ... 38

Figura 17 - Interface do Postman ... 39

Figura 18 - Modelo Entidade-Relacionamento (Gestão de Perfis)... 42

Figura 19 - Modelo Entidade-Relacionamento (Role Mining) ... 43

Figura 20 – Controlador da classe Application ... 45

Figura 21 – Modelo da classe Application ... 46

Figura 22 – Interface “Dashboard” ... 48

Figura 23 – Interface “Role Mining” ... 49

Figura 24 - Método para a obtenção dos dados das "Applications" ... 50

Figura 25 - Esboço do ficheiro HTML Role Mining ... 50

Figura 26 – Interface “Applications”... 51

Figura 27 – Pop-up “Create Application” ... 52

Figura 28 - Interface "Application Details" ... 53

Figura 29 - Modal "Modify Application” ... 54

Figura 30 - Interface "Repository" ... 55

(16)

xiv

Figura 32 – Interface “Application Role Details” ... 56

Figura 33 – Pop-up “Erro ao inserir CSV” ... 59

Figura 34 – Erro ao criar uma aplicação... 60

Figura 35 - Código da validação ao inserir campos existentes... 61

Figura 36 – Mensagem de erro ao modificar uma aplicação ... 61

Figura 37 – Mensagem de erro ao eliminar elementos ... 62

(17)

xv

Índice de Tabelas

Tabela 1 - Atores e respetivos casos de uso ... 19

Tabela 2 - Descrição do caso de uso "Inserir Aplicação" ... 21

Tabela 3 - Descrição do caso de uso "Consultar Aplicação" ... 22

Tabela 4 - Descrição do caso de uso "Editar Aplicação" ... 23

Tabela 5 - Descrição do caso de uso "Eliminar Aplicação" ... 24

Tabela 6 - Descrição do caso de uso "Importar csv Aplicações" ... 25

Tabela 7 - Descrição do caso de uso "Atribuir funções ao utilizador" ... 25

Tabela 8 - Descrição do caso de uso "Remover funções ao utilizador" ... 26

(18)

(19)

xvii

Lista de siglas e acrónimos

AD - Active Directory

API - Application Programming Interface BI - Business Intelligence

CD - Continuous Deployment CI - Continuous Integration

CRUD - Create Read Update Delete DOM - Document Object Model FTP - File Transfer Protocol

HTML – Hyper Text Markup Language IAM - Identity and Access Management IIS - Internet Information Services IPG – Instituto Politécnico da Guarda

ISEP – Instituto Superior de Engenharia do Porto IT – Information Technology

ITS - Intelligent Transport Systems MIM - Microsoft Identity Manager MSSQL - Microsoft SQL

MVC - Model View Controller OAM - Oracle Access Manager OIM - Oracle Identity Manager ORM - Oracle Role Manager

PGPN – Plataforma de Gestão e Perfis de Negócio TI – Tecnologias da Infomação

(20)

xviii REST - Representational State Transfer

SGBDR - Sistema de Gestão de Base de Dados Relacional SOAP - Simple Object Acess Protocol

SPA - Single Page Application SQL - Structured Query Language SSO - Single Sign-On

UML - Unified Modeling Language

(21)

1

1 Introdução

O presente documento, descreve, no âmbito da Unidade Curricular (UC) Projeto de Informática do 3º ano da licenciatura de Engenharia Informática, lecionada na Escola Superior de Tecnologia e Gestão (ESTG) do Instituto Politécnico da Guarda (IPG), a realização do projeto em contexto de estágio decorrido na empresa Armis.

Este projeto teve uma duração de 280 horas, e nele é desenvolvida uma solução na área de Segurança para ser usada em clientes da Armis, designada “Plataforma de Gestão de Perfis de Negócio” (PGPN). Esta é uma plataforma web capaz de fazer a gestão e criação de identidades dentro de uma organização.

Este projeto é motivado pelo facto de contribuir para a resolução de um problema recorrente, que é a segurança nas organizações, mais concretamente a gestão de identidades e acesso. A gestão de identidades é um processo organizacional que permite definir uma identidade digital para cada entidade (pessoas, hardware, processos) associando determinados atributos a essa identidade. De forma resumida, esta tem como objetivo controlar o acesso dos colaboradores, a fim de evitar vazamento de informações confidenciais.

1.1 Caraterização sumária da instituição

De acordo com a Armis (Armis, 2018), esta foi fundada em 2005, com sede na cidade do Porto sendo uma entidade de vanguarda na área de TI (Tecnologias e Informação). Atualmente tem escritórios nas cidades do Porto, Lisboa, São Paulo (Brasil) e Macau (China), podendo contar com cerca de 130 colaboradores e a existência de vários projetos internacionais em países como o Egito, Rússia, Espanha, Angola e Irlanda.

Como indica o nome Armis, derivado da palavra em Latim e inspirado na força e determinação dos guerreiros, tem como principal objetivo oferecer as melhores soluções tecnológicas aos clientes. Para que tal seja possível e de modo a responder às especificidades de cada projeto e negócio, a Armis é composta por 4 grupos:

(22)

2 • Armis IT – desenvolve soluções à medida do cliente como Portais, Aplicações Mobile, Business Intelligence, Segurança e Gestão de Identidades, Testes e Certificação de Software.

• Armis ITS (Intelligent Transport Systems) - desenvolve soluções inteligentes na área de transportes.

• Armis Digital Sport - tem foco na conceção de soluções digitais especializadas na indústria desportiva.

• Armis Sourcing - presta serviços de Sourcing através da alocação de recursos especializados aos nossos clientes.

Na Figura 1, podemos ver o logótipo da Armis Group.

1.2 Motivação

A principal motivação na realização deste projeto, foi a oportunidade de frequentar um estágio num ambiente empresarial, numa empresa de desenvolvimento de software que me permitisse desenvolver grandes capacidades tanto a nível técnico, como a nível pessoal, como foi o caso da Armis.

Outro fator de grande importância, foi a possibilidade de trabalhar numa área ao mesmo tempo muito relevante e que eu desconhecia, que é a Gestão de Identidades. Isso tornou este desafio ainda mais incentivante pela necessidade de aprendizagem de novos conceitos e trabalhar com novas ferramentas num ambiente real de desenvolvimento.

1.3 Descrição do problema

De modo a melhorar a segurança nas organizações de TI, a Armis decidiu implementar uma solução de identificação de padrões para simplificar e automatizar o controlo de

(23)

3 acessos dentro da organização bem como, a leitura de dados referentes às funções dos utilizadores na organização.

De forma resumida, esta solução terá de ser capaz de fazer toda a gestão e criação de identidades (identificação digital atribuída a uma entidade) dentro de uma organização, permitindo aos gestores inicialmente analisar os mapeamentos de cada colaborador com os recursos que o mesmo tem acesso, através do processo de Role Mining, possibilitando assim uma melhor análise das identidades existentes. Após esta análise, estes podem prosseguir com a criação e gestão de identidades.

Esta solução pode trazer vários benefícios para as organizações de TI, sendo eles: • A diminuição de custos administrativos, reduzindo a carga atual colocada na área

de TI;

• O aumento da produtividade e da eficiência. Quanto mais rápido o colaborador obtiver acesso aos recursos necessários, mais cedo pode tornar-se produtivo; • Melhoria da qualidade e precisão, reduzindo a entrada de dados manualmente

propensa a erros pelos administradores de sistemas, ou qualquer outro tipo de interveniente manual no processo, e uma maior precisão na atribuição de acessos consoante a função a desempenhar;

• Melhoria da segurança, garantindo aos colaboradores o acesso aos recursos certos no momento certo, permitindo assim uma colaboração segura em toda a organização;

• Melhoria da privacidade, atribuindo automaticamente os direitos de acesso corretos para contas de utilizador.

1.4 Objetivos

O objetivo principal é a criação de uma plataforma web de Gestão e Criação de Perfis de Negócio, analisando os mapeamentos de cada utilizador com cada recurso que o mesmo tem acesso através do processo de Role Mining, agilizando desta forma o processo de modificação de permissões numa organização. Estes mapeamentos serão visualizados numa Dashboard feita através do Microsoft Power BI (Business Intelligence).

(24)

4 Esta solução tem como intuito examinar identidades existentes, atributos de identidade e respetivas permissões de cada utilizador. Após a identificação dos padrões dá-se seguimento à criação e gestão de identidades.

A criação desta plataforma ficou a cargo de uma das equipas de desenvolvimento da área de segurança. Esta equipa era constituída por 4 elementos sendo eles os seguintes:

• Francisco Falcão: Gestor de projetos;

• André Rodrigues: Estagiário do ISEP (Instituto Superior de Ensino do Porto) / Programador Júnior;

• Diogo Pinheiro: Estagiário do IPG; • Vanderley Quaresma: Estagiário do IPG.

1.5 Plano de estágio

Em baixo encontram-se todas as fases do planeamento relativas ao projeto.

1. Etapa (15/07 – 29/07): Fase de adaptação na empresa e realização de testes de modo a avaliar as habilidades dos estagiários;

2. Etapa (29/07 – 31/07): Preparação do ambiente (desenho da base de dados de perfis e preparação do ambiente de desenvolvimento);

3. Etapa (01/08 – 14/08): Implementação do back-end; 4. Etapa (15/08 – 30/08): Implementação do front-end;

(25)

5 Na Figura 2 é apresentado o mapa de Gantt correspondente ao plano estágio.

1.6 Estrutura do documento

Este documento é constituído por oito capítulos, que a seguir se descrevem.

No capítulo 1, Introdução, encontra-se uma breve descrição da instituição de acolhimento, a motivação que levou à criação da plataforma realizada, uma descrição do problema inicial, um resumo dos objetivos definidos inicialmente e o plano de estágio definido pela organização.

No capítulo 2, Estado de Arte, está uma análise de gestão de identidades e de Role Mining, neste também são apresentadas algumas das soluções existentes na área de gestão de identidades.

De seguida, no capítulo 3, Metodologia, é definida a metodologia usada no desenvolvimento do projeto.

Posteriormente, no capítulo 4, Análise de Requisitos, é descrita a análise de requisitos, incluindo o diagrama de contexto, o diagrama de classes, entre outros.

No capítulo 5, Tecnologias, são apresentadas as tecnologias utilizadas no desenvolvimento deste projeto.

O capítulo 6, Implementação, é composto pela descrição da implementação realizada durante o desenvolvimento da plataforma, contendo algumas imagens da interface.

(26)

6 No capítulo 7, Verificação e Validação, pode ser visto o processo de testes realizados de forma a garantir um bom funcionamento da plataforma para que esta cumprisse com os requisitos propostos.

Por fim, no capítulo 8, Conclusões, são apresentadas as conclusões do trabalho realizado bem como, potenciais melhorias a ser feitas no futuro.

(27)

7

2 Estado de Arte

Pretende-se, com este capítulo, fazer uma abordagem ao estado da arte atual sobre um ponto de vista tecnológico, analisando alguns do conceitos utilizados e algumas das aplicações relevantes, no âmbito do mercado de Gestão de Identidades e Acesso.

2.1 Gestão de Identidades

Gestão de identidades é o processo organizacional usado para identificar, autenticar e autorizar indivíduos ou grupos de indivíduos a terem acesso a aplicações, sistemas ou redes, associando direitos e restrições de utilizadores a identidades estabelecidas (Rouse, 2017).

A gestão de identidades não só determina se um utilizador tem acesso aos sistemas, mas também define o nível de acesso e as permissões que este possui num sistema específico. Por exemplo, um utilizador pode estar autorizado a aceder ao sistema, mas com restrições a certas funcionalidades deste sistema. Este processo é uma parte crucial no plano de segurança da empresa, pois está vinculado à segurança e à produtividade da organização (Rouse, 2017).

Em muitas organizações, os utilizadores recebem mais privilégios de acesso do que necessitam para desempenhar as suas funções, tornando assim a organização mais vulnerável a ataques. Usando a gestão de identidades, as organizações podem assim proteger-se contra estes ataques, adicionando uma camada adicional de proteção, garantindo que as políticas e regras de acesso dos utilizadores sejam aplicados de forma consistente (Rouse, 2017).

A gestão de identidades também pode ser usado para melhorar a produtividade dos funcionários, o que é especialmente importante ao integrar novos funcionários ou para alterar as autorizações de um funcionário quando este muda de função. Quando as empresas contratam novos funcionários, estes precisam de ter acesso a partes específicas dos seus sistemas. Feito manualmente, esse processo pode consumir muito tempo. No entanto, o provisionamento automatizado pode permitir que as empresas acelerem este processo (Rouse, 2017).

(28)

8

2.2 Role Mining

Role Mining é o processo de analisar os dados de mapeamento dos utilizadores com cada recurso a que tenham acesso, de forma a agilizar o processo de criação ou modificação de permissões na organização (Rouse, 2018).

Num ambiente de negócios, as funções de cada utilizador são atribuídas de acordo com a sua competência, autoridade e responsabilidade do cargo. Isto tem como finalidade obter uma administração de segurança ideal com base na função que cada individuo desempenha dentro da organização.

Existem três formas de fazer o processo de Role Mining, sendo estas (Hitachi ID Systems, 2019):

• “Bottom-up” : são dadas funções pré-existentes aos utilizadores com base nas suas habilidades ou deveres;

• “Top-down”: são formadas funções de maneira a corresponder com as habilidades ou deveres de cada utilizador;

• “By-example”: os gerentes são questionados quais os trabalhadores que realizam o mesmo trabalho e, caso tenham os mesmos privilégios, são atribuídas funções de modo a representar esse grupo.

Este processo traz várias vantagens para as organizações, tais como (Rouse, 2018): • Uma melhor identificação de utilizadores que operam fora do padrão normal; • Deteção e eliminação de funções ou privilégios redundantes;

• As funções e os privilégios de cada utilizador estão sempre atualizados;

• Eliminação de potenciais falhas de segurança e minimização dos riscos que com elas associados.

2.3 Trabalhos relacionados

Nesta secção são analisadas algumas das soluções existentes no âmbito de gestão de identidades, designadamente Oracle Identity Managemet, Microsoft Identity Manager e Okta Identity Cloud.

(29)

9 Como se pode ver na Figura 3, uma análise realizada pela Gartner mostra que as soluções apresentadas são algumas das líderes de mercado no ano de 2019. Esta análise, chamada Gartner Magic Quadrant, permite verificar o posicionamento de várias tecnologias do mesmo ramo, classificar fornecedores de tecnologia com base nos critérios definidos e exibir os seus pontos fortes e fracos.

O Gartner Magic Quadrant classifica cada tecnologia com base nos seguintes quadrantes (Techopedia, 2019):

• Leaders: Normalmente estas empresas possuem uma grande base de clientes e uma forte posição no mercado;

• Challengers: Estas empresas normalmente não têm visão, mas possuem um grande potencial de se transformar em líderes caso os seus planos sejam aperfeiçoados;

• Visionaires: Empresas geralmente pequenas, com visões razoáveis. No entanto ainda sem capacidade de executar essas visões;

• Niche players: Normalmente startups ou empresas mais pequenas que ainda não têm visão nem execução.

Figura 3 – Magic Quadrant for Acess Managment 2019 (Fonte: Gartner, 2019)

(30)

10

2.3.1 Oracle

A Oracle introduziu o seu primeiro produto de gestão de identidades em 1999, com o lançamento do Oracle Internet Directory. Desde então, o portfólio de produtos fez tremendos avanços no crescimento tanto orgânico quanto aquisitivo (Oracle, 2008). Na atualidade a solução desenvolvida pela Oracle no âmbito de gestão de identidades e acesso é designada por Oracle Identity Management, sendo esta composta por várias soluções.

De entre as soluções da Oracle Identity Managment, as que mais se enquadram com este projeto são as seguintes:

• Oracle Identity Manager (OIM) • Oracle Role Manager (ORM) • Oracle Access Manager (OAM)

Oracle Identity Manager

O OIM é um sistema altamente flexível e escalável que permite às empresas gerir todo o ciclo de vida das contas dos utilizadores e privilégios de acesso nos recursos empresariais (Oracle, 2008).

Oracle Role Manager

O ORM é uma solução fundamentada para a gestão de funções, que fornece um conjunto completo de recursos para a gestão do ciclo de vida das funções empresariais (Oracle, 2008). Esta solução permite que os utilizadores de negócios definam o acesso de acordo com a política da empresa, além de examinar os direitos de acesso do utilizador em termos administrativos.

O ORM permite assim (Oracle, 2009):

• Um aprimoramento da segurança, melhorando drasticamente a pontualidade e a precisão do provisionamento de recursos à medida que a associação muda de funções;

(31)

11 • Acelerar a implementação da gestão de funções, extraindo as funções candidatas

tornando assim o processo mais eficaz;

• Fortalecer a conformidade regulatória pelo meio de auditorias detalhadas, permitindo assim saber quem deve ter acesso ao que, e o porquê de o utilizador receber esse acesso.

Oracle Access Manager

O OAM oferece controle de acesso escalável para ambientes heterogéneos, com uma solução integrada e baseada em padrões de autenticação, fornecendo assim uma autenticação, autorização e auditoria centralizada, de forma a habilitar um controle de acesso seguro entre os recursos da empresa. Esta solução ajuda a proteger aplicações empresariais, reduzindo ao mesmo tempo a carga de administração, custo e complexidade (Oracle, 2008).

2.3.2 Microsoft

O Microsoft Identity Manager (MIM) baseia-se nos recursos de gestão de identidades, permitindo gerir utilizadores, credenciais, políticas e acessos dentro das organizações. Além disso o MIM permite o suporte para novas plataformas (Microsoft, 2019).

Com o MIM, uma organização pode simplificar a gestão do ciclo de vida da identidade com fluxos de trabalho automatizados, regras de negócio e fácil integração com plataformas heterogéneas (Microsoft, 2019).

De forma a complementar os recursos do MIM, a Microsoft criou o Microsoft BHOLD Suite, adicionando assim um controle de acesso baseado em funções. O BHOLD permite que as organizações definam funções de utilizadores e parâmetros de controlo de acesso a dados e aplicativos confidenciais. Esta solução inclui serviços e ferramentas que simplificam a modelagem das relações entre funções dentro das organizações, sendo estas mapeadas para permissões e para verificar se as definições estão corretamente aplicadas aos utilizadores (Microsoft, 2017).

(32)

12 De momento a Microsoft não recomenda aos clientes que comecem novas implementações com componentes do BHOLD, pois estes recursos serão substituídos através do Azure AD (Microsoft, 2018).

2.3.3 Okta

Okta Identity Cloud é um serviço integrado de gestão de identidades e acesso. Este serviço é extremamente flexível e possui vários componentes, como por exemplo (Gilbert, 2019):

• Single Sign-On (SSO);

• Autenticação de múltiplo fator adaptável; • Gestão de ciclo de vida;

• Gestão de diretório universal;

• Gestão de acesso à API (Application Programming Interface).

Desta forma é possível obter uma plataforma independente, capaz de satisfazer todas as necessidades da qualquer organização. Na Figura 4, podemos ver uma comparação entre a solução desenvolvida pela Okta e pela Microsoft.

(33)

13

3 Metodologia

Para o desenvolvimento de uma plataforma web é preciso seguir certas normas e critérios de forma a agilizar este processo. De modo a isto acontecer, podem ser usadas várias metodologias.

Neste caso, a Armis optou por utilizar uma metodologia ágil, mais concretamente a metodologia Scrum. Esta metodologia é conhecida pela sua simplicidade e capacidade de organização de tarefas complexas, tonando-a ideal para projetos difíceis. O facto de ter lançamentos rápidos também ajuda na motivação da equipa, pois é possível ver progressos num curto período de tempo.

3.1 Metodologia Scrum

Scrum é uma framework ágil para a gestão e planeamento de projetos de software. Esta permite uma abordagem de desenvolvimento de forma iterativa e incremental que se pode aplicar a qualquer produto, proporcionando assim uma excelente interação entre as equipas de desenvolvimento. Toda esta ligação entre membros e com a participação ativa dos clientes, obtém-se melhores resultados no desenvolvimento do projeto. Na Figura 5 é ilustrado todo o processo da metodologia Scrum.

(34)

14 De seguida são explicados os processos utilizados por esta metodologia (Densenvolvimentoagil, 2014; Drumond, 2019):

• Product Backlog: é a lista principal que contem todas as funcionalidades desejadas para um produto, normalmente definida pelo Product Owner.

• Sprint Planning Meeting: o trabalho a ser executado durante o Sprint é habitualmente planeado durante esta reunião, onde estarão presentes o Product Owner, Scrum Master e a equipa desenvolvimento. Serão descritas todas as tarefas a ser feitas nesta reunião, dando assim origem ao Sprint Backlog.

• Sprint Backlog: é uma lista de tarefas que a equipa de desenvolvimento se compromete a fazer durante um Sprint. Estas tarefas são extraídas do Product Backlog com base nas prioridades que o Product Owner definiu.

• Daily Scrum: todos os dias é feita uma reunião pela equipa, também conhecida por Daily Scrum. Esta tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia seguinte.

• Sprint Review Meeting: no final de cada Sprint é feito um Sprint Review Meeting, onde é mostrado tudo aquilo que foi alcançado durante o Sprint, normalmente em formato de demo contendo todas as novas funcionalidades. Após o feedback, o Product Owner decide se deve ou não realizar o incremento, embora na maior parte das vezes seja realizado.

Sprint Retrospective: a retrospetiva é onde a equipa se reúne para documentar e

discutir o que funcionou e o que não funcionou durante o Sprint. De seguida é discutido aquilo que pode ser melhorado e que medidas serão tomadas para que tal aconteça.

(35)

15

3.2 Detalhes da metodologia no desenvolvimento da PGPN

Numa fase inicial deste projeto foi realizada um reunião entre os membros da equipa e o gestor do projeto (Sprint Planning Meeting) de forma a levantar todas as funcionalidades que iriam ser desenvolvidas nas semanas seguintes (Sprint Backlog). Após a conclusão da fase de planeamento, deu-se início à fase de implementação (Sprint), onde foram desenvolvidas todas as funcionalidades anteriormente definidas.

Durante a fase de implementação eram realizadas reuniões diárias (Daily Scrum), habitualmente na parte da manhã, entre os elementos da equipa e por vezes com o gestor do projeto de forma a rever todas as funcionalidades que foram implementadas naquele dia e a planear o que iria ser implementado no dia seguinte.

No final de cada Sprint eram realizadas reuniões entre a equipa e o gestor do projeto de forma a rever o trabalho realizado ao longo do Sprint (Sprint Review), nesta reunião era apresentado um feedback por parte do gestor de projetos, pois este é quem mantinha contacto com o Product Owner. No final eram indicadas as melhorias que necessitavam de ser implementadas (Sprint Retrospective).

Após isto era feita uma nova reunião acerca do que iria ser implementado no Sprint seguinte.

Durante o desenvolvimento da PGPN foram realizados cerca de quatro sprints, tendo durações entre uma a duas semanas, dependendo das propostas que iam sendo apresentadas pelo gestor do projeto.

(36)

(37)

17

4 Análise de Requisitos

A análise de requisitos de um sistema é um processo muito importante no seu desenvolvimento. Com ela será possível descobrir, analisar, documentar e verificar os requisitos de um sistema de modo a definir claramente tudo aquilo que o software terá de realizar para satisfazer todas as necessidades da organização e dos utilizadores.

Durante a fase de inicial deste projeto, a equipa da Armis determinou vários requisitos que identificam as funcionalidades da solução a desenvolver.

Neste capítulo é descrito o diagrama de contexto e os seguintes itens da linguagem UML (Unified Modeling Language): diagrama de casos de uso, algumas descrições de casos de uso, diagramas de classes e dicionário de dados.

4.1 Diagrama de Contexto

O diagrama de contexto mostra as relações estabelecidas entre o sistema e o meio ambiente, apresentando o sistema com um único processo.

Na Figura 6, é ilustrado o Diagrama de Contexto que traduz a solução para o problema apresentado.

(38)

18

4.2 Diagrama de Casos de Uso

O diagrama de casos de uso permite ver, de forma prática, todas as funcionalidades existentes na plataforma, assim como todas as interações que o ator tem com esta. Na Figura 7, podemos ver o resultado final do diagrama de casos de uso. Todos os casos de uso que comecem por “Gerir” têm como referência inserir, consultar, editar e eliminar.

(39)

19

4.3 Atores e respetivos Casos de Uso

Na Tabela 1 podemos ver os atores (neste caso apenas o administrador), os casos de uso em que este participa e os objetivos dos respetivos casos de uso.

Tabela 1 - Atores e respetivos casos de uso

Ator Caso de uso Objetivo

Administrador

Gerir aplicações

O objetivo é o administrador poder inserir, consultar, editar e eliminar as aplicações usadas dentro da organização.

Gerir permissões

O objetivo é o administrador poder inserir, consultar, editar e eliminar permissões atribuídas às aplicações.

Gerir repositórios

O objetivo é o administrador poder inserir, consultar, editar e eliminar os repositórios.

Gerir departamentos

O objetivo é o administrador poder inserir, consultar, editar e eliminar os departamentos da organização.

Gerir utilizadores

O objetivo é o administrador poder inserir, consultar, editar e eliminar utilizadores.

Gerir funções

O objetivo é o administrador poder inserir, consultar, editar e eliminar as funções.

Importar csv aplicações

O objetivo é o administrador poder importar aplicações em massa a partir de um ficheiro csv.

Importar csv permissões O objetivo é o administrador poder importar permissões em

(40)

20 massa a partir de um ficheiro csv.

Importar csv repositórios

O objetivo é o administrador poder importar repositórios em massa a partir de um ficheiro csv.

Importar csv departamentos

O objetivo é o administrador poder importar departamentos em massa a partir de um ficheiro csv.

Importar csv utilizadores

O objetivo é o administrador poder importar utilizadores em massa a partir de um ficheiro csv.

Importar csv funções

O objetivo é o administrador poder importar funções em massa a partir de um ficheiro csv.

Atribuir e remover permissões às funções e vice-versa

O objetivo é o administrador poder atribuir e remover permissões às funções existentes e vice-versa.

Atribuir e remover funções aos utilizadores e vice-versa

O objetivo é o administrador poder atribuir e remover funções aos utilizadores existentes e vice-versa.

Atribuir e remover permissões aos utilizadores e vice-versa

O objetivo é o administrador poder atribuir e remover permissões aos utilizadores existentes e vice-versa.

Atribuir e remover utilizadores aos departamentos e vice-versa

O objetivo é o administrador poder atribuir e remover

(41)

21 utilizadores aos departamentos existentes e vice-versa.

4.4 Descrição dos Casos de Uso

Nesta secção podemos ver, em forma de tabela, a descrição dos casos de uso apresentados na secção anterior.

Esta tabela é composta pelos seguintes campos: • Nome: indica o nome do caso de uso;

• Descrição: descreve o objetivo em que o caso de uso consiste;

• Pré-Condição: indica todas as condições necessárias para que o caso de uso possa ser iniciado;

• Caminho Principal: descreve todas as etapas do caso de uso entre o ator e o sistema;

• Caminhos Alternativos: descreve validações de campos e operações anormais ao caminho principal;

• Suplementes ou Adornos: indica os casos de teste concretos ao caso de uso; • Pós Condições: caso existam, descrevem alguma operações necessárias após a

finalização do caso de uso.

Tal como indicado acima todos os casos de uso começados por “Gerir”, consistem em inserir, consultar, editar e eliminar, logo destes serão apenas descritos os casos de uso das aplicações sendo os restantes idênticos.

4.4.1 Descrição do Caso de Uso “Inserir Aplicação”

O objetivo deste caso de uso é permitir ao administrador criar uma aplicação (Tabela 2). Tabela 2 - Descrição do caso de uso "Inserir Aplicação"

Nome Inserir Aplicação.

Descrição O objetivo é o ator “Administrador” poder registar uma nova aplicação.

(42)

22 Caminho

Principal

1. O ator encontra-se no menu das aplicações. 2. O ator seleciona o botão “New”.

3. O sistema apresenta um formulário em forma de pop-up com todos os dados necessários (ApplicationID, Name, Description, Repository sendo o Repository uma opção de dropdown com todos os repositórios existentes).

4. O ator preenche o formulário. 5. O ator seleciona o botão “Create”.

6. O sistema cria uma nova aplicação, fecha o pop-up e atualiza a tabela do menu das aplicações.

Caminhos Alternativos

5. a) O sistema devolve um alerta dos campos que se encontram vazios ou que estão num formato incorreto.

5. b) O sistema devolve um alerta caso já exista uma aplicação com os mesmos dados.

5. c) O ator cancela a operação de inserir. Suplementos

ou adornos

- Verificar se os campos obrigatórios estão todos preenchidos. - Verificar se todos os campos estão inseridos no formato correto. - Verificar se existem aplicações existentes com os mesmos dados Pós-Condição O sistema guarda na base de dados uma nova aplicação.

4.4.2 Descrição do Caso de Uso “Consultar Aplicação”

A Tabela 3, descreve com detalhe o caso de uso “Consultar Aplicação”. Tabela 3 - Descrição do caso de uso "Consultar Aplicação"

Nome Consultar Aplicação.

Descrição O objetivo é o ator poder consultar todas as aplicações existentes. Pré-Condição O ator tem de efetuar um login válido.

Caminho Principal

1. O ator seleciona a opção “Applications” no menu lateral.

2. O sistema apresenta todas as aplicações existentes em forma de tabela.

3. O ator pesquisa por ApplicationID, Name, Description, Repository através de uma caixa de texto.

(43)

23 5. O ator seleciona uma aplicação através de uma checkbox.

6. O ator seleciona o botão “Details”.

7. O sistema apresenta todos os dados relativos à aplicação selecionada.

3. a) Não existe nenhuma aplicação com os dados pesquisados.

Suplementos ou adornos

- Verificar se existem dados consoante a pesquisa do ator. - Verificar se a checkbox se encontra selecionada.

Pós-Condição N/A

4.4.3 Descrição do Caso de Uso “Editar Aplicação”

A Tabela 4, descreve com detalhe o caso de uso “Editar Aplicação”. Tabela 4 - Descrição do caso de uso "Editar Aplicação"

Nome Editar Aplicação.

Descrição O objetivo é o ator poder editar os dados da aplicação selecionada. Pré-Condição O ator tem de efetuar um login válido.

Caminho Principal

1. O ator encontra-se no menu das aplicações.

2. O ator seleciona a aplicação desejada através de uma checkbox. 3. O ator seleciona o botão “Details”.

4. O sistema apresenta todos os detalhes relativos à aplicação selecionada.

5. O ator seleciona o botão “Modify”.

6. O sistema apresenta um formulário em forma de pop-up com todos os dados necessários, estes preenchidos com os dados atuais da aplicação.

7. O ator altera os dados desejados. 8. O ator seleciona o botão “Modify”.

9. O sistema valida o formulário e edita os dados da aplicação. Caminhos

Alternativos

7. a) O sistema devolve um alerta dos campos que se encontram vazios ou que estão num formato incorreto.

(44)

24 7. b) O sistema devolve um alerta caso já exista uma aplicação com os mesmos dados.

7. c) O ator cancela a operação de editar.

- Verificar se a checkbox se encontra selecionada.

- Verificar se os campos obrigatórios estão todos preenchidos. - Verificar se todos os campos estão inseridos no formato correto. - Verificar se existem aplicações existentes com os mesmos dados. Pós-Condição O sistema guarda na base de dados os novos dados da aplicação.

4.4.4 Descrição do Caso de Uso “Eliminar Aplicação”

A Tabela 5, descreve com detalhe o caso de uso “Eliminar Aplicação”. Tabela 5 - Descrição do caso de uso "Eliminar Aplicação"

Nome Eliminar Aplicação.

Descrição O objetivo é o ator poder eliminar uma ou mais aplicação(ões) existente(s).

Pré-Condição O ator tem de efetuar um login válido.

Caminho Principal

1. O ator encontra-se no menu das aplicações.

2. O ator seleciona as aplicações que deseja eliminar através de uma checkbox.

3. O ator seleciona a botão “Delete”.

4. O sistema apresenta um pop-up para confirmar a eliminação. 5. O ator seleciona o botão “Confirm”.

6. O sistema elimina a(s) aplicação(ões). Caminhos

Alternativos

5, a) O sistema devolve um alerta devido à existência de dependências com a tabela “Application Roles”.

- Verificar se alguma checkbox se encontra selecionada.

- Verificar se a eliminação realizada tem dependências com outras tabelas.

(45)

25

4.4.5 Descrição do Caso de Uso “Importar CSV Aplicações”

A Tabela 6, descreve com detalhe o caso de uso “Importar CSV Aplicações”. Tabela 6 - Descrição do caso de uso "Importar CSV Aplicações"

Nome Importar CSV Aplicações.

Descrição O objetivo é o ator poder inserir aplicações em massa através de uma ficheiros CSV.

Caminho Principal

1. O ator encontra-se no menu das aplicações. 2. O ator seleciona o botão “Import File”.

3. O sistema apresenta uma janela para a seleção do ficheiro. 4. O ator seleciona o ficheiro CSV que deseja importar.

5. O sistema insere todos os dados dentro do ficheiro CSV e atualiza. a tabela das aplicações com os dados importados.

4. a) O sistema devolve um alerta devido aos campos do CSV não serem compatíveis com os das aplicações.

5. a) O sistema devolve um alerta das aplicações que não foram inseridas devido a estas já existirem ou não serem compatíveis com os requisitos.

- Verificar se o ficheiro de importação se encontrava no formato CSV correto.

- Verificar se os campos do ficheiro de importação são compatíveis com os campos das aplicações.

- Verificar se os dados a ser inseridos já existem ou se são compatíveis com os requisitos.

Pós-Condição O sistema guarda na base de dados todas as aplicações corretamente inseridas.

4.4.6 Descrição do Caso de Uso “Atribuir funções ao utilizador”

A Tabela 7, descreve com detalhe o caso de uso “Atribuir funções ao utilizador”. Tabela 7 - Descrição do caso de uso "Atribuir funções ao utilizador"

(46)

26 Descrição O objetivo é o ator poder atribuir as funções existentes a um utilizador

existente.

Caminho Principal

1. O ator encontra-se no menu dos utilizadores.

2. O ator seleciona o utilizador que deseja visualizar através de uma checkbox.

3. O ator seleciona o botão “Details”. 4. O ator abre a aba das funções.

5. O sistema apresenta uma lista das funções atribuídas ao utilizador. 6. O ator seleciona o botão “+”.

7. O sistema apresenta um formulário em forma de pop-up, contendo um dropdown com todas as funções existentes.

8. O ator seleciona a função que pretende atribuir. 9. O ator seleciona o botão “Add”.

10. O sistema atribui a função ao utilizador e atualiza a lista das funções.

6. a) O ator cancela a operação de atribuir uma nova função.

Pós-Condição O sistema guarda na base de dados uma nova ligação entre o utilizador e a função selecionados.

4.4.7 Descrição do Caso de Uso “Remover funções ao utilizador”

A Tabela 8, descreve com detalhe o caso de uso “Remover funções ao utilizador”. Tabela 8 - Descrição do caso de uso "Remover funções ao utilizador"

Nome Remover funções ao utilizador.

Descrição O objetivo é o ator poder remover as funções já atribuídas um utilizador existente.

Pré-Condição O ator tem de efetuar um login válido. Caminho

Principal

(47)

27 2. O ator seleciona o utilizador que deseja visualizar através de uma checkbox.

3. O ator seleciona o botão “Details”. 4. O ator abre a aba das funções.

5. O sistema apresenta uma lista das funções atribuídas ao utilizador. 6. O ator seleciona o ícone “Caixote do lixo”.

7. O sistema apresenta um ícone “X” atrás de todas as funções existentes na lista.

8. O ator seleciona o ícone “X” na função que deseja remover. 9. O sistema apresenta um pop-up para confirmar a eliminação. 10. O ator seleciona o botão “Confirm”.

11. O sistema remove a função ao utilizador e atualiza a lista das funções.

9. a) O ator cancela a operação de remover a função.

Pós-Condição O sistema remove da base de dados a ligação entre o utilizador e a função selecionados.

4.5 Diagrama de Classes

Nesta secção poderemos ver os diagramas de classes da PGPN. O diagrama de classes mostra como as diferentes classes se relacionam entre si. Estas são constituídas pelo nome, atributos e as responsabilidades que as mesmas representam nas operações realizados pelos atores.

Devido ao projeto ser composto por duas partes, sendo estas Gestão de Perfis e Role Mining foram criados dois diagramas de classes de forma a representar ambas as partes. Na Figura 8, encontra-se o diagrama de classes da parte de Gestão de Perfis, que vai permitir ao utilizador fazer a gestão de todas as aplicações, repositórios, departamentos, permissões, funções e utilizadores dentro da organização.

(48)

28 Na Figura 9, podemos ver o diagrama de classes da parte de Role Mining. Esta permite ao utilizador apenas visualizar os dados mapeados do Active Directory. No entanto, como este projeto ainda se encontra em fase de desenvolvimento, estes dados eram carregados através de ficheiros CSV. Estes dados também poderão ser visualizados de uma forma mais dinâmica na dashboard da PGPN (6.3.1 Dashboard).

(49)

29

4.6 Semântica de Classes

Nesta secção é apresentada a semântica de classes, tendo como objetivo identificar atributos e operações por análise dos vários cenários em que a classe participa (Silveira, M. 2018).

Esta é composta por todos os atributos, tipos de dados, descrições, valores válidos, formato e restrições das classes apresentadas na Erro! A origem da referência não foi

encontrada. e Erro! A origem da referência não foi encontrada.:

• Nome do campo: nome dos atributos que compõem a classe;

• Tipo de dados: tipo de valor que o atributo representa (numérico, texto, …); • Descrição: breve descrição do atributo;

• Valores válidos: valores válidos consoante o tipo de dados (caso seja numérico, verificar se é superior a 0);

• Tamanho: tamanho máximo que o atributo pode atingir (caso numérico, 11 dígitos);

• Restrição: caso existam, restrições atribuídas ao atributo (obrigatório, alterável). As tabelas de dicionário de dados de cada classe encontram-se no Anexo A1.

(50)

(51)

31

5 Tecnologias

Neste capítulo, são apresentadas as várias tecnologias e ferramentas utilizadas no desenvolvimento deste projeto.

5.1 AngularJS

AngularJS é uma framework javascript open-source de desenvolvimento de front-end que possibilita o desenvolvimento de aplicações web, sendo mantida pelo Google. Esta tem como principal objetivo simplificar tanto a escrita de código como o processo de testes. Além disso é possível integrá-la com bibliotecas muito usadas, como o Bootstrap, o D3.js e muitas outras, facilitando ainda mais o processo de desenvolvimento (Julio, 2015).

Esta framework também disponibiliza vários recursos completos de modo a facilitar a criação de aplicações CRUD (Create Read Update Delete) (GSTI, 2019):

• Vinculação de dados;

• Diretrizes básicas de modelos; • Validação de formulários; • Roteamento;

• Componentes reutilizáveis; • Injeção de dependências.

De seguida são explicadas as principais características do AngularJS.

5.1.1 Padrão MVC

MVC (Model View Controller) é um padrão de arquitetura de aplicações que as divide em três camadas: modelo (model), visão (view) e controlador (controller) (Massari, 2017). Na Figura 11 são representadas estas camadas.

Figura 10 – Logótipo AngularJS

(52)

32 De forma resumida utilizar este padrão significa (Massari, 2017):

• Dividir as aplicações em camadas, uma de interface do utilizador denominada por View, outra para a manipulação lógica dos dados chamada Model e uma terceira camada de fluxo da aplicação chamada Controller;

• Criar a possibilidade de exibir a mesma lógica de negócios através de várias interfaces;

• Isolar a camada de negócios (Model) das demais, de forma a facilitar a sustentabilidade do código;

• A implementação do controlador permite que esta camada receba os eventos da interface e os converta em ações no modelo.

Este padrão foi usado tanto na implementação de front-end como na implementação de back-end.

5.1.2 Conceito SPA

SPA significa Single Page Application, e trata-se de um método para o desenvolvimento web. Este método permite uma menor codificação na parte do servidor (back-end) e mais na parte do cliente (front-end), proporcionando ao utilizador uma aplicação dinâmica,

(53)

33 carregando os recursos conforme necessário (Massari, 2019). Na Figura 12 é ilustrada a diferença entre os métodos de desenvolvimento SPA e “Multi-Page Lifecycle”.

Resumindo, este método permite:

• Priorizar técnicas que incrementem a performance dos scripts;

• Construir aplicações inteiramente contidas no browser, que não façam pedidos de novas páginas ao servidor;

• Aproveitar ao máximo os recursos do JavaScript e das suas frameworks; • Usar padrões como o MVC;

• Criar várias Views (camada de interface) para o mesmo modelo de dados (camada de manipulação de dados);

• Separar de forma bem clara a interface visual e a persistência de dados.

5.1.3 Two-Way Data Binding

O conceito de Two-Way Data Binding tem como objetivo automatizar o tráfego de dados, de tal forma que o desenvolvedor não precise de criar handlers no DOM (Document Object Model) para atualizar o JavaScript e vice-versa. Assim quando um valor do DOM muda, o JavaScript responsável por aquele DOM também será atualizado sem que seja necessário a criação de handlers (Custódia, 2016).

(54)

34 Resumindo (McGarnagle, 2012):

• Quando as propriedades no modelo são atualizadas, a View também o é.

• Quando os elementos da interface do utilizador (View) são atualizadas, estas são propagadas de volta para o modelo.

Na Figura 13 encontra-se um fluxograma do conceito acima apresentado.

Este conceito foi usado nas interfaces de “Gestão de Perfis” de modo a facilitar a pesquisa de dados através da searchbox.

Figura 13 - Fluxograma Two Way Data Binding (Fonte: Custódia, 2016 )

(55)

35

5.1.4 Injeção de dependências

Injeção de dependências é uma técnica pela qual um objeto fornece as dependências de outro objeto. Na Figura 14 é ilustrado um esquema de forma a explicar de forma resumida a Injeção de dependências.

Existem 3 tipos de injeção de dependências (Karia, 2018):

• Constructor Injection: as dependências são fornecidas através de um construtor de classe;

• Setter Injection: o cliente expõe um método setter que o injetor usar para injetar as dependências;

• Interface Injection: a dependência fornece um método injetor que a injeta em qualquer cliente passado para ela. Os clientes devem implementar uma interface que exponha um método setter que aceita essa dependência.

5.1.5 Recursos de Diretiva

As diretivas são marcadores num elemento DOM que dizem ao compilador HTML para anexar um comportamento especificado a esse elemento DOM, ou mesmo para

(56)

36 transformar o elemento do DOM e seus filhos. Este recurso permite a implementação de novos comportamentos de forma declarativa (Google, 2018).

Na Figura 15 são apresentadas as diretivas do AngularJS.

Na Tabela 9 são apresentadas as explicações de algumas destas diretivas (Massari, 2017). Tabela 9 – Diretivas AngularJS

ng-app Declara um elemento como o elemento raiz da aplicação, ocasionando a mudança do comportamento do padrão tag.

ng-bind Muda o texto de um elemento HTML automaticamente, de acordo com o seu resultado, vindo das regras de negócio.

ng-model É similar ao ng-bind, mas permite ligação direta bidirecional (two-way data binding) entre a view e o modelo.

ng-show/ng-hide Mostra ou esconde um elemento HTML de acordo com o resultado de uma expressão booleana.

ng-switch Instância um template, numa lista de escolhas, dependendo do valor obtido pela expressão.

ng-click Permite instanciar o evento de click, semelhante ao onclick. ng-if Declaração básica de um 'if' que permite mostrar um elemento se a

condição for verdadeira.

(57)

37 ng-class Permite atributos de classe serem carregados dinamicamente.

5.2 ASP.NET Core

ASP.NET Core é uma versão open-source do ASP.NET. Esta permite a criação de aplicações web de alta performance.

Pelo facto da existência de um template em AngularJS e à existência de vários recursos para a criação de web APIs, a escolha desta plataforma foi ideal para o projeto, ficando então o ASP.NET a servir como uma RESTful API (back-end) e o AngularJS a servir de interface do utilizador (front-end). Outro fator que ajudou na escolha desta plataforma foi também a capacidade de esta hospedar facilmente a aplicação web no IIS.

5.3 Microsoft SQL Server

O Microsoft SQL Server (MSSQL) é um SGBDR (Sistema de Gestão de Base de Dados Relacional) criado pela Microsoft. Este oferece uma grande variedade de aplicações de processamento de transações, inteligência de negócios e análises em ambientes corporativos de TI (Rouse, 2019).

Como outros SGBDR, o MSSQL Server é construído sobre SQL (Structured Query Language), uma linguagem de programação padronizada usada para gerir base de dados e consultar os dados que nelas existem. Este encontra-se vinculado ao Transact-SQL, uma implementação do SQL da Microsoft que adiciona um conjunto de extensões de programação proprietárias ao idioma padrão (Rouse, 2019).

Foi usado este sistema no projeto, devido à necessidade de uma base de dados relacional e devido ao facto de este ser usado na maior parte dos projetos dentro da empresa.

5.4 SQL Server Management Studio

O SSMS é um software para gestão de qualquer infraestrutura SQL. Este oferece bastantes ferramentas para configurar, monitorar e administrar instâncias do SQL Server

(58)

38 e base de dados (Microsoft, 2019). Durante o projeto todas as tabelas, triggers, procedimentos SQL foram criados através deste Software.

5.5 Microsoft Power BI

O Power BI é um serviço de análise de negócios criado pela Microsoft. O seu objetivo é fornecer uma visualização de dados de forma interativa e dinâmica, como também fornecer recursos de inteligência de negócios com uma interface simples para que todos os utilizadores possam criar os seus próprios relatórios e dashboards (Microsoft, 2019). Na Figura 16 são ilustradas as várias plataformas do Microsoft Power BI.

5.6 Postman

Postman é uma aplicação usada para o desenvolvimento de APIs, pois permite ao utilizador testar a sua API à medida que a vai desenvolvendo. Esta aplicação disponibiliza ao utilizador uma interface elegante e uma série de recursos, o que facilita imenso na altura de testar a API. Esta aplicação foi usada durante o desenvolvimento do back-end, desta forma permitiu-nos testar a API á medida que era desenvolvida, sem ser necessário o desenvolvimento de uma interface (front-end).

Alguns dos recursos que esta plataforma permite fazer são (Postman, 2019): Figura 16 - Diferentes plataforma do Power BI (Fonte: Microsoft, 2019)

(59)

39 • Enviar solicitações REST (Representational State Transfer), SOAP (Simple

Object Acess Protocol) e GraphQL de maneira rápida e fácil;

• Automatizar testes manuais e integrá-los ao pipeline de CI/CD (Continous Deployment/Continuous Integration) para garantir que qualquer alteração no código não interrompa a API na produção;

• Gerar e publicar uma documentação elegante de modo a facilitar o consumo da API;

• Partilhar o trabalho num workspace entre colegas de equipa, de forma a todos colaborarem em simultâneo.

Na Figura 17 é ilustrada a interface de uma das funcionalidades do Postman.

5.7 TortoiseGit

TortoiseGit é uma interface do Windows Shell para o sistema de controle de versões Git. Este permite gerir os arquivos ao longo do tempo, onde estes são armazenados dentro de um repositório local. Um repositório é muito parecido com um servidor de arquivos, exceto que este tem registado todas as alterações feitas anteriormente a todos os arquivos e diretórios, permitindo assim recuperar versões mais antigas e examinar o histórico de

(60)

40 forma a ver quando e quem alterou certo arquivo. Desta forma o desenvolvimento em ambientes de equipa torna-se mais fácil pois permite aos desenvolvedores trabalharem em simultâneo no mesmo projeto.

5.8 IIS

IIS é um servidor web criado pela Microsoft, este corre em sistemas Windows e pode ser usado como servidor FTP (File Transfer Protocol), para hospedar serviços WCF (Windows Communication Foundation) ou para hospedar aplicações web.

O facto de permitir autenticação Windows e de ter uma fácil integração com aplicações ASP:NET fez dele a escolha ideal para o projeto.

(61)

41

6 Implementação

Neste capítulo é descrito todo o processo de desenvolvimento ao longo deste projeto. Este foi divido em 4 partes, sendo elas a implementação da base de dados, implementação do back-end, implementação das interfaces (front-end) da PGPN e implementação da PGPN num servidor da Armis via IIS.

O presente projeto é composto por três áreas principais, designadamente o “Dashboard” onde podem ser visualizados todos os dados e uma forma dinâmica e interativa, o “Role Mining” onde podem ser visualizados os mapeamentos de todos os dados existentes dentro da organização e a “Gestão de Perfis” onde é realizada toda a gestão e criação de perfis de negócio.

Durante o desenvolvimento deste projeto, foram sempre divididas tarefas entre os vários elementos da equipa de desenvolvimento, sendo estas explicadas ao longo deste capítulo. Na secção abaixo será explicada a fase inicial do desenvolvimento deste projeto, que consiste na implementação da base de dados.

6.1 Base de dados

Neste módulo são apresentados o modelos Entidade-Relacionamento relativos à PGPN. Estes modelos são criados a partir dos diagramas de classes apresentados anteriormente na secção 4.5 Diagrama de Classes. Também serão apresentados os triggers desenvolvidos.

Toda a implementação relativa a este módulo foi feita através do SSMS, apresentado anteriormente na secção 5.4 SQL Server Management Studio.

6.1.1 Modelo Entidade-Relacionamento

Nas Figura 18 e Figura 19 são apresentados os modelos físicos relativos aos processos de “Gestão de Perfis” e “Role Mining”, desenvolvidos numa fase inicial do projeto. No entanto, estes foram sofrendo alterações ao longo do tempo devido à alteração de requisitos ou de modo a torná-los mais eficientes.

(62)

42 Figura 18 - Modelo Entidade-Relacionamento (Gestão de Perfis) (Fonte: Elaboração Própria)

(63)

43

6.1.2 Triggers

Ao longo do desenvolvimento desta plataforma, foi necessário a criação de alguns triggers. Eles têm como objetivo guardar informação acerca de todas as ações realizadas pelos utilizadores, ou seja, sempre que o utilizador realizava alguma operação CRUD esta era automaticamente guardada numa tabela, guardando os dados relativos ao utilizador que efetuou a operação, a data em que esta foi realizada e os dados relativos ao elemento antes e depois da operação CRUD.

O código destes triggers encontra-se no Anexo A2.