De volta ao básico: E quando não é possível usar um diretório único?

Continuando (muito mais tarde do que eu imaginava, peço desculpas) o blog anterior, precisamos colocar um pouco mais os pés no chão. A idéia de se ter um único diretório acessível por diversos protocolos é muito interessante, mas é um tanto quanto fora da realidade. Por que?

Quantos de vocês possuem diversos sistemas (internos ou licenciados de terceiros) que possuem um diretório próprio para os processos de autenticação e autorização, isto é, quantos deles possuem base própria de pares usuário/senha e controle de perfis de acesso? Aposto que a esmagadora maioria tem. E o que é possível fazer sobre isso?

Há, pelo menos, três soluções no horizonte:

1. Deixar do jeito que está, mas melhorar o que está para vir:
   Muitas vezes é extremamente difícil justificar os investimentos necessários para alterar os sistemas atuais, a não ser que sua empresa esteja sendo pressionada por alguma legislação. Mas dá para melhorar o que vem por aí.
   Tenho um caso interessante de um cliente que veio discutir sobre este assunto há um par de anos: eles tinham uma bem estabelecida infra-estrutura de Active Directory na empresa mas precisavam estabelecer um esquema de single sign-on para sua infra-estrutura. Analisamos durante algum tempo o impacto que isto teria, tanto em projetos, quanto em aquisição de licenças e novos procedimentos operacionais e resolvemos partir para o princípio do KISS (Keep It Simple, Sam): estabelecemos requisitos para a aquisição de novos produtos e para a atualização dos produtos atuais, usando as idéias de múltiplos protocolos como fachada para o mesmo diretório. Com isso foi possível traçar no tempo, com menos investimentos, um caminho para o diretório único;
2. Usar um produto de single sign-on:
   Muitas empresas de grande porte partem para esta solução. Normalmente estes produtos fazem um mapeamento de contas de usuários e suas senhas, oferecendo uma API que permite fazer o controle de perfis. O usuário se loga em todos os sistemas usando um único par usuário/senha mas, por debaixo do pano, o sistema de single sign-on verifica qual usuário/senha deve ser utilizada para cada um dos sistemas, efetivamente mascarando para o usuário a parafernália de identidads do seu ambiente. É normalmente uma tecnologia complexa, de custo elevado, que nem todas as empresas têm disponibilidade para investir;
3. Usar um produto de sincronização e provisionamento:
   É uma solução que permite a sincronização dos pares usuário/senha dos diversos sistemas/plataformas, facilitando principalmente a vida do usuário final (que não precisa se lembrar de tantos pares de usuário/senha), mas traz complexidade extra para o ambiente. As funções de provisionamento permitem que, ao se incluir ou excluir um usuário na empresa, seja possível, com regras pré-definidas, criar ou excluir o mesmo usuário em diversos sistemas com diretórios desconexos ao mesmo tempo em que, ao se trocar uma senha em um dos diretórios, esta senha seja replicada em todos os sistemas ao qual o usuário tem acesso. Idéia simples, mas que também embute mais complexidade na infra-estrutura.

Para a opção 1, temos uma técnica que é possível ser utilizada depois de uma análise mais aprofundada do ambiente: se os sistemas desenvolvidos internamente compartilharem uma API de autenticação/autorização própria, em muitos casos é possível substituir o código desta API (sem alterar as interfaces) por uma nova API que faça acesso ao diretório principal da empresa, migrando gradualmente de um cenário de múltiplos diretórios para um cenário de diretório único.

Mas aqui fica mais um pensamento: quando se utilizam as técnicas 2 e 3 acima, é provável que a força da sua senha seja em realidade, a da senha de complexidade mais baixa. Se, por exemplo, um dos sistemas aceita apenas senhas de 8 caracteres maiúsculos,  para que o single sing-on funcione ou a sincronização seja efetiva, todos os sistemas ficam com os mesmos 8 caracteres maiúsculos. Assim, mesmo que um ou mais sistemas permitam uso de senhas complexas, esta características não será explorada adequadamente. Razão esta para um outro cliente que eu conheço não usar nenhum destes esquemas: eles definiram um grupo de 3 a 5 diretórios, atribuindo a cada um deles um grupo de sistemas dependentes. Sistemas críticos dependem do diretório que permite maior controle da complexidade da senha, enquanto sistemas mais simples ficam com os diretórios que oferecem menor complexidade. Para eles também há uma vantagem de se manter esse número de diretórios: caso a senha de um usuário fique comprometida, apenas aqueles sistemas dependentes do diretório que hospeda o par usuário/senha com problemas é que serão um alvo potencial de ataque, minimizando o risco de se ter um ponto único de falha no controle de acesso à informação.

A seguir (próximo blog): A federação a nosso alcance.