Este artigo foi traduzido por máquina.
Windows Azure AppFabric
Reintrodução do serviço Controle de Acesso do Windows Azure AppFabric
Vittorio Bertocci
Se você está procurando um serviço que facilita a autenticação e a autorização de usuários em seus sites e serviços Web, deve dar outra olhada no serviço Controle de Acesso do Windows Azure AppFabric (ACS), pois algumas atualizações importantes estão sendo implementadas (enquanto escrevo este artigo).
Abrir seu aplicativo para que seja acessado por usuários que pertencem a diferentes organizações e, ao mesmo tempo, manter altos padrões de segurança, sempre foi um desafio. Esse problema tem sido tradicionalmente associado a cenários comerciais e corporativos, embora os usuários normalmente residam em diretórios. O avanço dos sites de rede social como uma importante arena de atividades online faz com que seja cada vez mais interessante tornar seu aplicativo acessível para usuários de serviços como Windows Live ID, Facebook, Yahoo e Google.
Com o surgimento de padrões abertos, a situação está melhorando; no entanto, hoje, implementar esses padrões diretamente nos seus aplicativos e, ao mesmo tempo, fazer malabarismo com os protocolos de autenticação usados por todas essas diferentes entidades é um grande desafio. Talvez o mais difícil na implementação dessas coisas é que o trabalho nunca termina: os protocolos evoluem, novos padrões surgem e muitas vezes você é forçado a voltar e atualizar códigos de autenticação complicados repletos de criptografia.
O ACS simplifica bastante esses desafios. Em suma, o ACS pode funcionar como intermediário entre seu aplicativo e os repositórios de usuário (provedores de identidade ou IP) que armazenam as contas com as quais você deseja trabalhar. O ACS cuidará dos detalhes de menor importância relacionados à combinação de cada IP ao respectivo protocolo apropriado, protegendo o código do seu aplicativo para que ele não se preocupe em considerar os detalhes de cada tipo de transação. O ACS é compatível com inúmeros protocolos, como OpenID, OAuth WRAP, OAuth 2.0, WS-Trust e Web Services Federation. Com isso, você aproveita as vantagens de ter muitos IPs.
É fácil terceirizar a autenticação (e parte da autorização) da sua solução para o ACS. Tudo o que você precisa fazer é usar o Windows Identity Foundation (WIF) — a extensão para o Microsoft .NET Framework que aprimora aplicativos com recursos avançados de identidade e acesso — e seguir as instruções de um rápido assistente do Visual Studio. Normalmente isso pode ser feito sem precisar ver uma única linha de código!
Isso parece grego para você? Não se preocupe, você não está só; como sempre acontece quando se fala em identidade e segurança, é mais difícil explicar algo do que efetivamente fazê-lo. Vejamos um uso comum do ACS, terceirizar a autenticação do seu site para vários IPs da Web, e executar as etapas exigidas por esse procedimento.
Terceirizando a autenticação de um site para o ACS
Vamos começar com um site comum e autorizar os usuários a fazer logon usando uma conta do Google.
Antes de começar, vamos nos certificar de que os pré-requisitos foram atendidos. Aqui está o que precisamos:
- Visual Studio 2010
- Tempo de Execução do Windows Identity Foundation
- SDK do Windows Identity Foundation e um dos seguintes sistemas operacionais: Windows 7, Windows Server 2008, Windows Server 2008 R2 ou Windows Vista SP1
Embora não seja um requisito difícil, ter o IIS no computador é útil; se o IIS não estiver instalado, você terá precisará ajustar algumas etapas do passo a passo.
Apesar de o Visual Studio não exigir uma introdução, provavelmente ele ajudará a expandir um pouco o WIF (pronuncia-se “dub-IF”) e a entender por que é um pré-requisito. (Para ver uma explicação completa sobre o WIF, consulte o livro “Programming Windows Identity Foundation” [Microsoft Press, 2010]).
O WIF é uma extensão para o .NET Framework que oferece um novo modelo para lidar com autenticação e identidade de usuário, um modelo que dissocia seu aplicativo dos detalhes de como ocorre a autenticação. Os sistemas de autenticação tradicionais (como as APIS de provedor Membership do ASP.NET) forçam você a lidar com os detalhes de como é feita a autenticação. Isso exige que você utilize APIs de nível inferior para trabalhar com construções de nível inferior, como senhas, certificados e afins. O WIF muda tudo isso, porque oferece uma abstração prática que permite especificar uma entidade externa para processar a autenticação de usuários. Com a autenticação baseada em formulários, você especifica uma determinada página (geralmente login.aspx) para a qual as solicitações são redirecionadas sempre que o chamador ainda não está autenticado. Com o WIF, é possível convocar uma entidade externa (um IP) que será chamada sempre que um usuário precisar de autenticação. As maneiras como o IP é escolhido no tempo de design e combinado no tempo de execução seguem protocolos bastante conhecidos. O WIF se encarrega de descobrir quais protocolos devem ser utilizados e de impor as diretivas de comunicação devidamente. Novamente, é muito mais fácil mostrar do que explicar isso.
Criar a solução inicial
Abra o Visual Studio. Crie um novo site selecionando Arquivo | Novo | Site. Vamos criar um novo site ASP.NET — mas primeiro veja se você selecionou o local na Web como “HTTP” e se configurou a URL para que execute no IIS (veja a Figura 1). Isso vai assegurar uma execução tranquila quando forem usadas as ferramentas do WIF. Se o protocolo HTTPS estiver disponível no servidor Web, é uma boa ideia usá-lo; embora não seja estritamente necessário para este passo a passo, ele é altamente recomendável em sistemas de produção e evitará alguns avisos do WIF.
Figura 1 Selecionando um site do ASP.NET com HTTP como o local
Quando pressionar F5, você verá que tem um site ASP.NET básico e, ao clicar no link para fazer logon, terá de informar um nome de usuário e uma senha. É isso que vamos alterar — em vez de usar um nome de usuário e uma senha e processar a autenticação diretamente no site, vamos utilizar o WIF para terceirizar a autenticação para o ACS. O ACS, por sua vez, nos dará acesso a IPs externos.
Configurar um projeto do ACS
Para começar, precisamos criar um projeto no portal LABS do Windows Azure AppFabric. O portal LABS é um ambiente configurado especificamente para permitir que a comunidade acesse os bits iniciais. Não há custo associado ao LABS do AppFabric, mas também não existem contratos de nível de serviço nem garantias.
Abra o navegador e vá para portal.appfabriclabs.com. Você deverá fazer logon com seu Windows Live ID. Uma vez conectado, você terá de criar um novo projeto — clique no link “criar um projeto”. Você deverá escolher um nome de projeto — escolha algo apropriado e clique em OK. Uma vez concluído o procedimento, você verá um nome de projeto ativo (no nosso exemplo, “acsdemoproject”) — clique nele (veja a Figura 2).
Figura 2 Criando um projeto no portal LABS do Windows Azure AppFabric
Para que você possa terceirizar a autenticação para o ACS, é preciso definir um namespace de serviço. O namespace de serviço disponibiliza sua parte do ambiente LABS do AppFabric e — para o ACS — o componente exclusivo para todos os URIs dos recursos que você usará quando interagir com o ACS a partir do seu aplicativo. Você pode controlar todo o conteúdo do namespace de serviço. Clique em “Add Service Namespace”, especifique um nome, escolha uma zona — no LABS só é possível selecionar “United States (South/Central)” — e clique em Create. Os URIs utilizados pelo AppFabric estão disponíveis na Internet pública e servem exclusivamente para identificar serviços; portanto, você deve escolher um namespace que não tenha sido selecionado.
Levará alguns minutos, mas, depois que o namespace de serviço for ativado, você poderá clicar no link “Access Control” para começar a configurar o ACS para seu site.
Agora você concluiu o trabalho no portal de gerenciamento, onde pode configurar o ACS para seus sites (veja a Figura 3).
Figura 3 O portal de gerenciamento do serviço Controle de Acesso do Windows Azure AppFabric
Clique no botão “Manage” para começar. O portal de gerenciamento apresenta algumas etapas passo a passo para você começar, e é exatamente isso o que vamos fazer.
Escolhendo os provedores de identidade desejados
Clique no link “Identity Providers”. Aqui vamos configurar os diversos IPs sociais que queremos aproveitar no seu aplicativo. Por padrão, o Windows Live ID está na lista; vamos adicionar suporte para contas do Google.
Clique no link “Add Identity Provider”, que mostrará uma lista de provedores. Clique no botão “Add” ao lado de Google. You can specify a custom image URL for the IP, but go ahead and just click “Save.” Just like that, we’ve added Google as a recognized source of user identities.
Fazendo com que o ACS reconheça seu site
Agora que nossos IPs foram configurados, precisamos fornecer informações sobre nosso site para o ACS. No jargão de identidade, costumamos nos referir aos aplicativos como “partes confiáveis”, uma expressão que faz alusão ao fato de que o aplicativo conta com um ou mais IPs para cuidar da autenticação em seu nome. A interface de usuário do ACS é consistente com esta terminologia.
Click the “Relying Party Applications” URL, and then “Add Relying Party Application.” Let’s specify the following information:
- Nome: Meu Site
- Realm: https://localhost/Site/
- URL de retorno: https://localhost/Site/
- Formato do token: SAML 2.0:
- Autenticação do token: Certificado de namespace de serviço de usuário (comum)
O campo de formato do token merece no mínimo uma breve explicação (discutiremos esse tópico mais detalhadamente ainda neste artigo). Um token é um artefato — normalmente um fragmento XML ou algo em outro formato de serialização — utilizado por IPs para indicar que uma operação de autenticação ocorreu com êxito. Quando um usuário é autenticado, seja qual for o sistema escolhido pelo IP, o navegador é redirecionado para o ACS com um token que certifica que o usuário foi reconhecido. O formato do token e o protocolo usado serão determinados de acordo com o IP. O ACS examinará o token e, se considerá-lo satisfatório (falaremos mais sobre isso mais adiante), emitirá um novo token próprio e o enviará de volta para o aplicativo. As configurações alteradas nesta etapa determinam o formato de token que o ACS deverá usar para se comunicar com o aplicativo. O ACS é capaz de emitir três tipos de tokens — SAML2.0, SAML1.1 e SWT — que representam diferentes contrapartidas entre força expressiva, segurança, aplicabilidade para certos tipos de cliente e assim por diante. Escolha o SAML2.0; os detalhes não são fundamentais nessa etapa.
É importante que o realm corresponda à URL do site que criamos anteriormente. Uma vez que ocorrer a autenticação com o IP escolhido, o ACS redirecionará o usuário de volta para o site usando a URL especificada aqui. Por padrão, a opção “Create New Rule Group” fica selecionada — vamos utilizá-la na próxima etapa. Clique em “Save” quando terminar e volte ao portal de gerenciamento.
Adicionando regras
Regras são construções interessantes que propiciam controle refinado das informações de identidade dos usuários. O cenário que estamos habilitando agora, no entanto, não requer uso explícito de regras para permitir o logon com diversos IPs. Assim, adiaremos todas as explicações sobre regras para uma seção mais adiante no artigo, onde elas são realmente providenciais; aqui vamos tratar somente das configurações padrão.
Clique no link “Rule Groups”. Você deverá ver o grupo de regras criado quando adicionamos o aplicativo de parte confiável (“Default Rule Group for My Website”). Selecione esse grupo de regras, clique no link “Generate Rules”, verifique se tanto o Google quanto o Windows Live ID estão selecionados e clique no botão “Generate” — isso é tudo o que você precisa fazer em relação às regras neste cenário.
Coletando endereços de metadados de Web Services Federation
Nessa etapa, concluímos a configuração do ACS. Porém, antes de voltarmos ao Visual Studio, vamos capturar algumas informações da página Application Integration. Clique no link “Application Integration” e copie a URL de “WS-Federation Metadata” — vamos usá-la com o WIF para configurar nosso site.
Sem entrar em muitos detalhes, o documento de metadados de Web Services Federation é uma descrição legível em máquina de como o ACS processa a autenticação. Seu aplicativo precisará dele para ser configurado a fim de terceirizar a autenticação para o ACS.
Configurando o site para usar o ACS
Volte para o Visual Studio e o seu site. Agora queremos usar o WIF para terceirizar a autenticação para o ACS, que por sua vez autoriza contas do Google a acessar seu aplicativo. In the Solution Explorer, right-click the Web site project and select “Add STS Reference.” This will launch the Federation Utility wizard, which will configure the Web site to use WIF as the authentication mechanism and the ACS as the authenticating authority. STS quer dizer “Security Token Service” (Serviço de Token de Segurança), que indica um tipo especial de serviço Web ou de página da Web que oferece um ponto de entrada para solicitar tokens; normalmente cada emissor de token ou IP usa um.
Você só precisa clicar em “next” na maioria das vezes; o número de etapas em que é preciso inserir informações é muito pequeno. Advance to the “Security Token Service” step, and specify “Use an existing STS.” Paste the federation metadata URL you copied from the ACS portal (see Figure 4).
Figura 4 Iniciando o assistente do utilitário de federação no Visual Studio
Nele, mantenha os padrões, clique até o final e selecione Finish. O assistente adicionará todos os assemblies WIF necessários, alguns arquivos do site e, o mais importante, atualizará web.config com as informações necessárias para se associar ao ACS no momento da autenticação.
Testando o fluxo de autenticação
Finalmente chegou a hora de experimentar o recém-criado site protegido! Pressione F5. Você será imediatamente redirecionado para a página Home Realm Discovery, que permite ao usuário escolher entre os IPs que configuramos anteriormente no portal de gerenciamento do ACS (veja a Figura 5).
Figura 5 A página Home Realm Discovery
Depois que você selecionar Google e inserir as credenciais da sua conta do Google, verá uma página de aprovação que solicita autorização de acesso do projeto do ACS — é importante entender isso, porque não é o site que pede permissão, mas sim o ACS (veja a Figura 6).
Figura 6 O Serviço de Controle de Acesso do Windows Azure AppFabric pedindo permissão para obter informações do Google
Depois que você autorizar o acesso para o ACS, será reconduzido ao site (veja a Figura 7). Pronto — você está conectado!
A Figura 7 **sucesso!**Fazer logon no site da Web
Para verificar se a mesma experiência funcionaria com o Windows Live ID, o outro IP configurado no namespace, tudo o que você precisa fazer é fechar o navegador, pressionar F5 novamente e, na página Home Realm Discovery, escolher Windows Live ID em vez de Google.
Se você tem alguma experiência na ativação de protocolos de autenticação em sites, sabe que, tradicionalmente, adicionar um IP significa estudar seus protocolos e a API, escrever um código razoavelmente complexo e testar, testar e testar até acertar. E cada IP adicional exige o mesmo processo, além da dificuldade extra de detectar, com base na solicitação, qual protocolo está sendo usado.
Aqui não precisamos fazer nada disso; na verdade, talvez você tenha percebido que não escrevemos sequer uma linha de código. Se quisermos adicionar outros provedores de identidade, tudo o que temos de fazer é passar por algumas telas no portal de gerenciamento do ACS, sem afetar nada no aplicativo propriamente dito. Se os IPs mudarem seus protocolos, o ACS alterará seu código para acomodar as novas condições, e nosso aplicativo nem mesmo saberá que algo foi modificado.
O ACS: estrutura e recursos
Agora que você teve uma oportunidade de experimentar a força do ACS em primeira mão, está pronto para uma breve visão geral do serviço e o que o faz funcionar. Isso exigirá um pouco de teoria, mas você irá descobrir que já aprendeu a maior parte do conteúdo necessário ao longo do cenário descrito anteriormente.
O ACS funciona de acordo com os princípios de identidade baseada em declarações. A principal ideia por detrás desse conceito é que cada entidade em uma transação com identidades desempenha um ou mais funções canônicas, extraídas de uma lista de quatro itens: requerente, provedor de identidade (IP), parte confiável (RP)e provedor de federação (FP). No passo a passo, você viu tudo isso em ação. A interação entre essas entidades se resume a solicitar, obter e encaminhar tokens de segurança, como ilustrado na Figura 8.
Figura 8 Solicitando, obtendo e encaminhando tokens de segurança
O requerente é a função desempenhada pelo usuário, ou seja, a entidade que precisa ser autenticada. O IP é a entidade que armazena a conta do requerente: nome de usuário, credenciais, atributos e assim por diante. O IP usa um ou mais STSs para expor seus recursos de autenticação e emitir tokens. A RP é o aplicativo que o requerente deseja usar. Essas três funções são suficientes para descrever o caso mais básico: o requerente obtém um token de um IP em que a RP confia, usa esse token com a RP e a autenticação é feita.
Algo que não mencionamos durante o passo a passo é que os tokens não só representam o resultado bem-sucedido da operação de autenticação, como também são usados para transportar atributos que descrevem o usuário: nome, endereços de email, funções e tudo o mais que a RP precisa saber e que o IP disponibiliza. Se você se lembra das propriedades de tokens de segurança assinados, verá que esses atributos não podem ser violados e criptograficamente têm garantia de serem originados de um determinado IP. Isso significa que uma RP pode escolher considerar válidos os atributos que recebe conforme o grau de confiança que ela tem no IP que os originou. Pense em situações da vida real em que você precisa provar algo, por exemplo, que reside em um certo endereço. Com frequência as empresas pedem para você fornecer uma conta de concessionária de serviços públicos, principalmente porque confiam na concessionária mais do que em você. As informações são as mesmas (o endereço), mas o IP que as produziu faz toda a diferença.
Quando um atributo é emitido como parte de um token de segurança, o chamamos de declaração. Esse conceito é tão importante que dá o nome da abordagem inteira, e praticamente tudo o que o ACS faz gira em torno de declarações. Só precisamos ver outro conceito e então passaremos para os detalhes.
Embora seja possível usar as funções de requerente-RP-IP para modelar cada sistema, na prática isso não é muito útil. Se uma RP confia em vários IPs, como aconteceu em nosso cenário, o modelo exigiria que a RP mantivesse várias relações, lidasse com diferentes protocolos e assim por diante. É nesse ponto que a quarta função, FP, entra em cena. Um FP é um intermediário entre uma ou mais RPs e um ou mais IPs, como ilustrado na Figura 9.
Figura 9 O provedor de federação como um intermediário
O FP confia em vários IPs, comportando-se como um aplicativo e esperando tokens dos IPs. A RP, por sua vez, confia no FP; para isso, o FP expõe seu próprio STS, que emite tokens para a RP. O FP cuida dos detalhes da associação aos diversos IPs, ao mesmo tempo em que sempre apresenta para a RP a mesma fachada, por isso os IPs podem ser integrados e desconfigurados sem afetar a RP. O FP também pode transformar as declarações vindas de diferentes IPs para torná-las mais úteis para a RP. Ele pode normalizar diferentes tipos de declarações recebidas, adicionar declarações extra, como funções e permissões, entre outros.
Como você pode ter adivinhado, o ACS desempenha a função do FP, como ilustrado na Figura 10.
Figura 10 O serviço Controle de Acesso do Windows Azure AppFabric desempenhando a função do provedor de federação
Quando você cria um namespace de serviço, obtém seu próprio FP completo na nuvem. De imediato, esse FP inclui quatro diferentes pontos de extremidade STS, todos oferecendo diferentes protocolos que são apropriados para diferentes tipos de aplicativos: WS-Federation para entrar em sites; WS-Trust para chamar serviços Web SOAP; OAuth WRAP e OAuth 2 para serviços Web REST e APIs da Web em geral. Esses são os pontos de extremidade que você usa para configurar o aplicativo a fim de terceirizar a autenticação.
O ACS já está pré-configurado para confiar em vários IPs da Web, como vimos, e isso facilita a experiência de escolher entre eles, pois são fornecidas páginas ou código que pode ser incorporado. Além disso, o ACS pode estabelecer confiança com IPs comerciais, como os Serviços de Federação do Active Directory 2.0 (AD FS 2.0), que expõem pontos de extremidade STS. Na prática, o ACS expõe a contrapartida da funcionalidade “Add STS reference” que você viu quando configurou o site para confiar no ACS. Usar o AD FS 2.0 como IP é muito interessante, pois ele permite reutilizar contas de usuário sempre que você desejar, incluindo aquelas em aplicativos hospedados pelo Windows Azure que tradicionalmente seriam válidas apenas localmente. Outro recurso interessante dos IPs comerciais é que normalmente eles oferecem conjuntos de declarações mais ricos que podem ser utilizados para adicionar uma sofisticada lógica orientada por identidade no processamento de token.
O ACS permite descreve seu logon para transformação de declarações na forma de regras, um mecanismo simples mas eficiente. Por exemplo, é possível atribuir uma função a um usuário com a mesma facilidade de inserir algo nos moldes de “se a declaração do identificador de nome recebido tiver o valor X, adicione uma declaração de saída de função de tipo e valor Y”.
Toda a funcionalidade discutida aqui pode ser acessada através do portal de gerenciamento usado no passo a passo; como alternativa, há um serviço de gerenciamento baseado em Odata que proporciona controle total das configurações do ACS e, ao mesmo tempo, se integra aos seus processos existentes.
Por mais trivial que pareça, nós descrevemos apenas superficialmente o que o ACS pode fazer por você. Você está convidado a conferir o laboratório prático do kit de treinamento para desenvolvedor de identidade e o kit de treinamento da plataforma Windows Azure para explorar outros cenários com mais detalhes. Se você deseja simplificar o gerenciamento de acesso do seu site, serviço Web ou API da Web, o ACS pode ajudar!
Vittorio Bertocci is a senior architect evangelist in the Developer and Platform Evangelism team and a member of the extended engineering team that produces Microsoft claims-based platform components. He’s responsible for identity evangelism for the .NET developer community and drove initiatives such as the Identity Developer Training Kit and the IdElement show on Channel 9. He recently wrote “Programming Windows Identity Foundation” (Microsoft Press, 2010).
Wade Wegner is a senior technical evangelist at Microsoft, responsible for influencing and driving Microsoft’s technical strategy for the Windows Azure platform. You can reach him through his blog at wadewegner.com or on Twitter at twitter.com/WadeWegner.
Meus agradecimentos aos seguinte especialista técnico para revisar este artigo: Kent Brown