SOA e IAM - Segurança em Web Services

Quando há o uso de Web Services para a implementação de uma Arquitetura de Serviços, os padrões WS-Security têm uma importância indiscutível. São eles que permitirão que o processamento de mensagens SOAP seja feito de modo seguro.

Este "post" tem como objetivo ilustrar um pouco o uso deste padrões. Entretanto, em primeiro lugar, gostaria de descrever o que tipicamente acontece em um ambiente sem Web Services. Acho que podemos encontrar muitas analogias importantes depois.


Web Single Sign-On (SSO)
Comentei no "post" passado sobre a típica arquitetura de segurança de aplicações usando um servidor específico de Autenticação e Autorização. Abaixo uma imagem ligeiramente diferente daquela que utilizei:

A fatoração entre as lógicas de Aplicação (apresentação, negócio, acesso a dados, etc) e de Autenticação e Autorização é uma excelente idéia em qualquer lugar. Em um ambiente Web, com o usuário manipulando um "browser", não é diferente.

Antes de descrever o fluxo de processamento, é importante notar que a inserção de um Servidor de Autenticação e Autorização na arquitetura de software, apesar de trazer inúmeras vantagens, implica em um evento intrusivo no ambiente:

• O primeiro momento de "intrusão" no ambiente é a própria presença deste servidor.
• As aplicações são protegidas por um componente de software posicionado entre o browser e elas próprias. Tal componente é chamado de agente e é tipicamente localizado em um Servidor Web ("Web Server"). Este é o segundo momento de "intrusão" no ambiente. As responsabilidades do agente são (1) verificar se o usuário já foi autenticado e (2) autorizar o uso, ou controlar o acesso a um recurso da aplicação pelo usuário.
• O terceiro momento de "intrusão" no ambiente ocorre pela necessidade de alteração da aplicação, posto que as lógicas de autenticação e autorização foram implementadas pela própria.

No momento da autenticação do usuário o que acontece é mais ou menos isso:

• O usuário requisita a execução de uma aplicação através de uma URL bem conhecida.
• Um sistema de proteção da aplicação, ou o agente mencionado acima, verifica se o usuário já foi autenticado. Esse passo consiste em analisar a presença de um token de autenticação na requisicão HTTP enviada pelo browser. Caso o token não esteja presente, significa que o usuário nunca foi autenticado e portanto deve ser redirecionado ao Servidor de Autenticação e Autorização (o redirecionamento ocorre pela resposta 302 à requisição HTTP).
• O usuário é submetido ao processo de autenticação previamente estabelecido. Novamente, tal processo é tão complexo quanto se queira, envolvendo diversos tipos de credenciais, fatores de autenticação, etc.
• O Servidor de Autenticação e Autorização faz uso das bases de dados existentes (LDAP, SGBD, etc) para autenticar o usuário.
• Caso o usuário tenha sido autenticado com sucesso, o Servidor de Autenticação (1) cria um token de autenticacão e (2) redireciona novamente o usuário à aplicação. A requisição é a mesma daquela original emitida pelo usuário com a diferença que desta vez há a presença do token de autenticação.
• Como o token, desta vez, está presente na requisição HTTP, o agente permite que a mesma seja enviada à aplicação.
• A aplicação inicia o tratamento da requisição. Note que não ocorrência de autenticação por parte da mesma.

O "Single Sign-On" é atingido quando todas as aplicações estiverem protegidas pelo agente. Ou seja, o token de autenticação é reconhecido pelo agente e transferido a quaisquer aplicações. Deste modo, o usuário é requisitado para apresentar suas credenciais somente uma vez. Diria que uma arquitetura como essa traz vantagens bem mais valiosas do que o próprio "Single Sign-On". Mais uma vez, a flexibidade dos processos de autenticação, juntamente com a sua separação em relação aos processos de negócios implementados pelas aplicações são os seus maiores benefícios.






Basic Web Services
Os fundamentos de Web Services são bastante simples: há um Provedor de Serviços ("Service Provider") e um Consumidor ("Service Consumer"). Mensagens SOAP trafegam entre os dois elementos para requisição de informações e respectiva resposta. A figura abaixo exibe o que chamamos de "Basic Web Services".


Contudo há pelo menos duas questões que inicialmente devemos considerar em relação à segurança: (1) não há qualquer referência ao usuário responsável pela requisição de um Web Service e (2) as mensagens SOAP, muito provavelmente, atravessarão nós intermediários até o seu destino. Cada nó intermediário poderá ser um sistema específico responsável por um tipo de processamento a ser imprimido na mensagem SOAP até chegar no provedor do serviço.
.

O uso de tecnologias como SSL ("Secure Sockets Layer"), apesar de necessário, garante somente a segurança das informações entre nós. Outras tecnologias devem ser adicionadas para endereçar não somente os dois itens acima mas outros que também podem surgir.

Web Services Security
Entra o padrão Web Services Security (WS-Security ou WSS), conduzido pelo OASIS. Trata-se de uma extensão que permite a inserção de mecanismos baseados em tokens em mensagens SOAP.

A figura abaixo exibe a estrutura de uma mensagem SOAP sem o padrão WSS. Importante notar a presença de um "header" na mensagem. Este "header" é usado para descrever características da mensagem. O WSS, então, define como inserir informações de tokens de segurança no "header" da mensagem. Isso é ilustrado na mesma figura.


Note que o WSS permite o uso de diversos tipos de tokens como certificados digitais X.509, tickets Kerberos, etc. O uso mais comum atualmente para este token é o padrão SAML, também do OASIS.

STS (Security Token Service)
Postas as novas variáveis, uma pergunta aparece: qual componente da arquitetura é o responsável pela emissão de tokens SAML? Novamente aparece a figura do STS. Este servidor cumpre um papel semelhante àquele desempenhado pelo Servidor de Autenticação e Autorização em ambiente Web Single Sign-On explorado anteriormente. De fato, tipicamente, temos à disposição no mercado produtos que podem ser usados em ambas as situações (Web SSO e STS). A figura abaixo ilustra a situação.

Além do STS, a figura exibe o padrão WS-Trust também do OASIS. Esta padrão estende o WSS para que um elemento da cadeia de mensagens Web Services possa requisitar a emissão, renovação, validação, etc de tokens de segurança (SAML, mais uma vez, é um padrão disso).
Em resumo, este framework percorre o seguinte fluxo:

• O consumidor faz uma requisição WS-Trust para o STS para autenticação informando credenciais.
• O STS verifica as credenciais nas bases de dados de usuários existentes.
• Caso o usuário seja autenticado, um token SAML é criado.
• Os tokens SAML são usados por WS-Security para a sua inclusão no cabeçalho da mensagem SOAP.
• Todos os nós seguintes, incluindo o destino da mensagens têm acesso à mensagem, e consequentemente ao token SAML.

Como conclusão: em um ambiente corporativo de Web Services para a construção de uma Arquitetura Orientada a Serviços, o uso dos padrões WS-Security, WS-Trust, SAML, além do próprio STS é absolutamente obrigatório. Infelizmente, estes elementos não recebem a atenção necessária em um projeto de implementação SOA. Como se vê, esta questão deve ser encarada com seriedade e diria que deveria ser conduzida como mais um subprojeto dentro do espectro amplo de SOA.