Single Sign-On: o caminho das pedras

Rafael Shoji

Imagine que todos os aposentos de sua casa estão sempre trancados e você precisa de todas as chaves dos dormitórios para circular por ela. Agora, considere o mesmo no lugar em que você trabalha e nos demais locais que você costuma ir. Do que você precisaria para viver, além de um bolso enorme para guardar tantas chaves? Organização, disposição, um chaveiro para quaisquer lugares novos que você quisesse freqüentar e, principalmente, paciência, porque algumas vezes você não acharia a chave correta e seria impedido de ir ao banheiro ou a uma loja, por exemplo. Soluções de Single Sign-On buscam eliminar esse pesadelo, só que em sistemas e redes de computadores.

Problemas com a administração de senhas surgem nos sistemas e ambientes heterogêneos que exigem autenticação e autorização locais. A principal dificuldade é que a utilização de dezenas de senhas numa organização gera custos operacionais. Funcionários, clientes e fornecedores acabam esquecendo as senhas necessárias para fazer um processo fluir, gerando ineficiência e um significativo custo operacional à empresa, leia-se gastos com Help Desk, seja ele manual ou eletrônico/automatizado.

Adicionalmente, como uma corrente é tão mais fraca quanto mais frágil for seu elo, uma grande quantidade de senhas pode comprometer a segurança dos próprios sistemas que se tenta proteger. Senhas mal elaboradas ou iguais são compartilhadas entre sistemas e usuários, o que implica no comprometimento de toda a organização.

As soluções atuais de Single Sign-On ainda estão longe da resolução desses problemas para ambientes heterogêneos e muitas delas estão baseadas em reconhecimento de padrões em telas. No entanto, Single Sign-On para Web, no qual as aplicações são restritas ao contexto do navegador e as requisições de autenticação são respondidas por um serviço ou componente acoplado ao servidor web, tem tido um desenvolvimento mais acelerado por meio da padronização. Inicialmente, Web Single Sign-On foi implementado usando cookies para armazenar o estado da sessão.

Essas abordagens de Web Single Sign-On têm rapidamente evoluído com a proposta de padrões e de uma abordagem federativa, na qual os sistemas transferem a autenticação que realizam em outros domínios, evitando a redundância. Entre esses padrões há o SAML (Security Assertion Markup Language), o WS-Security, ambos da OASIS, e o Liberty Alliance Project, um consórcio encabeçado pela Sun. O SAML é um padrão XML para transferência de autenticação e autorização entre diferentes sistemas. Já o WS-Security é um amplo padrão para implementar serviços Web de forma independente e segura, especificando cabeçalhos e envelopes para mensagens SOAP (Simple Object Access Protocol) seguras. O consórcio Liberty Alliance, por sua vez, é baseado no SAML e buscou inicialmente uma alternativa ao sistema de autenticação Passport, da Microsoft, que só permitia sites que suportassem o sistema.

Aparentemente esses padrões têm amadurecido a ponto de podermos ter interoperabilidade. Um claro sinal dessa tendência é a aliança da Sun e da Microsoft, recentemente divulgada, de trabalharem em uma especificação que garanta transferência de autorização e autenticação entre os domínios baseados em Liberty e WS-Federation, especificação que a Microsoft vem adotando. Caso essa promessa se concretize, pelo menos para a web, será dado um grande passo para que se possa ter uma senha única para os diversos serviços para o qual precisamos nos autenticar na Internet. É ver para crer.

Rafael Shoji é diretor da E-VAL, empresa especializada em soluções de Segurança da Informação e Certificação Digital.