Além de atuar diretamente na construção das aplicações desenvolvidas na Pris, nossa equipe de desenvolvedores atua, também, em componentes e serviços complementares, necessários para que as aplicações sejam entregues com qualidade para nossos clientes. Um destes componentes complementares essenciais é o Provedor de Identidade – Identity Provider, IDP – que atua identificando e autenticando os usuários para acesso às aplicações, além de realizar a integração com os IDPs de clientes.
Esse tema tem recebido especial importância com a entrada em vigor da Lei Geral de Proteção de Dados (LGPD) e aumento da preocupação das empresas com Segurança da Informação, por isso, neste artigo, explicaremos a abordagem técnica que utilizamos para construir este componente.
Durante sua concepção, as duas principais aplicações da Pris foram estruturadas para realizarem autenticação de usuários por conta própria, ou seja, toda a estrutura de identificação e gestão de usuários estava dentro da própria aplicação, não em um serviço separado.
A opção por esse formato se deu por uma questão de custo-benefício. Uma das aplicações começou a ser desenvolvida em 2011, e a outra (Ilupi) em 2014. Nesse período, a preocupação com a gestão e replicação de dados de usuários pelos clientes era muito menor do que hoje. Para o Options Report, por exemplo, entre o lançamento em 2012 e 2019, somente um cliente havia demandado Single Sign-On, isto é, que a autenticação fosse feita através do IDP corporativo do cliente, e não dentro da própria aplicação.
Considerando esse cenário de pouca demanda de clientes por um mecanismo mais robusto de gestão de identidade, optamos pelo mecanismo mais simples, que funcionou bem até 2019. Porém, esse formato tem pelo menos duas desvantagens claras:
1) Toda a base de dados de usuários que utilizam a aplicação é replicada do sistema de gestão da empresa para a base da aplicação, o que:
- Aumenta a superfície de ataques e vazamento de dados.
- Demanda esforço grande por parte dos administradores do sistema de sincronização das bases de dados. Por exemplo, se o endereço de um usuário é atualizado no sistema de gestão da empresa, o administrador deve atualizar também na nossa aplicação.
2) O usuário tem credenciais próprias na aplicação, ou seja, mais um nome de usuário e senha para guardar.
A partir de 2019, houve duas mudanças importantes no cenário dos dados que nos forçaram a uma mudança de abordagem para o tema.
A primeira foi uma mudança de exigência pelos clientes: a maior parte de novos clientes passou a exigir Single Sign-On (SSO) para utilizar a aplicação. Isto é, a autenticação de usuários deveria ser realizada pelo IDP corporativo do cliente, e não pela própria aplicação. Acreditamos que essa mudança foi motivada principalmente pela LGPD.
A segunda foi que começamos a migrar a aplicação para uma Single Page Application (SPA) baseada em Angular. O SPA não deveria possuir estrutura própria de autenticação como a versão anterior, mas sim consumir como um serviço.
Em um primeiro momento, ainda tentamos incluir tratamentos específicos dentro da própria aplicação. Porém, à medida que a demanda por SSO aumentou, percebemos que esse formato seria inviável em termos de esforço de manutenção e risco de erros.
Neste momento, começamos a buscar por soluções que, ao mesmo tempo, atendessem bem a demanda dos clientes e da SPA e reduzissem o esforço de configuração e manutenção em autenticação, incluindo SSOs.
Após pesquisas sobre o tema, identificamos o Identity Server como um bom candidato. O Identity Server (IS) é um framework de servidor de identidade baseado em .NET. Como é possível observar no link da documentação mencionado acima, ele visa a atender justamente os requisitos que estávamos buscando: autenticação como serviço, Single Sign-On e Federation Gateway (explicaremos este conceito um pouco mais a frente).
Além de atender bem aos requisitos, escolhemos o IS por outros 3 motivos:
1) Encaixe de stacks: O IS foi desenvolvido e é voltado para .NET, stack utilizada em nossas aplicações.
2) Customizável: o IS é consumido como um projeto Open Source, não um sistema fechado. Com isso, é possível customizá-lo para as necessidades de cada contexto. Ao mesmo tempo, o código tem boa legibilidade, aliado a uma boa documentação, o que facilita as customizações na prática.
3) Credibilidade: o IS faz parte da .NET Foundation e possui recomendações na própria documentação da Microsoft sobre o tema. Isso nos deu confiança de ser um framework maduro e com bom apoio na comunidade.
Baseado, então, no IS, desenvolvemos nosso próprio Identity Provider, o Pris IdP. O Pris IdP é um serviço independente, que pode ser consumido por diferentes aplicações. Em relação à estrutura, é uma API (ASP.NET Web API), consumida por aplicações ou outras APIs por meio de endpoints.
O Pris IdP é capaz de fazer autenticação por conta própria ou delegar a autenticação para IDPs das empresas clientes das aplicações da Pris, para fornecer Single Sign-On. Ou seja, ele atua como um Federation Gateway, isto é:
O Pris IdP atua como “ponte” entre nossa aplicação e o IDP da empresa cliente que fará a autenticação.
Assim, a nossa aplicação só conhece o Pris IdP, não o IDP da empresa cliente. Ou seja, para nossa aplicação, o processo é o mesmo: ela solicita autenticação para o Pris IdP e recebe o resultado (token), independente do Pris IdP fazer a autenticação por conta própria ou via IDP de terceiros.
A figura abaixo resume esse processo:
O processo de autenticação via serviço externo é feito através de protocolos (processos padrão) pré-definidos. Existem diferentes protocolos, como OAuth 2.0, OpenID Connect (OIDC), WS-Federation, SAML2 - cada um com suas particularidades.
O Identity Server é um framework voltado para os protocolos OIDC e OAuth 2.0. O OIDC, principalmente, é um protocolo mais moderno, elaborado já voltado para os cenários de uso mais comuns atualmente, de aplicações distribuídas, e deve prevalecer nos próximos anos.
Porém, o protocolo SAML2 ainda é muito utilizado, sobretudo por grandes empresas, por ser o protocolo padrão do serviço de identidade on-premises da Microsoft – Active Directory Federation Services, ou ADFS. Pela característica de negócios B2B da Pris, o Pris IdP precisa conseguir atender o protocolo SAML2 também.
Atingimos isso com uma customização no IS, através da biblioteca de código aberto Sustainsys.Saml2. Essa biblioteca permite que aplicações e serviços .NET realizem autenticação através deste protocolo. Assim, conseguimos adaptar o IS para contemplar também esse protocolo, atendendo o nosso requisito.
Com a estrutura descrita acima, já conseguimos integrar com sucesso IDPs de clientes baseados em diferentes tecnologias como ADFS, Azure AD, Okta, Google SAML e o próprio IS.
Por outro lado, até o momento, focamos nos requisitos funcionais, principalmente devido ao pico de demanda sobre o assunto, trazido pela LGPD. Assim, hoje temos um “MVP” (minimum viable product) do serviço, e questões como UI para facilitar a configuração dos SSOs, mensagens de erro mais amigáveis e detalhamento de algumas documentações estão no backlog do serviço.
Outro ponto importante é que IdP ainda possui alguns pontos de acoplamento com uma das aplicações da Pris. Nosso objetivo é chegar em um serviço 100% genérico, que possa ser consumido por qualquer aplicação da Pris somente via configurações, sem alteração de código.
Por último, deixamos abaixo alguns materiais para quem desejar trabalhar com o tema. Esses materiais foram fundamentais para chegarmos a um bom entendimento do assunto e na versão atual do serviço.
Kevin Dockx é professor da plataforma de cursos Pluralsight. Ele possui 3 cursos específicos sobre o tema e, para cada curso, é mostrada a implementação realizada em sua página no Github.
O grande ponto forte desses cursos é que unem bem teoria e prática. No início do primeiro curso, Dockx explica de forma bem didática o processo de autenticação externa pelo protocolo OIDC. Em seguida, começa a implementar as definições teóricas utilizando o Identity Server, mostrando a implementação passo a passo, do início, e como as alternativas do protocolo são refletidas nas configurações do IS e da aplicação cliente.
No segundo curso, ele mostra como migrar configurações do IS para banco de dados, ao invés de em memória. E, no terceiro, mostra a utilização de um provedor de identidade no contexto de microsserviços.
A plataforma de cursos Desenvolvedor.io (https://desenvolvedor.io/), do Microsoft Regional Director Eduardo Pires, também possui cursos interessantes sobre o tema.
No curso “ASP.NET Core Enterprise Applications”, ministrado pelo próprio Eduardo Pires, é mostrado o desenvolvimento de uma aplicação a nível comercial, isto é, sem simplificações comuns em cursos. O sistema desenvolvido é distribuído, e um dos pontos abordados é o desenvolvimento de um serviço de identidade. Ele não realiza a implementação com o IS, porém fornece uma excelente base conceitual sobre divisão de responsabilidades de um serviço de identidade distribuído, além de como é feito o consumo por outros serviços e aplicações. Em uma aula final, ele cita o Identity Server e como ele pode ajudar no processo, porém não detalha sobre a implementação com o framework.
Eles também possuem um curso específico sobre o tema, “Fundamentos de IdentityServer4”, ministrado pelo Bruno Brito - uma das melhores referências nacionais sobre o tema. O ponto forte do curso é o fornecimento de uma excelente base conceitual, explicando de forma bem didática todos os conceitos envolvidos. Porém, é um curso introdutório.
A documentação do Identity Server, por si só, já é uma ótima referência. Ela não se limita a detalhes técnicos do framework, em muitos pontos explica a base conceitual por trás – como o exemplo da seção sobre Federation Gateway, mencionada anteriormente. Ela cobre uma grande variedade de cenários. Porém, por ser um material escrito e mais denso, talvez não seja a melhor indicação para quem está ingressando no tema, e sirva melhor como material de consulta à medida que for aprofundando.
Não deixe de acompanhar nossas publicações. Mensalmente, publicamos um texto com temas exclusivos, desenvolvidos por um de nossos especialistas na área.
A Pris tem como propósito simplificar processos de negócios, facilitando o dia-a-dia de empresas e colaboradores em nossas áreas de atuação. Para realizar esse objetivo desenvolvemos diversas soluções, desde consultorias e treinamentos, até sistemas e softwares inovadores, como o Pris e o Ilupi.
Como empresa de software, contamos com uma equipe robusta de desenvolvedores e desenvolvedoras especializados, e queremos mostrar um pouco de nosso trabalho diário e nossas estratégias e soluções técnicas.
Uma de nossas iniciativas se trata do desenvolvimento de uma completa área de Quality Assurance (QA), contando com o apoio da consultoria especializada da Base2.
Como primeira ação prática deste trabalho, começamos a implementar melhorias no processo de Testes Manuais, utilizando a funcionalidade Test Plans do Azure DevOps.
Na Pris já utilizamos o Azure DevOps para gerenciar todo o processo de desenvolvimento – repositório de código, Scrum, pipelines de build / release. Assim, a utilização do Azure DevOps Test Plans foi um encaixe natural e permite integrar facilmente com as outras etapas do processo.
O Test Plans do Azure DevOps é uma funcionalidade muito completa, e vale a pena para todo profissional conhecê-la um pouco. Internamente desenvolvemos um treinamento para nossa equipe, e criamos um breve tutorial.
1) Organização de Casos de Teste (Test Cases)
2) Execução de Test Cases
3) Falhas nos testes: Criação de Bugs
Além da funcionalidade em si, a melhoria envolve também mudanças no processo de desenvolvimento, ao longo da Sprint. São dois pontos principais:
Este último ponto deve impactar também no planejamento da Sprint: para que as alterações sejam disponibilizadas mais cedo, possivelmente será necessário reduzir o volume de trabalho incluído em cada Sprint. Em resumo, a ideia é fazer menos, mas com mais qualidade.
Diante disso, dois resultados principais com esta estruturação do processo de Testes Manuais são bastante esperados em virtude de seu impacto positivo:
Isto deve ser atingido devido as várias melhorias que a estruturação gera no processo, como mostra a comparação abaixo do antes e depois.
Quer trocar experiências sobre Testes Manuais ou conhecer mais sobre o nosso processo? Entre em contato com a gente!
