Por dentro da Microsoft.comUsando os Serviços de Federação do Active Directory

Jim Guthrie

Na Microsoft, fornecemos uma extranet para proporcionar acesso aos parceiros comerciais a importantes recursos internos. A arquitetura da extranet requer que cada participante fora da organização tenha um conta de domínio exclusiva para esse espaço. Essa conta é criada e gerenciada pelos funcionários da Microsoft, e não pelos

parceiros, por motivos óbvios. No entanto, enquanto funcional, a experiência para o usuário pode ser menos satisfatória, e a carga na Microsoft para gerenciar todos esses usuários parceiros de certa forma faz uso intensivo de recursos.

Veja agora como funciona a extranet. Quando um cliente ou parceiro acessa um aplicativo, ele precisa inserir as suas credenciais. Durante a mesma sessão, se o usuário decidir acessar um recurso diferente, ele será solicitado novamente a inserir as suas credenciais. Isso continuará sempre que ele passar de um recurso para outro. Se o usuário tiver acessado um único aplicativo que usa vários recursos, como um banco de dados financeiro, ele precisaria autenticar cada recurso de forma independente. Isso pode ser uma experiência desgastante e complicada para os usuários.

Felizmente, ao usar os Serviços de Federação do Active Directory®, conseguimos solucionar o problema de várias autenticações com facilidade e isso se refletirá no seu uso. O ADFS é um componente do Windows Server® 2003 R2 que facilita a confiança entre duas ou mais empresas, a fim de permitir o compartilhamento de vários recursos e mantendo ao mesmo tempo a capacidade da empresa de gerenciar seu próprio conjunto de usuários. Nesta coluna, ilustrarei como a Microsoft pretende usar o ADFS para solucionar esse problema de extranet de vários recursos, o que lhe fornecerá mais informações necessárias para implementar uma solução semelhante. No entanto, antes de entrarmos em detalhes, veja a Figura 1 para se familiarizar com a terminologia básica do ADFS.

Figure 1 Terminologia do ADFS

Uma solução ADFS

Quando um usuário tenta acessar um aplicativo com conhecimento de ADFS, o navegador é enviado para o Recurso do Serviço de Federação (FS-R, Federation Service Resource) para descoberta de território. Aqui o usuário selecionará qual conjunto de credenciais utilizará para a duração da sessão. Com base na descoberta do cliente escolhido, o usuário será redirecionado para o servidor das Contas do Serviço de Federação (FS-A, Federation Service Accounts). É nesse servidor que o usuário receberá um token de conta válido (em um cookie) que está baseado nas credenciais que ele inserir no formulário de um Windows Live™ ID (anteriormente, uma conta Passport), a autenticação integrada do Windows ou autenticação SSL (consulte a Figura 2). Nesse modelo, fica a cargo das empresas individuais manter o seu próprio servidor de federação de conta. No caso dos servidores parceiros da Microsoft, a carga no Microsoft.com é removida para gerenciar cada conta no ambiente. É claro que se você implementar esse nível de responsabilidade, será necessário selecionar cuidadosamente as empresas com as quais você será federado e garantir que elas estejam gerenciando ativamente as informações da conta.

Figura 2** Fluxo de ADFS **(Clique na imagem para aumentar a exibição)

A próxima interrupção na rota é voltar para o servidor FS-R para alterar o token da conta para um token de recurso. Em nossa configuração, esse token contém uma lista completa de permissões das concessões do usuário por meio de um processo de mapeamento de declarações realizado no FS-R. Assim que o token for recebido, o usuário terá o recurso de logon único nos aplicativos com ADFS pelo tempo em que a sessão estiver aberta ou até 24 horas por padrão (essa janela é configurável). O resultado é que você terá SSO habilitado para esses aplicativos com ADFS, resultando em uma experiência mais protegida e eficiente para o cliente. Para obter uma orientação completa do processo de autenticação ADFS, consulte o artigo de Matt Steele, da edição de julho de 2006 da TechNet Magazine intitulado “Simplifique o logon único usando ADFS”.

Para manter a segurança dos recursos corporativos da Microsoft, isolamos o lado em contato com a internet da extranet do lado corporativo, o que significa que cada servidor é potencialmente de hospedagem dupla. Permitimos uma confiança unilateral aos usuários internos corporativos e utilizamos os servidores para fornecer a proteção necessária. Além disso, temos um domínio separado para o espaço da extranet, no qual fornecemos acesso aos recursos necessários para os usuários externos.

Duas áreas de maior preocupação durante a implementação foram as alterações no arquivo de diretiva do ADFS e balanceamento de carga. O balanceamento de carga foi um desafio em nível global e local. Inicialmente na produção utilizaremos o balanceamento de carga global a partir dos nossos parceiros CDN (Content Delivery Network, rede de fornecimento de conteúdo) Akamai ou Savvis para os agrupamentos de servidor front-end da Web em duas regiões. Isso garantirá disponibilidade do sistema para os usuários finais mesmo na improvável hipótese de um par de servidores regionais ficar offline. Isso é realizado com a automação de failover baseada nos serviços de verificação de integridade do servidor fornecidos pelos CDNs. Além disso, temos o recurso de adicionar facilmente mais agrupamentos no futuro. Como uma economia de custos, as nossas implantações pré-produção foram escolhidas para não usar o serviço CDN.

No nível regional emparelhamos os servidores para failover local por meio do agrupamento de balanceamento de carga de rede (NLB, network load balancing). Não estamos usando recursos especiais de balanceamento de carga, de forma que isso poderia facilmente ser realizado com hardware; no entanto, novamente estamos usando a NLB para economia de custo. Essa configuração fornecerá a estabilidade para garantir que mais de 99,9% de duração em todos os ambientes compatíveis.

Outro desafio que enfrentamos foi garantir que o arquivo de diretiva ADFS, o backbone do ADFS, fosse corretamente distribuído em todo o nosso ambiente e que as alterações a ele também fossem replicadas. Para realizar isso, aproveitamos outro recurso interno do Windows Server 2003 R2 – DFS-R (Distributed File System-Replication, replicação do sistema de arquivos distribuído), um novo mecanismo de replicação multimestre baseado em estado. Em cada um dos servidores de back-end habilitamos uma associação de grupo DFS-R com uma replicação de malha completa, de 24 horas. Agora, não importa onde ocorrer a alteração no arquivo de diretiva, ele será distribuído a todos os servidores. À medida que controlamos como podemos alterar o arquivo, temos um serviço estável e extremamente disponível.

Tentamos garantir que todas as alterações fossem feitas no snap-in do ADFS. No entanto, na prática detectamos que devemos atualizar esse arquivo de forma manual ocasionalmente. Quando atualizar manualmente é importante lembrar que o ADFS controla a versão desse arquivo. Por isso, você deve incrementar o arquivo de forma que as alterações sejam refletidas no ambiente:

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

Você também precisa se lembrar que, como todo XML, os arquivos de XML de diretiva diferenciam maiúsculas de minúsculas. Em todo o arquivo XML de diretiva há muitas referências a aplicativos ou outros servidores ADFS e em todos os casos eles devem ser copiados literalmente de servidor para servidor. Observe que os seguintes exemplos comuns em que o primeiro, RevocationCheckFlags, foi manualmente inserido e o segundo é uma URL de aplicativo confiável modificada da IU:

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

Para um nível adicional de segurança utilizamos outro componente de ADFS, o Proxy do Serviço Federado (FS-P, Federation Service Proxy), que garante que o FS-Rs permaneça uma camada removida do acesso direto de solicitações de entrada da Internet. Um modo exclusivo com o qual temos implementado proxies no Microsoft.com é por meio do uso de um único conjunto de proxies para hospedar vários ambientes ADFS em nossa área de pré-produção. Curiosamente, durante a adaptação inicial da tecnologia, detectamos que precisamos fazer uma simples modificação na chave do Registro para que isso ocorra. A chave está localizada no HKLM\Software\Microsoft\WebSSO. A simples alteração do valor do diretório inicial nessa chave permitirá que você use o proxy para vários ambientes. O padrão era:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

Para alternar ambientes, a chave seria mudada da seguinte forma:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

A criação de um arquivo em lote pode simplificar o gerenciamento desse processo. Infelizmente, a atual versão do snap-in MMC do ADFS não oferece suporte para alternar ambientes, pois há uma relação de um para um entre o proxy e o recurso ou o servidor de conta. Essa é a única forma de maximizar a utilização dos servidores de proxy. O resultado final é que isso é uma tremenda economia de custo, pois limita o número de servidores físicos necessários, independentemente de quantos ambientes diferentes você escolha hospedar.

A partir do ponto de vista da arquitetura, estamos executando o nosso ambiente de pré-produção com máquinas virtuais – outra medida de economia de custo. Isso elimina a necessidade de adquirir e acomodar seis servidores adicionais. Até o momento, não tivemos problemas de desempenho. No entanto, para atender à demanda significativamente aumentada no ambiente de produção, escolhemos usar as máquinas físicas de alto desempenho.

Não apenas para o Active Directory

Não somente o Microsoft.com está usando as contas do Active Directory para autenticação, mas também temos realizado com êxito a integração com as contas do Windows Live ID. Detectamos que ao usar o Windows Live ID (WLID) 4.5, podemos usar uma conta individual do Windows Live ID para delegar acesso aos recursos da Microsoft usando uma transformação de declaração personalizada. Isso é uma grande vitória para atingir a autenticação SSO, pois não precisamos mais de uma conta de domínio específica.

Desafios restantes

O maior desafio que estamos enfrentando agora é o gerenciamento do ADFS para compartilhar certificados de assinatura de token. Estamos utilizando certificados padrão que permanecem geralmente válidos por um ano antes de exigir renovação. No momento da renovação cada um dos servidores apropriados precisará ser atualizado, o que terá impacto significativo no FS-Rs. Embora seja parcialmente gerenciável com 15 ou 20 federações, a escala poderia ser imaginada como em torno de pelo menos centenas, e não milhares. Isso exigiria uma equipe em tempo integral para o gerenciamento de certificados SSL para um único ambiente. Temos várias equipes tentando descobrir os melhores métodos para automatizar essa solução mas ainda não definimos um curso de ação.

Outro desafio é que nem todos os aplicativos estão prontos para reconhecer o ADFS. Isso exigirá programação para que os sites aproveitem a oportunidade do ADFS. Estamos trabalhando junto com a equipe do Microsoft® Office SharePoint® Services para garantir que a próxima geração do SharePoint seja compatível com as necessidades de implementação do ADFS.

Conclusão

Há vários fatores a serem considerados ao se tomar a decisão de mudar para um modelo ADFS. Um é o número de recursos que os clientes acessarão. O processo de definir uma confiança federada entre as organizações pode ser uma tarefa trivial, mas exige tempo e esforço para gravar, revisar e executar as diretivas de acesso aceitáveis. Portanto, se você tiver somente um recurso, o qual será acessado pelos clientes, você precisará decidir se o esforço é válido. No entanto, como o número de recursos cresce, os benefícios também aumentam.

Se você estiver procurando por mais informações, consulte Visão geral do ADFS e Serviços de Federação do Active Directory: um caminho para o gerenciamento de acesso e identidade federada.

Jim Guthrie trabalha para a Microsoft na equipe de Operações do Microsoft.com Operations, na qual além de trabalhar com ADFS, ele é Engenheiro de sistemas com a equipe de Suporte à Plataforma de Portal Empresarial.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..