Implementando Segurança em um aplicativo Flex/BlazeDS utilizando o Single-Sign-On do Active Directory

le 23/09/2011 par Antoine Véret

Seu Diretor Executivo de Segurança da Informação quer a integração de seus aplicativos Flex/BlazeDS no Active Directory? Claro, você poderia usar o antiquado método LDAP, mas certamente você prefere retirar o peso das costas dos seus usuários de ter que digitar novamente as suas credenciais. Agrade seus clientes integrando seus aplicativos ao SSO do Active Directory.

Imagine um aplicativo web com uma interface de clientes Flex, chamando serviços de negócio através de um canal BlazeDS. Antes de usar tais serviços de uma interface Flex, usuários precisam autenticar com a sua conta AD (Active Directory). Este artigo expõe a maneira de se estabelecer uma autenticação transparente por meio do protocolo Kerberos que o AD implementa.

Se tudo fosse configurado perfeitamente, o BlazeDS iria controlar a autenticação Kerberos sozinho, mas infelizmente suas capacidades atuais de autenticação não irão superar a antiga combinação login/senha. Porém, o canal BlazeDS continua sendo um serviço Java baseado na web, então vamos tirar vantagem disso! Que entre o Spring Security...

A estrutura Spring Security fornece aplicativos Java de diversas maneiras para controlar a autenticação. Iniciando a partir da versão 3, a estrutura de configuração em xml ficou mais simples. E, aproveite, o Spring Security suporta o Kerberos graças a uma extensão recente. Como todos os componentes da nossa estrutura estão definidos, vamos fazer com que comuniquem melhor.

Arquitetura

Este diagrama resume as interações entre os componentes da nossa estrutura para a proteção do canal BlazeDS:

Kerberos e o Active Directory

Publicado pela primeira vez nos anos 80 pelo MIT (Massachussets Institute of Technology), o protocolo Kerberos é um modo de autenticação padrão do Active Directory introduzido pelo Windows 2000. Ele substitui o NTLM, que não é mais recomendado pela Microsoft.

O protocolo é baseado na troca de permissões com um controlador de domínio. Este diagrama mostra como aquelas trocas são realizadas quando um cliente acessa um serviço protegido pelo Kerberos:

(1) O usuário abre sua sessão do Windows com suas credenciais AD para usar sua estação de trabalho, como habitual.
(2) A estação de trabalho entra em contato com um controlador de domínio para verificar as credenciais e obter uma permissão daquela sessão chamada TGT (Ticket Granting Ticket)
(3) Quando o usuário acessa o serviço protegido pelo Kerberos, o Windows solicita um ST (Service Ticket) ao Controlador de Domínio (CD).
(4) O CD envia um ST criptografado à estação de trabalho, para que seja somente utilizado pelo serviço solicitado.
(5) O cliente pode agora autenticar a si mesmo para o serviço, nenhuma senha será solicitada.

O CD identifica um serviço pelo seu Nome Principal de Serviço (SPN). No AD, cada serviço é registrado como uma conta de usuário, que é então mapeada a um SPN durante a geração da chave do serviço com a ferramenta ktpass. No nosso caso, o nosso SPN de serviços web é algo como HTTP/appserver.octo.com@AD-DOMAIN.

Agora, vamos ver como integrar nosso serviço (a parte do servidor de aplicativo Flex) com o Kerberos.

Configuração BlazeDS

Em teoria, o Spring Security integra-se ao BlazeDS por meio do projeto Spring-Flex. Infelizmente, este suporte está atualmente limitado à autenticação com nome de usuário/senha. Desse modo, não temos esperança em tirar proveito do Spring-Flex para autenticação Kerberos. Detalhamos nossa solução a seguir.

Utilizamos os filtros URL do Spring Security para proteger dois tipos de recursos:

Recursos estáticos (html, css,...), incluindo o arquivo swf, que é a parte do cliente do aplicativo
O endpoint do BlazeDS (por exemplo, o lado do servidor do canal BlazeDS)

Arquivo de configuração do Spring Security:

<sec:http entry-point-ref="spnegoEntryPoint" auto-config="false">

  <sec:intercept-url pattern="/**" access="IS_ AUTHENTICATED_FULLY"  />

  <sec:custom-filter ref="spnegoAuthenticationProcessingFilter" position="BASIC_AUTH_FILTER" />

</sec:http>

A tag intercept-url é usada para solicitar que o usuário seja autenticado. A tag custom-filter especifica que os dados da autenticação serão processados pelo SPNego (veja abaixo).

Ao acessar uma daquelas URLs, o Spring Security dispara trocas de autenticação seguindo o protocolo SPNego. O SPNego permite a negociação do modo de autenticação usado (por exemplo, NTLM ou Kerberos), para que o cliente e o servidor cheguem a um acordo sobre o modo que ambos possam controlar. A negociação utiliza uma resposta HTTP 401 do servidor do aplicativo, contendo os cabeçalhos do SPNego que afirmam que o servidor pode controlar o Kerberos.

Uma vez que o navegador e o servidor concordaram sobre o uso do Kerberos, o navegador entra em contato com o Windows API para solicitar ao Controlador de Domínio um Service Ticket para obter acesso ao servidor de aplicativos. Então, a permissão é validada pela Extensão Kerberos do Spring Security utilizando a própria chave de serviço do servidor descrita na apresentação do Kerberos acima.

Se a permissão é validada, o usuário é autenticado e os mecanismos de autorização do Spring Security (funções, ACLs) devem conceder ou negar o acesso a um dado recurso. A fase de autorização é independente do Kerberos.

Mas há um problema: o uso de um canal HTTPS BlazeDS (SecureAMFEndpoint) exige a utilização de um mecanismo de login BlazeDS que consiste no servidor de uma classe LoginCommand. Portanto, implementamos nosso próprio LoginCommand (PreAuthLoginCommand)...que não precisa fazer qualquer verificação de credenciais, sendo a autenticação controlada de fato pelo Spring Security antes de qualquer acesso ao canal.

public class PreAuthLoginCommand implements LoginCommand, LoginCommandExt {

public Principal doAuthentication(String username, Object credentials) {
//We dont do any check !
logger.info("doAuthentication " + username + ", returning a PreAuthPrincipal");
return new PreAuthPrincipal(username);
}

public boolean doAuthorization(Principal principal, List arg1) {
logger.info("doAuthorization " + principal + ", returning true");
return true;
}
…
}

Indo mais longe

Este artigo não mencionou a configuração da estação de trabalho do cliente. É muito simples e consiste em dois pontos:

Uso de um navegador habilitado para SPNego-Kerberos, tais como Internet Explorer, Firefox ou Chrome.
Configuração do navegador para confiar no seu aplicativo (permitindo, desse modo, que o aplicativo receba Service Tickets do seu navegador). Esta configuração pode ser implementada em todas as estações de trabalho por meio dos GPOs do Active Directory.

Para mais detalhes, confira a seção "Links", abaixo.

Uma última ideia para aumentar a sua estrutura de segurança: ofereça a seus usuários uma maneira de fazer o logout das seções Kerberos no seu aplicativo e retorne de vez em quando para uma autenticação baseada em senha. Isto permitirá que um usuário diferente do proprietário da conta AD seja autenticado.