• Nenhum resultado encontrado

Sistema de autentica¸c˜ ao centralizada

No contexto de sistemas computacionais, a autentica¸c˜ao ´e o processo que garante e confirma a identidade de um utilizador. Este processo ´e fundamental para garantir

5.4. SISTEMA DE AUTENTICAC¸ ˜AO CENTRALIZADA 77

que as funcionalidades da Swish s˜ao protegidas de visitantes, que n˜ao possuem qualquer tipo de permiss˜ao. A autoriza¸c˜ao ´e o processo encarregue por definir e assegurar o que cada utilizador pode fazer (Geer, 2003). No caso da aplica¸c˜ao de gest˜ao de instˆancia e utilizadores, esta s´o deve estar dispon´ıvel para administradores do sistema, enquanto que as diferentes instˆancias do Swish s´o devem ser acedidas pelos utilizadores das organiza¸c˜oes a que pertencem.

A autentica¸c˜ao centralizada tem como principal objetivo a unifica¸c˜ao do processo de autentica¸c˜ao num ´unico ponto, permitindo que os utilizadores possam ter acesso a v´arios servi¸cos e aplica¸c˜oes com um conjunto ´unico de credenciais. Este modelo implementa o conceito de Single Sign-On, o conjunto de tecnologias e sistemas que fazem com que um utilizador autenticado seja reconhecido por um conjunto espec´ıfico de sistemas distintos sem que tenha de voltar a autenticar-se (De Clercq,

2002). O facto de os utilizadores de todas as instˆancia da plataforma partilharem um ponto ´unico de autentica¸c˜ao facilita as tarefas de gest˜ao dos utilizadores por parte dos administradores do sistema.

O IdentityServer4 ´e uma framework para o ASP.NET Core 2 que utiliza o protocolo OAuth 2.0 e uma camada de autentica¸c˜ao chamada OpenID Connect e que foi usada para a cria¸c˜ao do sistema de autentica¸c˜ao utilizado pela plataforma e pode atuar como um servidor central de autentica¸c˜ao para m´ultiplas aplica¸c˜oes

O OAuth 2.0 ´e uma framework de autoriza¸c˜ao que permite que as aplica¸c˜oes de terceiros possam obter o acesso limitado a um servi¸co HTTP hardt2012oauth. O OpenID Connect ´e uma camada de identidade colocada no topo do protocolo OAuth 2.0 que permite aos clientes a verifica¸c˜ao da identidade de um utilizador com base na autentica¸c˜ao realizada num servidor de autoriza¸c˜ao, assim como a obten¸c˜ao de informa¸c˜oes b´asicas sobre o mesmo (Sakimura et al., 2014).

O IdentityServer4 permite Single Sign-on, ou seja, a utiliza¸c˜ao de apenas um login para o acesso a diferentes servi¸cos, permite o controlo de acesso a APIs e a integra¸c˜ao com provedores de identidade externos como o Azure Active Directory, Google e Facebook.

78 CAP´ITULO 5. SWISH COMO UM SERVIC¸ O

O ASP.NET Core Identity ´e um sistema de filia¸c˜ao para o ASP.NET Core que adiciona fun¸c˜oes como a cria¸c˜ao de contas e o armazenamento de dados persistente para guardar dados dos utilizadores como palavras-chave, nomes de utilizadores e informa¸c˜oes pessoais. A base de dados escolhida para armazenar os dados dos utilizadores foi o MySQL. A arquitetura do IdentityServer4 foi desenha para permitir flexibilidade no que toca `a escolha da base de dados usada para guardar os dados dos utilizadores. O ASP.NET Core Identity ´e um dos sistemas que pode ser usado em conjunto com o IdentityServer4 e permite a constru¸c˜ao de um sistema de autentica¸c˜ao e utilizadores robusto e com a seguran¸ca providenciada pelo OAuth 2.0 e OpenID Connect.

A utiliza¸c˜ao do Single Sign On coloca uma maior ˆenfase na seguran¸ca no ato da autentica¸c˜ao, uma vez que com apenas um login o utilizador consegue aceder a todos os servi¸cos da plataforma que lhe est˜ao associados. O ASP.NET Core Identity permite a implementa¸c˜ao de um sistema de autentica¸c˜ao de dois fatores para o aumento da seguran¸ca no sistema de autentica¸c˜ao centralizado. Quando o utilizador ativa a autentica¸c˜ao de dois fatores, ´e mostrado um QR Code gerado pelo qrcode.js 7 que dever´a ser lido e associado a uma aplica¸c˜ao de autentica¸c˜ao como o Microsoft Authenticator ou o Google Authenticator. Depois do dispositivo ser associado `a conta do Swish, sempre que o utilizador tentar autenticar-se na plataforma, ter´a de inserir o c´odigo presente na aplica¸c˜ao de autentica¸c˜ao escolhida. Quando um visitante tenta aceder a uma das instˆancias da plataforma ´e redirecionado para a p´agina de autentica¸c˜ao centralizada da plataforma, onde lhe ser´a pedida a inser¸c˜ao dos dados de login. No caso de ser bem sucedido, o utilizador ´

e redirecionado para a instˆancia `a qual tentava aceder, caso tenha permiss˜oes. Se o utilizador tentar aceder diretamente `a aplica¸c˜ao de autentica¸c˜ao, ap´os o login ser-lhe-`a apresenta a lista de instˆancia `as quais este tem acesso, como exemplificado na Figura 5.4.

5.4. SISTEMA DE AUTENTICAC¸ ˜AO CENTRALIZADA 79

Figura 5.4 – Interface com a lista de instˆancias associadas ao utilizador auten.

5.4.1

Autoriza¸c˜ao role-based e claims-based

A autoriza¸c˜ao role-based ´e usada para agrupar utilizadores, com defini¸c˜ao de permiss˜oes que afetam o grupo como e todo e, como consequˆencia, os seus membros. De momento, a plataforma possuiu apenas dois grupos, os administradores e utilizadores, os analistas que ir˜ao usar as instˆancias e usar as funcionalidades de visualiza¸c˜ao. Os administradores possuem acesso ao sistema de gest˜ao de instˆancias e utilizadores e os utilizadores `as instˆancias que lhes est˜ao associadas.

Ao n´ıvel individual, os analistas n˜ao podem aceder a todas as instˆancias que desejam, visto que estas pertencem a organiza¸c˜oes diferentes. Para o controlo desta particularidade foi utilizada a autoriza¸c˜ao claims-based, aplicada individualmente a cada instˆancia com a verifica¸c˜ao das permiss˜oes do utilizadores atrav´es do sistema de pol´ıticas do ASP.NET Core. Uma claim ´e par nome e valor que um utilizador ou organiza¸c˜ao faz sobre si o outro sujeito. O sujeito que faz a claim ´e o provedor, sendo que no caso do Swish o provedor ´e o sistema de autentica¸c˜ao centralizada.

80 CAP´ITULO 5. SWISH COMO UM SERVIC¸ O

e o valor com o nome ´unico que identifica a instˆancia `a qual este pode aceder. A instˆancia ir´a verificar se o utilizador possuiu uma claim com o valor necess´ario e validar o pedido e permitir o acesso ou negar o acesso ao recurso e retornar uma p´agina HTML com o erro HTTP 403, que indica acesso proibido.

Documentos relacionados