O CASE DE CÓDIGO ABERTO IAM

1. Introdução

As estimativas atuais sugerem a adoção generalizada de software de código aberto (OSS) em organizações em todo o mundo. Em comparação com setores como sistemas operacionais e big data, a adoção no setor de gerenciamento de identidades e segurança tem sido baixa até agora. Embora existam vários projetos de código aberto em torno de bibliotecas para funcionalidades relacionadas à segurança e ao gerenciamento de identidades, havia apenas alguns projetos baseados em uma solução de segurança de ponta a ponta ou de gerenciamento de identidades e acesso (IAM). No entanto, nos últimos anos, alguns projetos IAM de código aberto começaram a receber atenção geral. Com a chegada das opções de código aberto, escolher a solução IAM certa para os requisitos corporativos somente com base na comparação de recursos não é mais uma abordagem viável, pois a maioria dos fornecedores oferece funcionalidades semelhantes. Em contraste, os usuários agora são forçados a olhar para outros aspectos sem nenhum recurso. Soluções IAM de código aberto oferecem melhores alternativas para softwares de código fechado devido a forças inerentes, como flexibilidade de implementação, extensibilidade, usabilidade e custos mais baixos.

Este Whitepaper discute os benefícios da adoção de uma solução IAM de software livre, como escolher a solução IAM de código-fonte correta e como o Servidor de Identidade WSO2 ajuda a criar uma nova solução IAM ou a migrar de uma solução proprietária existente.

2. Por que IAM?

O gerenciamento de identidades e acessos é indispensável para a segurança, governança e usabilidade de recursos online. Seja para autenticação, criação de uma experiência de usuário personalizada ou acesso à certificação, a identidade está no cerne de fazer com que os processos funcionem adequadamente. A proteção de ativos digitais, como dados, aplicativos, sistemas, dispositivos e APIs, por meio do controle de acesso e do gerenciamento da identidade (geralmente é chamada de IAM) é uma parte integrante dos negócios digitais. Como é o gateway, a solução IAM deve ser cuidadosamente desenvolvida desde o início e não apenas considerada posteriormente.

3. Quais são as opções de implantação disponíveis?

A criação de uma solução IAM requer uma variedade de software e hardware, mas a parte central da solução é o software, ou às vezes um serviço em nuvem, responsável pelo gerenciamento de identidade e pelos processos de autenticação e autorização. Esses softwares e serviços são geralmente referidos como produtos/serviços do IAM e, com base no modelo de licenciamento e propriedade, podem ser categorizados da seguinte forma.

• Produtos comerciais prontos para uso
• Identidade como serviço
• Soluções de código aberto
• Soluções caseiras

Entre essas opções, as soluções de código aberto oferece muitas vantagens em relação aos demais. Nas seções a seguir, analisaremos esses benefícios.

4. Por que o IAM de código aberto?

A Gartner espera que a adoção do IAM de código aberto aumente para 30% até 2020, de 20% atualmente, devido à adoção bem-sucedida de soluções de software de código aberto em nuvem e em outras áreas [1]. Em geral, o software de código aberto oferece os seguintes benefícios em comparação com as contrapartes comerciais.

• Liberdade
• Extensibilidade ou personalização
• Custo mais baixo
• Inovação rápida

Software de código aberto é livre para usar, modificar e compartilhar. O software pode ser usado imediatamente em avaliações ou provas de conceitos sem esperar por uma licença. Não há necessidade de passar por um vendedor e fazer qualquer papelada para começar um projeto. O modelo de licenciamento de código aberto permite até que o software seja incorporado em uma solução proprietária e agregue valor à solução sem quaisquer implicações legais. Essa liberdade de usar o software sem qualquer implicação legal também impede o bloqueio com um único fornecedor ou plataforma.

As comunidades de código aberto tendem a ter usuários e desenvolvedores de vários setores verticais com diversas origens. Normalmente, as arquiteturas de software de código aberto são projetadas para acomodar requisitos e ideias de comunidades grandes e diversas, o que, por sua vez, permite que os projetos acomodem requisitos e personalizações variáveis. Além disso, a experiência do usuário do IAM deve ser personalizável para oferecer uma experiência digital única entre os concorrentes; O IAM de software livre facilita isso, pois oferece personalizações por meio de extensões e modificações.

Custos incorridos afetam significativamente o retorno de um projeto sobre o investimento. O custo de aquisição inicial do IAM de código aberto é muito menor do que os custos de uma licença de uso comercial. Durante o início de um projeto, serviços de consultoria podem ser necessários para inicia-lo, e esse será o único custo inicial, não recorrente, para a adoção de uma opção de software código aberto. Uma vez que o projeto está ativo, o único custo recorrente será o relativo a serviços de suporte e manutenção, que também é tipicamente menor em comparação com as opções comerciais.

Com a capacidade de experimentar com segurança e falhar com rapidez (“fail fast”) e com baixo custo, as organizações se tornam capazes de alimentar ciclos de inovação. Se um IAM de código aberto não funcionar durante a fase de avaliação, as equipes envolvidas podem facilmente dar uma olhada em outro, já que não há custo inicial de investimento durante a avaliação.

5. Os riscos de optar por uma solução IAM de código aberto e como mitiga-los

Assim como as demais opções, as soluções IAM de código aberto também apresentam alguns riscos envolvidos. Existem mecanismos para mitigar esses riscos. Existem alguns empreendimentos que são puramente baseados na mitigação de riscos na adoção de soluções de software de código aberto. A seguir estão os principais riscos geralmente enfrentados por uma durante a vida útil de um projeto.

• Dependência da comunidade
• Estagnação do projeto
• Desafios na retenção de talentos internos
• Grau menor segurança, já que é aberto

O software de código aberto é construído pela comunidade para a comunidade. Os colaboradores têm um conhecimento profundo do software, já que são eles que o projetaram e desenvolveram como um grupo. Quando há um problema, que requer conhecimento profundo para encontrar uma solução, muitas vezes, os usuários dependerão da comunidade. A ajuda da comunidade não possui nenhum SLA associado a ela. Eles não têm obrigação de ajudar os usuários. Isso representa um grande risco para as empresas que pretendem usar software de código aberto em operações de missão crítica.

As empresas que usam código aberto em seu projeto tentam mitigar os riscos construindo talentos internos, contratando os colaboradores ou treinando a força de trabalho existente. Os funcionários que saem representam um risco para as empresas, pois leva tempo para construir um pool de recursos.

Quando o principal colaborador deixa a comunidade ou a comunidade perde o interesse, os projetos de código aberto tendem a parar sem qualquer progresso e sem ninguém para manter o software. Isso colocará projetos corporativos em perigo.

Há um equívoco de que o código aberto é menos seguro porque os intrusos podem olhar para o código-fonte e visar as vulnerabilidades. No entanto, o software de código aberto usa os mesmos processos de desenvolvimento de software seguros que a fonte fechada. Há muitas ferramentas de verificação de segurança de software livre disponíveis para criar um processo de desenvolvimento de software seguro e, às vezes, ferramentas de verificação de segurança disponíveis comercialmente oferecem serviços gratuitos para detectar vulnerabilidades de segurança em códigos abertos. Além disso, em se tratando de softwares de código aberto, há muitos olhos que podem olhar para o código-fonte, em comparação com alguns em fonte fechada.

A escolha de um software de código aberto apoiado por uma entidade comercial com um plano de negócios sustentável garantirá a longevidade da manutenção. Serviços comerciais, como suporte corporativo com SLAs agressivos e serviços profissionais, podem reduzir a maioria dos riscos com garantias legais.

6. O que procurar ao escolher IAM de código aberto?

Quando alguém decide usar o IAM de código-fonte aberto em seus cases de uso, há muitas opções por aí. Existem diferenças de recursos para modelos de licenciamento. Deve-se examinar cuidadosamente essas diferenças em relação aos requisitos. Uma avaliação deve, pelo menos, abranger os seguintes aspectos, a fim de ter um projeto bem-sucedido do IAM:

• A capacidade de atender aos requisitos funcionais - Seja de código aberto ou não, a solução IAM deve ter todos os recursos para atender aos requisitos funcionais do projeto. Além de se referir a recursos da comunidade para obter mais detalhes sobre o conjunto de recursos, a realização de uma prova de conceito às vezes ajuda a avaliar corretamente a solução.
• Código aberto, não apenas núcleo aberto - Existem muitos modelos de negócios baseados em software de código aberto. Ao escolher o provedor de código aberto, um com um modelo de software de código aberto é melhor que um com um modelo de núcleo aberto. Um modelo de código aberto fornece a solução completa gratuitamente sob um modelo de licenciamento de código aberto; no entanto, no modelo de núcleo aberto, apenas o núcleo do software está disponível como uma oferta gratuita, com outras funcionalidades críticas sendo disponibilizadas apenas por meio de uma licença comercial. Devido a isso, selecionar um modelo de núcleo aberto não é diferente de se prender em uma solução comercial.
• Facilidade de extensão e personalização - Ter flexibilidade para personalizar a solução é um requisito necessário para qualquer solução IAM. A solução de código aberto deve ter pontos de extensão suficientes para personalizá-la para proporcionar uma experiência do usuário diferente dos concorrentes.
• Capacidade de integração com conjuntos de tecnologia heterogênea - A solução IAM vai atuar como um ponto de entrada para todas as aplicações do negócio digital. Muitas integrações são necessárias para ter uma autenticação centralizada e autorização para todos os aplicativos. O produto de código aberto deve suportar a integração com aplicativos desenvolvidos usando uma variedade de tecnologias e implantados na nuvem ou no local.
• Implantações na nuvem x Implantação local, e necessidades de interconectividade - Alguns produtos de código aberto apresentam limitações no que diz respeito às opções de implantação suportadas. A solução IAM escolhida deve suportar o ambiente de implantação já utilizado para implantar o restante dos sistemas. Se a implantação exigir modificação na solução ou uma alteração na prática de implantação de uma organização, a solução será difícil de adotar.
• Se assegure de que você possa incorporar os mais recentes algoritmos e protocolos de segurança quando eles surgirem - Sempre que houver um padrão melhor introduzido para fazer as coisas de maneira mais segura e eficiente, o projeto deverá ter a largura de banda necessária para ser capaz de incorporá-lo ao produto ou solução. Se a comunidade for suficientemente grande e ativa, isso fará com que o produto seja atualizado com os padrões de segurança mais recentes.
• Conformidade com padrões de segurança e regulamentações do setor - Dependendo da diversidade da comunidade, a cobertura de conformidade será limitada ao que a comunidade está procurando. Se a comunidade não tem membros de uma determinada indústria ou território, então o projeto não daria prioridade aos padrões exigidos por aquela indústria ou território.
• Suporte a padrões abertos - É necessário que o suporte a padrões abertos esteja livre de bloqueio de fornecedores. Quando há muitas integrações, ter uma solução baseada em padrões abertos permitirá a substituição de provedores com alterações mínimas.
• A força da comunidade do software de código aberto - A força e o tamanho da comunidade são um indicador importante da sustentabilidade da solução de código aberto. Quando a comunidade é grande, é fácil obter apoio dos membros da comunidade e contratar.
• O nível de suporte comercial - Ter suporte comercial para manter a solução baseada em código aberto é semelhante a uma apólice de seguro para mitigar riscos.

O restante do artigo discute como um IAM de software livre pode ser uma opção vantajosa, apresentando o exemplo do Gestão de Identidade e Acesso WSO2 (Servidor de Identidade WSO2).

7. Introdução ao Servidor de Identidade WSO2

O WSO2 Identity Server faz parte da Plataforma Ágil de Integração WSO2 e é uma solução IAM de código aberto que facilita o login único (ou “single sign-on” entre aplicativos e federa identidades entre vários sistemas diferentes. É otimizado para proteger APIs, microsserviços e projetos de IAM de clientes. Ele oferece recursos de nível corporativo, como federação de identidades, SSO, autenticação forte e adaptável, gerenciamento de contas e provisionamento de identidades, para ajudar as organizações nativas digitais a se tornarem ágeis na integração por meio da segurança do CIAM e da API.

8. Customizando o Servidor de Identidade WSO2

O WSO2 Identity Server é construído sobre uma arquitetura extensível, onde há uma extensão para personalizar as funcionalidades mais importantes do produto. Como essas extensões são reutilizáveis, a WSO2 hospedou uma loja on-line [3] com todas as extensões oficiais. Essas extensões estão disponíveis sob a licença Apache 2 e podem ser baixadas e conectadas ao produto sob demanda. A seção a seguir discute algumas das extensões mais importantes.

8.1 Extensão de gerenciamento de usuários

Os repositórios de usuários são a parte principal da funcionalidade de gerenciamento de usuários. É um resumo representando armazenamentos de dados, como LDAP, Diretório Ativo e bancos de dados, onde os dados do usuário são armazenados. Os aspectos do armazenamento do usuário podem ser personalizados por meio de extensões.

8.2 Extensão de armazenamento de usuário

Existem variedades de armazenamentos de dados que podem atuar como um serviço de diretório ou repositório de usuários. Existe uma extensão de armazenamento de usuário correspondente para cada tipo de serviço de diretório. O repositório de usuários para serviços de diretório padrão, como LDAP ou Diretório Ativo, já é fornecido com o produto e, para outros tipos de armazenamentos de dados não-padrão ou novos, uma extensão pode ser construída e integrada ao WSO2 Identity Server.

8.3 Operações dos listeners de armazenamento do usuário

Se houver necessidade de ouvir (listen) eventos de gerenciamento de usuários, como criar, editar ou excluir um usuário ou função e executar uma ação com base no evento, essa extensão deverá ser usada. Isso pode ser utilizado sempre que o sistema externo deva ser notificado de alterações ocorridas no repositório de usuários locais.

8.4 Listener de eventos de erros de gerenciamento de usuários

É semelhante à extensão do listener de eventos anterior. A única diferença é que a notificação é enviada somente se houver algum erro durante qualquer uma das operações.

8.5 Customizando Mensagens de Erro

As mensagens de erro exibidas durante o processo de autenticação podem ser personalizadas por meio dessa extensão, e as páginas de erro comuns, como a página 404, podem ser definidas para um tema para estar de acordo com os requisitos corporativos.

8.6 Validador de Senha Customizado

Durante o processo de criação ou registro do usuário, uma senha fornecida pelo usuário pode ser validada por meio dessa extensão. A força e a complexidade da senha podem ser impostas por meio dessa extensão.

8.7 Autenticação de Extensão

Com base em como a autenticação é feita, os mecanismos de autenticação com suporte no WSO2 Identity Server podem ser categorizados da seguinte maneira.

1. Autenticação local
2. Autenticação Federada

Autenticar usuários com um repositório de usuários conectado localmente é conhecido como autenticação local. A autenticação federada é para autenticar usuários em sistemas de identidade externos usando protocolos de autenticação federados.

Existem várias maneiras de verificar a identidade de um usuário por meio da autenticação local. A validação de nomes de usuários e senhas, dados biométricos e certificados são mecanismos de autenticação ou verificação de identidade do usuário bem conhecidos. Cada método pode ser implementado como uma extensão e conectado ao WSO2 Identity Server.

Cada extensão fornece diferentes maneiras de executar a autenticação federada: uma extensão pode ser escrita para um protocolo de federação ou um sistema pode usar seu próprio caminho. As extensões para implementar protocolos de federação padrão conhecidos são fornecidas com o produto.

8.8 Extensão de Provisionamento

O WSO2 Identity Server oferece suporte a provisionamento de entrada, just-in-time e saída. O método de provisionamento de entrada é para provisionar usuários, o provisionamento just-in-time adiciona usuários ao repositório de usuários local durante a autenticação federada, e o provisionamento de saída é para provisionar usuários no sistema externo.

O sistema para gerenciamento de identidade entre domínios (SCIM) é um dos mecanismos de provisionamento de entrada suportados pelo WSO2 Identity Server. O SCIM tem sua própria maneira de representar usuários (ou seja, recursos) e atributos por meio de um esquema. Um atributo personalizado deve ser adicionado ao esquema por meio de uma extensão de esquema. O WSO2 Identity Server possui uma extensão para adicionar atributos customizados ao esquema SCIM.

O suporte para provisionamento de saída para sistemas externos é fornecido por meio de uma extensão. Cada sistema e SaaS possui a extensão correspondente para o provisionamento de usuários de saída. Quando houver necessidade de oferecer suporte ao provisionamento de saída para um novo sistema ou SaaS, ele poderá ser implementado como uma nova extensão.

8.9 Extensão de autorização

Além do controle de acesso interno baseado em função, o WSO2 Identity Server oferece suporte a OAuth2 e XACML.

O ponto de informações de política XACML é a interface através da qual o mecanismo XACML recupera os atributos do usuário. Para oferecer suporte à recuperação de atributos do usuário de várias origens diferentes, o Servidor de Identidade WSO2 fornece a extensão do ponto de informações sobre políticas.

Na implementação do OAuth2, o Servidor de Identidade WSO2 fornece uma extensão para adicionar um tipo de concessão personalizado; isso permite personalizar a maneira como um receptor de token é autenticado.

9. Migrando do IAM Proprietário

Ter amplo suporte para personalização é fundamental para projetos. No entanto, para projetos existentes que usam o IAM proprietário, o caminho da migração deve ser suave. Migrar de uma solução IAM para outra solução IAM requer as três coisas a seguir:

1. Dados do usuário
2. Aplicações
3. Configurações

9.1 Abordagens para migrar dados do usuário

Se os usuários estiverem disponíveis em um repositório de usuários padrão, como o LDAP ou o Active Directory, será fácil migrar os usuários para o Servidor de Identidade WSO2 conectando o repositório de usuários e configurando-o. No entanto, se os usuários estiverem em um banco de dados com esquema customizado, uma nova extensão de repositório de usuários deverá ser gravada e conectada ao produto para integrar.

Se os usuários do sistema atual puderem ser exportados para um arquivo CSV ou XLS, esses dados poderão ser importados para uma instância do WSO2 Identity Server com um novo repositório de usuários, usando o recurso de importação do usuário.

Outra abordagem complexa é continuar executando o sistema atual e habilitar a federação entre o sistema atual e o WSO2 Identity Server com um novo repositório de usuários. Com o provisionamento just-in-time ativado, quando os usuários efetuarem login, eles serão adicionados dinamicamente ao repositório de usuários. Em um ponto, quando quase todos os usuários são importados para a nova implantação, a federação pode ser desativada e o sistema antigo pode ser demolido.

9.2 Abordagens para migrar aplicativos

Os aplicativos integrados para autenticar e autorizar a solução do IAM devem ser alterados se a solução do IAM for migrada para uma solução diferente. Se a integração for feita usando um padrão aberto, como OAuth2, SMAL2, OpenID connect ou XACML, as alterações necessárias para a migração serão mínimas.

O WSO2 IAM também suporta a conexão OpenID. Se o aplicativo for projetado para usar a descoberta de conexão OpenID para descobrir automaticamente os detalhes do provedor de conexão OpenID, a migração envolveria a alteração do URL de descoberta.

Se o aplicativo for integrado usando um protocolo de federação proprietário, uma extensão deverá ser gravada para executar a integração. O WSO2 Identity Server oferece suporte à adição de uma implementação de federação proprietária por meio de uma extensão.

9.3 Abordagens para migrar configurações

As configurações estão lá para personalizar o comportamento padrão do produto. Para toda a implantação, as configurações básicas devem ser feitas de acordo com as práticas recomendadas documentadas. Não há como pular isso. Existem algumas outras configurações, como configurações de provedor de serviços e provedor de identidade, que podem ser automatizadas para evitar a repetição com base no número de provedores de serviços e provedores de identidade em uso.

Existem padrões abertos para trocar metadados de configuração por meio de exportação e importação. A especificação de metadados SAML SP/IDP define um endpoint padrão por meio do qual os dados do provedor de serviços e do provedor de identidade SAML2 podem ser exportados. A maioria das soluções proprietárias de IAM suportam exportação de metadados SAML2. O WSO2 IAM suporta a criação de provedores de serviços e provedores de identidade fornecendo metadados.

Se o IAM proprietário fornecer APIs para obter essas configurações repetidas, ele poderá ser importado automaticamente para o WSO2 IAM usando APIs de produto e importação de metadados. O WSO2 IAM possui APIs para criar provedores de serviços e provedores de identidade por meio de APIs não padrão. Essas APIs são coletivamente conhecidas como APIs de administração de produtos. Existem algumas APIs padrão abertas também disponíveis. Por exemplo, os aplicativos OAuth2 podem ser criados automaticamente usando uma API de registro do cliente dinâmico OAuth2.

A aparência da maioria das interfaces baseadas em navegador geralmente é personalizável por meio de padrões da Web, como CSS e HTML. Os fornecedores de IAM o seguem estritamente para obter compatibilidade de seus produtos com todos os navegadores da web. WSO2 IAM não é um outlier nesse caso. O mesmo CSS e HTML podem ser reutilizados durante a migração com alterações mínimas para obter a mesma aparência que anteriormente.

10. Conclusão

Soluções de IAM de código aberto estão agora ganhando atenção de empresas semelhantes a IAMs proprietários e comerciais. As empresas devem considerar os IAMs de código-fonte aberto para seus cases de uso, já que essas soluções apresentam proposições de valor exclusivas, devido à abertura, usabilidade, extensibilidade e baixo custo. No futuro, mais e mais empresas adotarão IAM de código aberto sem qualquer hesitação, dadas as ilustrações acima. Se você quiser saber mais sobre o WSO2 Identity Server, leia nosso Whitepaper aqui.

11. Referências