( DOCUMENTO EM CONSTRUÇÃO: com alguns TODOs )
Neste documento eu, Paulo Jerônimo, compartilho um pouco sobre
IDÉIAS E OPINIÕES PESSOAIS sobre as responsabilidades de
equipes que poderiam atuar no desenvolvimento ou na
implantação de aplicativos que devem ser integradas a um Keycloak
(ou a um RH-SSO).
Eu apresento, aqui, uma visão (simplificada) de trabalho que adquiri ao
ter passado por alguns projetos, em médias ou grandes empresas, onde o
Keycloak é parte de sua infraestrutura.
A intenção básica deste documento é apenas fomentar uma discussão
(a ser aberta através do uso de um sistema de comentários (TODO))
com quaisquer interessados sobre esse assunto.
|
Avisos legais (Disclaimer):
|
1. Antes de começar: Keycloak ou RH-SSO?
2. Equipes
2.1. Equipe de negócio
-
Equipe responsável por definições de negócio que podem ser implementados através de aplicativos ou soluções tecnológicas das mais variadas formas.
2.2. Equipe de arquitetura
-
Equipe responsável pela definição e adoção de padrões corporativos que envolvem, dentre várias alternativas, a escolha de:
-
Tecnologias.
-
Linguagens de programação e frameworks.
-
Ferramentas: de desenvolvimento, integração, ALM, bancos de dados, etc.
-
2.3. Equipe de DevOps (ou ALM)
-
Equipe responsável por facilitar a integração entre os equipes de desenvolvimento e produção.
2.4. Equipe de desenvolvimento
-
Equipe responsável pelo desenvolvimento de aplicativos que oferecem soluções ao negócio.
2.5. Equipe de segurança
-
Equipe responsável por garantir que os dados, e o acesso aos mesmos, estejam sempre seguros, do ambiente de desenvolvimento ao ambiente de produção.
2.6. Equipe de produção
-
Equipe responsável por, em acordo com as áreas de negócio, segurança e monitoramento da empresa, disponibilizar os aplicativos em produção.
2.7. Equipe de monitoramento
-
Equipe responsável por monitorar a saúde dos aplicativos de negócio da empresa, garantindo que eles estejam sempre disponíveis.
3. Responsabilidades (por equipe) no que se refere ao Keycloak
3.1. Equipe de arquitetura
Do lado de uma equipe de arquitetura, creio um dos papéis dessa equipe seria o de fornecer exemplos e demonstrações funcionais sobre como os mais diversos tipos de aplicativos deveriam ser integrados ao Keycloak.
Isso inclui guias e exemplos de como usar tecnologias de front-end (como Angular, React, etc) ou back-end (como Spring Boot, Quarkus, etc) integradas ao Keycloak observando-se os padrões e a infraestrutura utilizadas pela empresa para a qual trabalha essa equipe. Com certeza, vários dos exemplos podem ser extraídos do repositório keycloak-quickstarts. Mas, ainda assim, eles precisam ser adaptados para a realidade da empresa no tocante padrões utilizados por ela.
A equipe de arquitetura também deveria atuar no Keycloak em questões como:
-
Definição de versões que podem ser utilizadas.
-
Integrações do Keycloak a outros produtos.
-
Customizações diversas (ex: criação de temas e fluxos específicos).
-
Definições de Realms.
-
Definições de Roles corporativas.
-
…
3.2. Equipe de DevOps (ou ALM)
O papel dessa equipe deveria ser o de, a partir de definições arquiteturais elaboradas pela Equipe de arquitetura, oferecer visibilidade, através de exemplos práticos e integrados a Ferramentas para DevOps, sobre como os aplicativos deveriam ser implantados de forma integrada ao Keycloak.
Essa equipe deveria fornecer documentos (preferencialmente scripts ou exemplos de código) que demonstrassem, de forma rápida e simples, como um novo projeto de desenvolvimento poderia ser implantado na infraestrutura da empresa. Como um exemplo, esses documentos (ou scripts) deveriam apresentar como o Keycloak poderia ser integrado a um OpenShift (se esse fosse utilizado).
Nessa última situação eu creio que, além de exemplos de soluções integradas ao OpenShift, também deveriam ser oferecidas alternativas para que a construção de aplicativos pudesse ser realizada de forma contêinerizada, dependendo apenas do Docker (e/ou do Docker Compose) de forma que um aplicativo pudesse ser prototipado e iniciado, rapidamente, em ambiente de desenvolvimento, sem a dependência de uma infraestrutura complexa como o OpenShift.
Eu já passei por esse tipo de problema onde, ao fazer o setup de um projeto utilizando o Angular 10, percebi que a Equipe de DevOps (ou ALM) a empresa tinha um processo específico e customizado para a implantação através do OpenShift. Mas, como disse, o desenvolvimento de um contêiner é algo bastante simples de ser gerenciado (se o desenvolvedor já possui alguma experência em Docker, como no meu caso). Dessa forma, eu considero que uma independência do OpenShift, em ambiente de desenvolvimento, possa ser muito útil para que uma aplicação seja iniciada e construída de uma forma bem rápida.
3.3. Equipe de desenvolvimento
Atuando numa empresa de médio porte para cima, haverá situações onde o desenvolvimento de um aplicativo será realizado por equipes internas e, também, por equipes externas a essa empresa.
Imagine a situação em que você é o líder de desenvolvimento de um aplicativo, em uma equipe de desenvolvimento externa, que precisa ser integrado a um Keycloak implantando em um cliente.
Como líder de uma equipe desenvolvendo um aplicativo para esse cliente eu gostaria de receber, dele, documentos que me oferecessem detalhes sobre como acesso o seu Keycloak. Esses documentos deveriam me direcionar o desenvolvimento de forma que eu pudesse colocar o aplicativo em homologação no ambiente desse cliente da forma mais rápida possível.
O mais interessante, contudo, seria que eu pudesse acessar o Keycloak desse cliente evitando assim, que eu tivesse que instalar ou configurar um Keycloak em meu próprio ambiente.
| Apesar de ser bastante simples a instalação do Keycloak (por exemplo, da forma como eu faço em keycloak-labs utilizando o Docker Compose), ele oferece facilidades para que seus serviços possam ser extendidos ou modificados. Por essa razão, a instalação do Keycloak, mesmo que adotando as mesmas versões especificadas por um cliente, pode ainda ser bastante diferente da que está no ambiente desse cliente. Minha sugestão, nesse caso, seria que o Keycloak do cliente pudesse ser acessado remotamente (via HTTPS, claro). |
3.3.1. Registro de cliente
Como desenvolvedor, haverá um momento (assim que for necessária a codificação de acesso seguro a um determinado recurso) em que será necessário um Client Registration (registro de cliente) em um Realm específico do Keycloak.
O Keycloak possibilita que existam administradores diferentes por Realm. Tendo a administração de um Realm em suas mãos, o líder da equipe de desenvolvimento poderia adicionar ou remover Clients da forma como fosse preciso ao desenvolvimento.
| Isso ocorre, por exemplo, ao ser utilizada o serviço Please Open It, um exemplo de Keycloak as a Service no qual você pode obter um Realm próprio para fazer suas configurações. |
Clientes (aplicações) também podem se auto registrar através do serviço
de registro de cliente oferecido pelo Keycloak.
O endpoint desse serviço é
/auth/realms/<realm>/client-registrations/<provider> e os providers
suportados são default, install, openid-connect e
sam2-entity-descriptor (detalhados no tópico Client Registration da
documentação).
Para chamar o serviço de registro de cliente, usualmente é necessário um token (para chamar o endpoint acima). Mas, também há uma forma de isso ser realizado até mesmo sem um token (através de configurações da política de registro de cliente). Por fim, também há uma CLI disponível para o registro de cliente.
3.3.2. Deploy automatizado (de desenvolvimento a produção)
Atuando no papel de líder de desenvolvimento, eu gostaria de ser capaz de implantar o aplicativo remotamente no cliente contando com o auxílio de sua Equipe de DevOps (ou ALM). E eu gostaria de ser capaz de implantar a aplicação nos ambientes de desenvolvimento ao ambiente de homologação do cliente, em parceria com a Equipe de negócio do cliente, de forma automatizada e independente.
Eu não deveria ter o poder para implantar a aplicação em produção já que essa deve ser uma atividade exclusiva de uma Equipe de produção do cliente. Mas, observando que já haveria meios automatizados para implantar o aplicativo até o ambiente de homologação, eu esperaria que essa Equipe de produção fosse responsável por isso, de forma rápida e segura, apenas através da configuração de algumas variáveis que seriam gerenciadas e visíveis somente por ela.
Como líder do desenvolvimento do aplicativo eu gostaria que o meu desenvolvimento local não ficasse amarrado a uma infraestrutura remota mesmo sabendo que haveria chances de eu ter alguma incompatibilidades de ambiente.
Eu digo isso pelo seguinte: eu poderia ser uma startup, por exemplo, que de forma totalmente independente e desacoplada trabalha em seu próprio ambiente observando, para isso, apenas algumas diretrizes básicas de desenvolvimento especificadas pelo cliente. Além disso, quaisquer erros seriam resolvidos, rapidamente, durante a implantação do aplicativo no ambiente de desenvolvimento do cliente, antes mesmo dessa implantação ocorrer no ambiente de homologação.
Pelo fato do Keycloak ser um Identity Manager de fácil instalação que pode usufruir de um contêiner (homogêneo) executável em diferentes ambientes, eu esperaria apenas que houvesse uma maneira rápida, mínima e simples, de se fazer um setup do mesmo de forma a atender um conjunto de configurações básicas necessárias a um ambiente próximo (em termos de configuração) ao do cliente.
Pelo lado do desenvolvimento de um aplicativo, seria interessante (diria que necessário) que um script de configuração do Keycloak fosse criado, e que pudesse ser executável pelo cliente, em seu ambiente, com mínimas configurações para isso.
| Eu exemplifico, através do projeto Keycloak Matrix, como é possível criar tais scripts e executá-los de maneira automatizada para tornar o Registro de cliente algo bastante simples e rápido evitando, assim, erros possíveis causados por uma má interpretação (ou escrita) de algum documento de implantação. Observo, porém, que esse projeto ainda é apenas uma prova de conceito. |
Partindo da Equipe de arquitetura deveriam vir informações relativas aos Realms e configurações específicas utilizados até o ambiente de homologação de forma que os scripts do aplicativo pudessem ser construídos com base nessas informações.
3.4. Equipe de segurança
O papel de uma equipe de segurança, com relação ao uso do Keycloak, poderia ser o de averiguação do atendimento as definições de segurança estabelecidos pela empresa.
Essa equipe seria, com certeza, uma das mais beneficiadas pela introdução do Keycloak na empresa pois ele, com certeza, aborda grande parte dos requisitos de segurança que são estabelecidos na maioria das corporações utilizando, para isso, padrões de mercado conhecidos e já estabelecidos.
3.5. Equipe de produção
A equipe de produção seria responsável por executar procedimentos elaborados pela Equipe de DevOps (ou ALM) para a implantação das aplicações em ambiente de produção. Obviamente seguindo definições estabelecidas através de uma gerência de mudanças para uma implantação manual de um release (Continuous Delivery) ou através de um processo automatizado e contínuo (Continuous Deployment).
3.6. Equipe de monitoramento
Uma equipe de monitoramento deve se beneficiar da capacidade do Keycloak para gerar e exportar logs de eventos.
Ferramentas como o ELK (Elasticsearch + Logstash + Kibana), EFK (Elasticsearch + Fluentd + Kibana) ou o Graylog podem ser facilmente integrados ao Keycloak para disponibilizar eventos relativos a utilização do Keycloak pelos usuários e clientes registrados.