Exportar (0) Imprimir
Expandir Tudo

Adicionar logon ao seu aplicativo Web usando o Azure AD

Atualizado: maio de 2014

noteObservação
Este exemplo está desatualizado. Sua tecnologia, métodos e/ou instruções da interface do usuário foram substituídos por recursos mais novos. Para ver um exemplo atualizado para criar um aplicativo semelhante, consulte WebApp-OpenIDConnect-DotNet.

.

Esse passo a passo mostrará como usar o AD do Azure para implementar o logon único da Web em um aplicativo ASP.NET. As instruções se concentrarão em aproveitar o locatário do diretório associado à sua assinatura do Azure, pois isso constitui a escolha óbvia de provedores de identidade para aplicativos LOB (linha de negócios) em sua própria organização.

Uma solução de logon único da Web geralmente envolve a configuração de um aplicativo Web para terceirizar suas funções de autenticação para uma entidade externa, comumente mencionada como Provedor de Identidade (IdP). Em termos concretos, isso significa que o aplicativo será configurado para redirecionar solicitações não autenticadas para o IdP, de acordo com algum protocolo de logon, como o SAML-P, Web Services Federation ou OpenID Connect.

A autoridade (ou IDP) manipula a experiência de autenticação e, geralmente, requer que o aplicativo Web já seja conhecido por meio de algum processo de provisionamento. Depois da autenticação bem-sucedida, o navegador é redirecionado de volta para o aplicativo Web, juntamente com um token de segurança que têm informações sobre o usuário que está entrando. O aplicativo valida o token (geralmente através de algum middleware de reconhecimento de identidade), e se a verificação for bem-sucedida, o usuário será considerado autenticado e conectado.

Essa descrição de alto nível também se aplica ao AD do Azure. Este documento lhe mostrará como usar as classes do Visual Studio 2012 e do Windows Identity Foundation (WIF) no .NET Framework 4.5 para configurar um aplicativo MVC 4 para usar um protocolo de logon da Web. Ele mostrará como provisionar o mesmo aplicativo em um locatário do AD do Azure e como configurar as definições de logon do aplicativo para conectar-se a esse locatário. No final do passo a passo, você terá um aplicativo da Web funcionando totalmente configurado para o logon único organizacional.

O objetivo deste passo a passo é ajudar você a entender como o AD do Azure funciona: isso exige ir um pouco mais além para montar a solução simplificada descrita aqui. Além de apresentar as instruções concretas para criar um exemplo de trabalho, o documento também apresentará artefatos e conceitos que serão úteis para que você conheça o AD do Azure e entenda como aproveitar os seus recursos fora do cenário específico discutido aqui. Essas seções extras, formatadas como notas de caixa, não são estritamente necessárias para executar o passo a passo. Porém, se tiver interesse em usar o AD do Azure em suas próprias soluções, será recomendável ler essas partes também.

Esta parte do tutorial deste documento está organizada nas seguintes seções:

  • Pré-requisitos: esta seção lista todos os requisitos que devem ser cumpridos para você concluir o passo a passo.

  • Arquitetura da solução: essa seção fornece uma introdução de alto nível que explica como funciona uma solução de SSO da Web para aplicativos LoB (linha de negócios). Vamos examinar os componentes funcionais que formam o SSO, a criação da estrutura que você vai concretizar mais tarde seguindo as instruções do documento.

  • Trabalhando com seu locatário do diretório do Azure AD: essa seção apresenta os locatários do AD do Azure e os recursos necessários neste cenário. Ela também descreverá brevemente os principais elementos da seção Active Directory do Portal de Gerenciamento do Azure.

  • Conectar o aplicativo ao AD do Azure: essa seção mostra como usar as Ferramentas de Identidade e Acesso do Visual Studio 2012 para permitir o logon único da Web no aplicativo MVC e conectar as configurações de autenticação ao locatário escolhido específico do AD do Azure.

  • Tópicos avançados: essa seção vai além do básico, aprofundando em alguns tópicos importantes e abrangendo algumas das outras tarefas que talvez você precise executar para levar o aplicativo para o próximo nível.

Os pré-requisitos a seguir são necessários para concluir este tutorial:

Se você tiver perguntas ou precisar de ajuda, consulte Preparing for Azure AD Solutions and Scenarios

Arquitetura do aplicativo de locatário único

Este passo a passo se concentra no seguinte cenário: um desenvolvedor tem um aplicativo Web que planeja implantar na nuvem e ele quer que somente usuários de um locatário do Active Directory do Azure tenham acesso. Para conseguir isso, ele vai precisar:

  1. Registrar o aplicativo da Web em seu locatário do AD do Azure. Depois que o aplicativo se tornar conhecido, o AD do Azure aceitará as solicitações dos usuários para se autenticarem.

  2. Adicionar algo na frente do aplicativo, de modo que:

    1. As solicitações não autenticadas possam ser bloqueadas e redirecionadas para o locatário do AD do Azure correto para autenticação do usuário

    2. Os usuários que se autenticarem com o AD do Azure possam ser reconhecidos e receber acesso

Nós implementaremos o primeiro passo trabalhando com o Portal de Gerenciamento do Azure. Você vai aprender a provisionar um novo locatário do AD do Azure em sua assinatura do Azure e a operar os recursos do Portal de Gerenciamento do AD do Azure para registrar um aplicativo.

A Etapa 2 pode ser implementada usando uma variedade de protocolos de alto nível cuja intenção é permitir operações de autenticação pelas fronteiras organizacionais ou até mesmo pela Internet.

Na plataforma .NET, o segundo passo resume a configuração das classes que o .NET oferece pronta para uso para funcionar com identidade baseada em declarações e autenticação federada. Essas classes são coletivamente conhecidas como Windows Identity Foundation (WIF) e incluem módulos HTTP e definições de configuração que podem ser usadas para adicionar a camada de intercepção que executa as tarefas de redirecionamento e autenticação apresentadas no passo 2. O Visual Studio 2012 oferece ferramentas para ajudar a configurar automaticamente aplicativos Web para usar o WIF para terceirizar a autenticação de autoridades externas que suportam protocolos de SSO da Web específicos, como o Web Services Federation. Este passo a passo mostrará como usar essas ferramentas com o AD do Azure.

O Active Directory do Azure é o serviço que fornece a estrutura de identidade de ofertas da Microsoft, como o Office 365 e o Windows Intune. Se assinar esses serviços e desejar reutilizar o locatário do diretório associado a esse serviço, crie uma nova assinatura do Azure e use o recurso Adicionar Usuário para adicionar um administrador desse locatário. Este passo a passo não dará orientações detalhadas sobre o processo.

Cada assinatura tem um locatário do AD do Azure e um diretório associado. Se o locatário tiver sido gerado automaticamente, o diretório será denominado Diretório padrão, mas você pode mudar o nome. Nesta parte do passo a passo, vamos adicionar um usuário ao diretório e, depois, adicionar um aplicativo.

Quando um locatário de diretório é criado, ele é configurado para armazenar usuários e credenciais na nuvem. Para obter instruções detalhadas sobre como integrar o seu locatário de diretório com a implantação no local do Active Directory do Windows Server, consulte Integração de diretório.

Se você tiver perguntas ou precisar de ajuda, consulte Preparing for Azure AD Solutions and Scenarios

Os cenários e soluções do AD do Azure (e nossos exemplos de código e aplicativos de exemplo) exigem uma conta de usuário no domínio do seu Active Directory do Azure. Se você tentar entrar nos aplicativos com uma conta da Microsoft, como uma conta do Hotmail.com, Live.com ou Outlook.com, o logon falha. Se você já tiver um usuário com uma conta em seu domínio do Active Directory, como uma conta Usuário@Contoso.onmicrosoft.com, você pode usá-lo para entrar nesse caso. Caso contrário, você precisará criar um novo usuário.

  1. Vá para o Portal de Gerenciamento do Microsoft Azure(https://manage.WindowsAzure.com), entre e, em seguida, clique em Active Directory. (Dica de solução de problemas: o item "Active Directory" está ausente ou indisponível)

  2. Se o seu diretório se chamar "Diretório padrão", adicione um diretório, como "EngenhariaContoso". Para adicionar um diretório, na parte inferior da página do Active Directory, clique em Adicionar e siga as instruções para adicionar um novo diretório.

  3. Clique duas vezes no diretório e clique em Domínios. Ao criar suas contas de usuário, use o nome de domínio que aparece na página. Por exemplo, se o seu domínio for EngenhariaContoso@onmicrosoft.com, crie nomes de usuário nesse domínio, como Teste@EngenhariaContoso@onmicrosoft.com.

  4. Para criar uma conta de usuário no domínio, clique em Usuários. Caso não veja uma guia Usuários, clique duas vezes no nome do diretório. Uma guia Usuários aparece em cada página específica do diretório. Na parte inferior da página, clique em Adicionar usuário.

  5. Selecione Novo usuário em sua organização. Adicione um usuário em seu novo domínio, como Teste@EngenhariaContoso.onmicrosoft.com e clique na marca de seleção na parte inferior da página.

    Inserir o nome de usuário e o domínio
  6. Na página Perfil do usuário, atribua uma função organizacional ao usuário. Para testar, é melhor ter pelo menos um usuário com a função Administrador Global e um usuário com a função Usuário.

    Inserir a função de usuário

No último passo, o Portal de Gerenciamento do Azure gera uma senha temporária que o usuário usa para entrar pela primeira vez. Depois de entrar pela primeira vez, o usuário deve alterar a senha temporária. Lembre-se de salvar a senha temporária, pois vamos precisar dela para testar o cenário.

Nesse ponto, temos um locatário de diretório com um usuário válido para fornecer uma autoridade de autenticação em nosso cenário de logon único da Web.

Senha temporária

  1. Vamos começar nosso trabalho com os bits de aplicativos. Abra o Visual Studio, clique em Novo Projeto e selecione Aplicativo Web ASP.NET MVC 4. Na janela Novo projeto ASP.NET MVC 4, selecione Aplicativo Intranet, certifique-se de que o mecanismo de exibição esteja definido como Razor e clique em OK. Neste passo a passo, usaremos ExpenseReport como nome do projeto.

    noteObservação
    Este passo a passo pressupõe que a sua instalação do Visual Studio está configurada com as definições padrão. Se tiver alterado algumas das configurações básicas (como o local em que os aplicativos Web estão hospedados no momento do desenvolvimento), você terá de ajustar as instruções adequadamente.



    Novo projeto no Visual Studio

    É possível aplicar as instruções deste passo a passo a qualquer aplicativo Web VS 2012 existente, MVC ou Web Forms, desde que você não tenha nenhuma lógica que altere significativamente o pipeline de processamento de solicitação ASP.NET. Porém, para simplificar, estamos criando aqui um novo projeto a partir do zero.

    noteObservação
    Este passo a passo fornece instruções detalhadas sobre como configurar uma solução .NET. Entretanto, os mesmos resultados podem ser obtidos ao segmentar de outras plataformas e pilhas de programação. O AD do Azure usa protocolos abertos em seus recursos de logon da Web, e todas as plataformas principais possuem bibliotecas e ferramentas que suportam esses protocolos. As etapas detalhadas terão de ser ajustadas para acomodar a sintaxe e as práticas de cada pilha, mas a subdivisão de tarefas de alto nível será aplicada globalmente.

    O Visual Studio cria um novo projeto MVC para você, já configurado para ser executado no IIS Express: não vamos adicionar novas funcionalidades a ele, pois os padrões são suficientes para demonstrar como adicionar logon da Web. A única exceção a isso é o ponto de extremidade usado pelo aplicativo. Por padrão, o Visual Studio configura o seu aplicativo para oferecer conteúdo por HTTP: mas isso não seria adequado para estabelecer sessões seguras, pois isso deixaria as comunicações desprotegidas e permitiria que possíveis atacantes roubassem cookies e tokens. Isso não é obrigatório durante a fase de desenvolvimento, pois o Azure não vai aplicar rigorosamente o uso de HTTPS. Porém, essa é uma prática recomendada.

  2. O IIS Express facilita ativar o HTTPS diretamente do Visual Studio. Selecione o seu projeto no Gerenciador de Soluções e, depois, no painel Propriedades, mude SSL Habilitado para True.

    Você vai ver que a URL de SSL, antes vazia, será preenchida com um novo endereço. Selecione-a e a copie para a área de transferência.



    Copiar URL de SSL

  3. Agora precisamos informar o Visual Studio que sempre queremos usar o ponto de extremidade de HTTPS durante a depuração. Volte para o Gerenciador de Soluções, clique com o botão direito do mouse no projeto e escolha Propriedades. Selecione a guia Web à esquerda, role para a opção Usar servidor Web local IIS e cole a URL HTTPS URL no campo URL do projeto. Salve as configurações (Ctrl + S) e feche a guia Propriedade.



    Alterar URL do projeto

    Neste ponto, temos um aplicativo que está pronto para ser configurado para aproveitar o AD do Azure para logon. O próximo passo será informar o seu locatário do AD do Azure sobre esse aplicativo específico.

  1. Minimize o Visual Studio e volte para a guia Active Directory no Portal de Gerenciamento do Azure. No início do passo a passo, trabalhamos na área de Usuários; agora, vamos trabalhar na área de Aplicativos. Na parte superior da página, clique em Aplicativos.



    Aplicativos Integrados

    Essa área lista os aplicativos que estão registrados no seu locatário de diretório. Um aplicativo é considerado registrado em um locatário quando:

    • O aplicativo tem uma entrada no diretório que descreve as suas coordenadas principais: nome, pontos de extremidade associados, etc.. Mais detalhes posteriormente.

    • O aplicativo em si tiver recebido permissão para executar alguma operação no locatário do diretório atual: as operações vão desde solicitações de token de sessão até a capacidade de consultar o diretório. Novamente, veremos mais detalhes posteriormente.

    ImportantImportante
    Nenhum aplicativo pode utilizar o AD do Azure sem ter sido registrado: isso se deve tanto a motivos de segurança (somente aplicativos que o administrador aprova devem ser permitidos), como a considerações práticas (a interação com o AD do Azure infere o uso de protocolos abertos específicos que, por sua vez, exigem o conhecimento de parâmetros importantes que descrevem o aplicativo).

  2. Como acabamos de criar esse locatário de diretório do zero, a lista de aplicativos registrados ainda está vazia. Na verdade, a primeira entrada vai ser para o aplicativo que acabamos de criar no Visual Studio: esta seção será totalmente dedicada ao seu registro como um aplicativo.

    Considerando que este é o primeiro aplicativo, inicie o processo clicando no botão Adicionar na barra de comandos do Portal de Gerenciamento do Azure, na parte inferior da tela. Em seguida, você será solicitado com a tela abaixo:



    Conte-nos sobre o seu aplicativo

    O processo de registro de um aplicativo pelo Portal de Gerenciamento do Azure é estruturado como um assistente clássico, em que as telas subsequentes dividem a coleta das informações necessárias de acordo com as suas escolhas.

    A figura acima mostra a primeira dessas telas. As opções oferecidas são diretas:

    • Nome para exibição: o texto digitado aqui é usado como apelido legível para se referir ao aplicativo sempre que um usuário (seja um administrador que gerencie a lista de aplicativos registrados ou um cliente que queira conceder acesso ao aplicativo acesso ao diretório) precisa executar uma ação. Há mais informações sobre isso no documento Desenvolvendo aplicativos Web multilocatário com o Azure AD.

    • Tipo de acesso: esse conjunto de botões de opção permite que você especifique quais operações do aplicativo devem ser autorizadas a operar em relação ao locatário do diretório. Para a finalidade deste tutorial, em que o nosso objetivo é simplesmente configurar o logon da Web com o nosso aplicativo, a escolha adequada é Logon único.

      noteObservação
      Outros documentos vão se aprofundar mais no assunto de permissões de aplicativos. Mas, aqui, vamos abordar brevemente os princípios por trás dele, caso você queira saber o que acontece nos bastidores.

      O AD do Azure representa aplicativos usando uma entidade chamada ServicePrincipal. Como o nome sugere, eles são análogos às entidades de usuário mais conhecidas, mas foram criados com objetivo de descrever aplicativos.

      O ato de registrar um aplicativo é, na prática, a criação de um ServicePrincipal para o aplicativo no locatário da instância de diretório que o aplicativo deve acessar.

      O nível de acesso que deve ser concedido a cada aplicativo é determinado pelas funções correspondentes a que o ServicePrincipal pertence. Neste passo a passo, você não precisa escolher os níveis de acesso de leitura e gravação. Porém, se precisasse, o fluxo de registro acrescentaria alguns passos adicionais para coletar mais informações, como quais teclas usar para autenticar ao executar essas consultas: nesse caso, as teclas também teriam de ser armazenadas na ServicePrincipal que descreve o aplicativo. O tópico Usar a Graph API para consultar o Azure AD tem mais informações sobre isso.

      As permissões concedidas pelo processo de registro do aplicativo têm efeito somente ao acessar o diretório em si. Elas não determinam as políticas de acesso para outros recursos do Azure, como os bancos de dados do SQL Azure, as seções do Portal de Gerenciamento e outros semelhantes.

  3. Uma vez inserido o nome do aplicativo e escolhido o tipo de acesso de Logon único, clique na seta no canto inferior direito para ir para a próxima tela.

    Propriedades do aplicativo Nesta tela, o Portal de Gerenciamento do Azure reúne coordenadas importantes que o serviço precisa para impulsionar o fluxo de protocolo de logon. Veja o que você precisa inserir:

    • URL de aplicativo: esse parâmetro representa o address do seu aplicativo Web. Neste exemplo, isso corresponde a https://localhost:44341/, o endereço atribuído pelo IIS Express ao seu aplicativo. Se tiver seguido as instruções exatas até agora, ele ainda estará na área de transferência, pronto para ser colado. O valor inserido funcionará durante a fase de desenvolvimento: uma vez que implantar seu aplicativo no estágio ou no ambiente de produção desejado, você terá que voltar ao Portal de Gerenciamento e modificar o endereço para que ele corresponda à localização do novo aplicativo. Discutiremos como fazer isso posteriormente no passo a passo.

      WarningAviso
      O AD do Azure precisa conhecer o endereço do seu aplicativo de modo que, depois que um usuário for autenticado com êxito nas páginas do AD do Azure, ele possa redirecionar o fluxo de volta para o seu aplicativo.

      É obrigatório fornecer este endereço antes: se o AD do Azure redirecionar os fluxos de autenticação para qualquer endereço, isso fará com seja mais fácil para os atacantes sequestrarem os fluxos de autenticação e roubarem tokens. O registro antecipado da URL do seu aplicativo garante que os tokens de autenticação destinados ao seu aplicativo sejam enviados apenas para o seu aplicativo.

    • URI de ID de aplicativo: esse parâmetro representa o identifier do seu aplicativo Web. O AD do Azure usa esse valor no momento do logon para determinar que a solicitação de autenticação tenha como objetivo permitir que um usuário acesse esse aplicativo específico (entre todos os registrados) para que as configurações corretas possam ser aplicadas.

    noteObservação
    O URI de ID de aplicativo deve ser exclusivo dentro do locatário do diretório. Um bom valor padrão para ele é o valor da URL do aplicativo. Porém, com essa estratégia, a restrição de exclusividade nem sempre é fácil de respeitar: o desenvolvimento do aplicativo em ambientes de hospedagem locais, como o IIS Express e o Azure Fabric Emulator, tende a produzir uma gama restrita de endereços que serão reutilizados por vários desenvolvedores ou até mesmo vários projetos do mesmo desenvolvedor. Uma estratégia possível é acrescentar algo ao valor do URI do aplicativo como diferenciador.

    Observe também: O URI de ID de aplicativo é um URI, e, como tal, não precisa corresponder a nenhum ponto de extremidade de rede endereçável. Isso significa que você pode escolher algo que não tenha nada a ver com a URL do aplicativo: na verdade, embora estejamos trabalhando com um aplicativo totalmente novo neste tutorial, ocasionalmente, você vai registrar aplicativos existentes que talvez já tenham o seu próprio URI de ID de aplicativo (no protocolo de logon usado aqui, o Web Services Federation, o URI de ID de aplicativo é denominado realm) e, nesse caso, é provável que você queira usá-lo aqui. No tópico Desenvolvendo aplicativos Web multilocatário com o Azure AD, vamos destacar algumas restrições extra que a multilocação apresenta.

  4. Depois de inserir a URL do aplicativo e o URI de ID de aplicativo, clique no botão da caixa de seleção no canto inferior direito.

    Início Rápido Isso conclui o processo de registro. O aplicativo agora tem a sua própria entrada no locatário de diretório e o AD do Azure está pronto para lidar com a autenticação Web em seu nome.

    A tela que informa que o registro foi bem-sucedido dá as informações de que você precisa para configurar seu aplicativo Web para usar o AD do Azure para logon. Isto é: a seção Habilitar logon único com o AD do Azure contém algumas configurações que você vai precisar para colar de volta no Visual Studio.

    Mantenha o seu navegador aberto nesta página e volte para o Visual Studio para a próxima tarefa do passo a passo.

Agora que o AD do Azure está pronto para emitir tokens de autenticação para o seu aplicativo, o último passo para permitir o logon da Web é configurar o aplicativo para lidar com as solicitações usando o protocolo de autenticação adequado. A aplicação do protocolo é o que permite que o aplicativo invoque o AD do Azure (e, especificamente, o seu locatário de diretório) para lidar com a autenticação do usuário no início de uma sessão de trabalho do usuário com o aplicativo.

É importante entender algumas das informações básicas sobre a mecânica de autenticação ao usar protocolos de logon da Web. Você encontrará mais detalhes na seção avançada.

O modelo de projeto que escolhemos é o aplicativo MVC 4 Intranet. Esse modelo normalmente usa a autenticação integrada do Windows para garantir que o usuário do aplicativo seja autenticado. Esse mecanismo opera no nível da rede: ele é aplicado a todos os serviços publicados na intranet, sem a necessidade de adicionar qualquer lógica de autenticação ao aplicativo em si.

Quando implantar um aplicativo fora de sua intranet, como é o caso de aplicativos em nuvem, você não poderá mais usar a autenticação de nível de rede. A estratégia mais comum para lidar com a autenticação nesses casos inclui a adição de algum tipo de middleware na frente do seu aplicativo, que recria em um nível mais alto a verificação de autenticação necessária. A camada adicional pode cuidar da interceptação de solicitações não autenticadas, da aplicação de protocolos de autenticação, do redirecionamento de usuários para autenticar fora do aplicativo, do retorno às informações do aplicativo sobre o usuário autenticado, do gerenciamento de sessões e, em geral, de todas as tarefas que necessários para controle de acesso.

Essa estratégia é aplicada de forma consistente na indústria em todas as opções de plataformas, pilhas de desenvolvimento e protocolos logon. Os eventos e o modelo de programação podem variar, mas o padrão geral permanece praticamente o mesmo.

Neste passo a passo, vamos conectar o aplicativo ao AD do Azure através do protocolo Web Services Federation: esta é apenas uma das possíveis opções de implementação de SSO da Web, sendo o SAML-P a outra opção mais comum.

O .NET Framework 4.5 suporta o Web Services Federation de maneira nativa: todas as classes necessárias para aplicar o fluxo de protocolo, processar a autenticação e manipular as sessões no contexto de aplicativos ASP.NET estão presentes na caixa.

Resumindo: o .NET 4.5 oferece um conjunto de HttpModules que são destinados a ser instanciados no pipeline de HTTP do aplicativo. Esses módulos foram criados para se referir a seções de configuração bem conhecidas, que contêm as coordenadas do protocolo do aplicativo e da autoridade de autenticação (neste caso, o locatário do AD do Azure). À medida que as solicitações fluem, os módulos as examinam e aplicam o protocolo de autenticação conforme o caso: por exemplo, ao receber uma solicitação não autenticada, os módulos vão ler as coordenadas do locatário do AD do Azure na configuração, vão usá-las para compor uma mensagem de logon do Web Services Federation e usá-la para redirecionar automaticamente o usuário para que ele se autentique com o AD do Azure.

noteObservação
O subconjunto de classes no .NET Framework 4.5 dedicado a tarefas relacionadas à identidade com base em solicitações é conhecido como WIF (Windows Identity Foundation). Aplicativos orientados a versões anteriores da estrutura (3.5 e 4.0) também podem implementar as medidas descritas neste passo a passo, usando uma versão anterior do WIF que foi lançada fora da banda como uma biblioteca independente (baixe aqui). No entanto, note que as instruções do passo a passo seriam diferentes, pois as duas versões não são totalmente compatíveis (as classes ficam em namespaces diferentes) e que você teria que usar ferramentas para diferentes versões do Visual Studio (2008 e 2010, baixe aqui).

O Visual Studio 2012 oferece ferramentas de apontar e clicar que podem lhe ajudar a configurar os aplicativos para usar o Web Services Federation para logon da Web: você pode usar a interface do usuário da ferramenta para fornecer algumas informações importantes sobre a autoridade que quer usar para autenticação, e a ferramenta emitirá as entradas de configuração correspondentes. Neste passo a passo, você terá que gravar pouquíssimo código, pois as ferramentas vão gerar para você automaticamente a maior parte dele.

  1. Agora que você sabe como vamos implementar o logon da Web, vamos usar a Ferramenta de Identidade e Acesso para configurar o aplicativo. No Gerenciador de Soluções, clique com o botão direito no projeto do seu aplicativo e clique em Identidade e Acesso… no menu de contexto.

    Identidade e acesso O Visual Studio mostrará a caixa de diálogo exibida abaixo.

    Provedores de identidade e acesso Você vai fazer todo o seu trabalho na guia Provedores, esta que aparece agora. Para os fins deste passo a passo, vamos ignorar todas as opções que não precisamos para esta tarefa.

  2. A ferramenta lista vários tipos de autoridade que você pode usar para terceirizar a autenticação. No nosso caso específico, estamos interessados ​​em usar um Provedor de Identidade de Negócios: clique na entrada correspondente, a segunda opção de cima para baixo.

    Configuração de identidade e acesso À medida que você seleciona a opção, os elementos de interface do usuário correspondentes são exibidos no painel abaixo. As informações solicitadas por esses controles correspondem exatamente às entradas exibidas no final do processo de registro do aplicativo descritas na seção anterior. Veja o que você deve inserir, de baixo para cima:

    • Insira o URI de ID de aplicativo (realm) do seu aplicativo: Ele é o identificador do seu aplicativo, como você definiu durante o registro. Volte para a janela do navegador que mostra o Portal de Gerenciamento, copie o valor correspondente do campo Atualizar seu código com o seu URI de ID de aplicativo e cole-o aqui.

    • Digite o caminho para o documento de metadados STS : O “documento de metadados STS” é um arquivo que contém uma descrição legível por máquina da autoridade a que você que deseja se conectar: a ferramenta irá consumi-lo para determinar o valor dos parâmetros que são essenciais ao fluxo de logon (mais detalhes abaixo). Cada locatário do AD do Azure expõe um desses documentos; a sua localização é fornecida no final do processo de registro. Mude para o Portal de Gerenciamento, copie o valor correspondente da página de registro do aplicativo, volte para a ferramenta e cole o caminho nesse campo.

      noteObservação
      À medida que você colar o caminho para o documento de metadados na caixa de texto, a ferramenta exibirá um aviso sobre um certificado ser inválido. Isso se deve ao fato de que o documento de metadados é assinado com um certificado autoassinado, e não deve ser motivo de preocupação.

    Pressione OK. A ferramenta vai acessar o documento de metadados especificado, ler as coordenadas da autoridade (endereço dos pontos de extremidade a ser usado para logon; o certificado X.509 a ser usado para verificar a assinatura de tokens de autenticação; o formato e a versão dos tokens de autenticação emitidos, e assim por diante) e vai usar essas informações para gerar e adicionar ao web.config as entradas que são necessárias para conectar o aplicativo ao Azure AD.

A lista a seguir descreve as entradas principais adicionadas ao web.config pela ferramenta. Para obter uma descrição mais detalhada, consulte a seção avançada do documento.

  • Entradas da <seção> para system.identityModel e system.identityModel.services: Elas são necessárias para que a configuração entenda as definições de configuração específicas da identidade.

  • Configurações de <autorização> em <system.web>: A ferramenta muda automaticamente as configurações de autenticação ASP.NET existentes para exigir que todas as solicitações ao aplicativo sejam autenticadas. Isso reforça o chamado comportamento de "redirecionamento amplo", em que cada solicitação não autenticada será redirecionada à autoridade de autenticação (em oposição a ter partes do aplicativo disponíveis a usuários não autenticados). Esse comportamento é o padrão em aplicativos LoB, onde a autenticação é geralmente silenciosa, uma vez que o usuário já está conectado com a autoridade. Se o desenvolvedor quiser alterar esse comportamento para fornecer os requisitos de autenticação de acordo com o caso, ele pode simplesmente mudar as configurações de <autorização> adequadamente.

  • WSFederationAuthenticationModule (FAM) e SessionAuthenticationModule (SAM) em <system.webServer/modules>: Essas entradas adicionam o pipeline de HTTP do aplicativo do HttpModules, que é responsável por aplicar o uso do Web Services Federation para autenticação. O FAM é o módulo responsável pela aplicação do protocolo: solicitações de logon e gerenciamento de saída de validação de token são os fluxos principais sob a sua responsabilidade. O SAM lida com sessões: especificamente, ele gera os cookies de sessão, os valida e aplica a sua presença em cada solicitação, lida com comprimento da sessão, e assim por diante. O seu comportamento é conduzido pelo elemento de configuração descrito abaixo.

  • A seção <system.identitymodel/identityConfiguration>: Esse elemento determina o comportamento do aplicativo durante a fase de autenticação. Por exemplo: no sub-elemento ValidatingIssuerNameRegistry, ele armazena a lista de autoridades que são de confiança para oferecer serviços de autenticação, gravando os seus nomes e os certificados que eles usam para entrar.

  • A seção <system.identitymodel.services/federationConfiguration>: Esta seção fornece as coordenadas necessárias para gerar fluxos do Web Services Federation: o endereço da entidade a ser usada para solicitações de logon, o identificador do aplicativo em si a ser incluído nas solicitações, etc..

A configuração gerada automaticamente é tudo o que você precisa para usar o AD do Azure para logon da Web: você não precisa gravar nenhum código específico de autenticação no aplicativo em si. Se você quiser acessar as informações de identidade do usuário, é possível fazer isso facilmente consultando as declarações da entidade atual. Por exemplo, digamos que você queira acessar o nome e o sobrenome do seu usuário atual. Você poderá fazer isso usando o código a seguir, sem precisar saber nada sobre como a autenticação ocorreu:

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

A partir do .NET 4.5, cada identidade no .NET é representada com um ClaimsPrincipal. Nesse caso, a ClaimsPrincipal atual foi construída durante a validação de um token de autenticação gerado pelo AD do Azure e apresentada pelo usuário no momento do logon.

Cada ClaimsPrincipal contém um conjunto de solicitações, que são atributos que descrevem o usuário atual como afirmado pela autoridade que o autenticou. Em nosso passo a passo, as declaração da entidade de segurança são as emitidas no token pelo Active Directory do Azure: para obter uma lista completa das solicitações disponíveis, consulte a documentação online.

O AD do Azure emite um conjunto fixo de declarações para os usuários autenticados. Veja abaixo uma referência rápida de todas as declarações que você pode esperar do AD do Azure. É possível encontrar uma descrição completa na documentação.

 

Tipo Valor no exemplo Descrição

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

Identificador direcionado, exclusivo, imutável e não reutilizável do usuário autenticado para o aplicativo atual

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

Identificador para o usuário no diretório. Útil para consultas de diretório sobre o usuário.

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

Identificador do locatário do diretório

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

Nome dado do usuário

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

UPN do usuário

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

Sobrenome dado do usuário

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

Identificador da autoridade que autenticou o usuário, como expresso no protocolo de logon da Web (nesse caso, o WS_Federation)

Neste ponto, o seu aplicativo tem tudo o que você precisa para demonstrar o logon da Web com o AD do Azure. Porém, ele ainda não foi concluído. Há pelo menos dois outros recursos importantes que você deve adicionar: apoio para a saída e atualização automática das coordenadas do protocolo de autoridade.

As próximas duas seções a seguir detalham como adicionar esses dois recursos: é recomendável passar por eles também antes de ir para a seção "Executar o seu aplicativo".

Os protocolos de logon em uso hoje, muitas vezes, incluem disposições para efetuar operações distribuídas de saída: tratam-se de fluxos em que não só o aplicativo atual cancela a sessão atual do usuário, mas também busca a autoridade para sinalizar que um comando de saída deve ser propagado para todas as outras sessões dos aplicativos que poderiam ter sido estabelecidos pela mesma autoridade. O Web Services Federation não é exceção, e oferece um fluxo de saída completo que é totalmente implementado no modelo de objeto do WIF. Nesta subseção, vamos discutir como adicionar recursos distribuídos de saída ao aplicativo de exemplo: isso se resume em fornecer as conexões certas na experiência do usuário para acionar o fluxo de saída e para gerar a mensagem de saída adequada a ser definida para o seu locatário do AD do Azure.

  1. Comece adicionando um controlador SignOut ao aplicativo. Você pode fazer isso localizando a pasta Controladores no projeto no Gerenciador de Soluções, clique nele com o botão direito do mouse e escolha Adicionar, e clique em Controlador. Dê a ele o nome SignOutController, escolha Controlador MVC vazio (geralmente, essa é a configuração padrão) e clique em Adicionar.

  2. Vamos precisar usar classes de alguns novos assemblies. Portanto, teremos que adicionar referências a eles. Novamente, no Gerenciador de Soluções, clique com o botão direito do mouse no nó Referências, escolha Adicionar Referência…, digite system.identitymodel.services no campo Buscar Assemblies e selecione o assembly correspondente da lista principal. Pressione OK.

  3. Volte ao arquivo SignOutController.cs que acabou de criar. Adicionar às diretivas de uso as seguintes entradas:

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    Agora, mude a implementação da classe SignOutController como segue:

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    Veja aqui uma breve explicação do que o código faz.

    • O primeiro método, Index(), atende a solicitação do formulário https://localhost:44341/SignOut. Esse é o endereço de uma exibição que você adicionará em poucos passos posteriormente. Sua finalidade é sinalizar uma saída bem-sucedida, e vamos usá-lo dessa forma no próximo método.

    • O método SignOut() atende a solicitação do formulário https://localhost:44341/SignOut/SignOut, e contém a lógica de saída principal.

    • A primeira linha recupera o objeto que o WIF usa para manter o controle das configurações do Web Services Federation no web.config: vamos precisar dele para criar uma mensagem de saída personalizada para o aplicativo atual.

      noteObservação
      Usar valores de configuração, em vez de codificar valores ou terceirizá-los de repositórios personalizados, geralmente é uma prática recomendada, pois ele torna o seu código adaptável e alinhado com o resto das configurações do protocolo: a lógica continuará funcionando, não importa quantas vezes as definições forem alteradas no arquivo de configuração, antes e depois da implantação.

    • A segunda e terceira linhas criam o endereço de retorno que queremos que a autoridade use no final do fluxo de saída. Queremos que esse endereço aponte para a Exibição discutida anteriormente: dessa forma, o código obtém a URL da solicitação atual e elimina a barra "SignOut". A derivação do endereço da solicitação garante que ele resolva corretamente para o cliente, ao passo que a obtenção do endereço da camada de hospedagem pode resultar em problemas de portas internas ao usar um balanceador de carga.

    • A quarta linha usa WIF para criar uma mensagem de saída do Web Services Federation, passando a URL da autoridade e o endereço de retorno definidos uma linha antes. Você pode facilmente criar a mensagem diretamente na sua forma conectada. Porém, usar o modelo de objeto WIF vai ajudar você a gravar um código mais conciso e ignorar a maioria dos detalhes da sintaxe. Se você tiver interesse em ver como é uma mensagem de saída, lembre-se de capturar um traço HTTP quando executar o aplicativo em uma seção posterior ou consultar a especificação aqui.

    • A quarta linha adiciona à mensagem o identificador do aplicativo atual, conforme registrado no atributo realm do elemento de configuração <wsFederation>.

    • A quinta linha usa o SAM (descrito anteriormente na descrição de configuração gerada automaticamente) para limpar a sessão local: isso inclui excluir o cookie de sessão gerado no momento do logon e qualquer limpeza de recursos locais que possa ser necessária.

      noteObservação
      O aplicativo de exemplo demonstrado aqui não faz muita coisa, mas seus aplicativos reais podem alocar recursos durante a sessão do usuário. Se for esse o caso, você pode tirar proveito de eventos do SAM SigningOut e SignedOut adicionando os manipuladores de eventos correspondentes no arquivo Global.asax para limpar todos os recursos que devem ser descartados ao fechar uma sessão.

A exibição usada aqui vai ser muito simples: como mencionado, a sua finalidade é apenas criar um ponto de retorno significativo para o fluxo de saída.

  1. No Gerenciador de Soluções, clique com o botão direito do mouse no nó Exibições e adicione uma pasta SignOut.

  2. Nessa pasta, adicione uma exibição clicando na pasta com o botão direito e clicando em Adicionar e em Exibição. Chame a nova exibição SignOut também. Coloque um código de apresentação de espaço reservado no arquivo Exibição (SignOut.cshtml) para sinalizar que a saída já ocorreu. Por exemplo:

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. Como você talvez se lembre da seção anterior, nós configuramos o aplicativo para lidar com autenticação por redirecionamentos amplos. Isso significa que, se tentarmos acessar essa Exibição depois de uma saída bem-sucedida (como devíamos), seremos imediatamente redirecionados ao AD do Azure para entrar novamente! Para evitar esse comportamento, use o elemento <location> no web.config para criar uma exceção à política de autenticação.

    Localize a primeira ocorrência do elemento <system.web> e, bem acima, cole o seguinte trecho de código:

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    Isso diz ao ASP.NET que o caminho SignOut pode ser acessado por qualquer pessoa, incluindo usuários não autenticados. Essa disposição permitirá que você veja essa exibição renderizada no seu navegador mesmo com uma saída bem-sucedida.

  1. Agora que o aplicativo tem a capacidade de sair, basta adicionar o recurso à experiência do usuário. Esta uma forma simples de fazer isso: abra o _layout.cshtml no caminho Exibições\Compartilhadas no Gerenciador de Soluções. Procure pela cadeia "Olá" para localizar o código responsável por renderizar as informações de login no topo do layout de MVC 4 conhecido e, em seguida, modifique a seção de login da seguinte forma:

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

Isso vai adicionar um comando de saída no lado direito da saudação do usuário conectado, de modo que uma ação de saída possa ser acionada em qualquer exibição.

A Ferramenta de Identidade e Acesso configurou o aplicativo para aceitar tokens provenientes do locatário do AD do Azure de sua escolha. Para fazer isso, ele armazenou em cache no web.config as coordenadas do protocolo necessárias para conectar-se aos pontos de extremidade do AD do Azure. Além disso, ele salvou as principais informações usadas no momento da autenticação para validar que o token de entrada seja realmente originado no locatário do AD do Azure: tratam-se do nome do emissor que representa o seu locatário e da chave pública (na forma do certificado X.509), que deve ser usada para verificar a assinatura do token.

É uma prática comum de segurança renovar regularmente as chaves criptográficas e as chaves de assinatura do AD do Azure não são exceção: em intervalos de tempo fixo, as chaves antigas serão retiradas, e novas chaves as substituirão na lógica de assinatura do emissor e no documento de metadados do seu locatário. No caso de emergência, as chaves podem ser renovadas fora do ciclo, com pouco ou nenhum aviso.

Toda vez que a chave de assinatura é lançada, as configurações do aplicativo devem ser alteradas adequadamente: de acordo com a abordagem mostrada no passo a passo até agora, isso significaria re-executar a ferramenta para ler o novo documento de metadados e atualizar as entradas do web.config.

Para reduzir o tempo de inatividade, recomendamos adicionar a lógica de autorrecuperação diretamente no aplicativo, de modo que você possa consumir o documento de metadados de forma programática e lançar a chave sem a necessidade de intervenção do operador. Segue abaixo um exemplo de como implementar esse recurso.

  1. Use o Gerenciador de Soluções, como descrito anteriormente no documento, para adicionar uma referência ao assembly System.IdentityModel.

  2. Adicione o seguintes usando as diretrizes adicionadas ao arquivo Global.asax.cs:

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. Depois, adicione o seguinte método usando ao arquivo Global.asax.cs:

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    A lógica aqui é muito simples. O ValidatingIssuerNameRegistry é a classe utilizada pela Ferramenta de Identidade e Acesso para gravar informações sobre quais autoridades são confiáveis ​​e quais chaves devem ser usadas para verificar os tokens que emitem. O WriteToConfig é um método estático que lê as configurações do emissor de um documento de metadados (nesse caso, recuperado da configuração, onde ele foi armazenado pela primeira execução da ferramenta, pela segunda linha do método) e o usa para criar ou atualizar a seção de configuração correspondente do arquivo no caminho especificado (construído a partir do AppDomain atual na primeira linha do método).

  4. Para inserir RefreshValidationSettings() no ciclo de vida do aplicativo, invoque-o de Application_Start() conforme mostrado abaixo.

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    Chamar RefreshValidationSettings de Application_Start garante que o web.config seja modificado em modo de segurança, enquanto se você fizer isso depois no ciclo de vida do aplicativo, arriscaria acionar uma atualização.

ImportantImportante
Há algumas precauções extras que devem ser aplicadas na atualização automática das chaves de validação do aplicativo. A principal ameaça que você precisa mitigar é o sequestro de DNS, onde um atacante usa malwares para lhe apontar um documento de metadados malicioso e induzir o seu aplicativo a confiar nas chaves erradas.

Se você não substituir os padrões .NET para manipular solicitações de HTTP, o cenário acima já está atenuada devido ao fato de que os documentos de metadados são hospedados em pontos de extremidade de HTTPS. Um sequestro de DNS pode redirecionar solicitações a um ponto de extremidade malicioso, mas esse ponto de extremidade não pode passar a validação do servidor HTTPS: por não possuir realmente o domínio no qual documentos de metadados ficam hospedados, o atacante não pode obter um certificado emitido para ele. Portanto, o cliente conseguirá detectar um problema com o servidor e evitar o direcionamento errado.

Ocasionalmente alguns cenários de desenvolvimento vão exigir que você desative a validação de HTTPS (normalmente através da classe ServicePoint). Se for usar a lógica de atualização automática de metadados mostrada nesta seção, é fundamental que você restaure as configurações de validação de HTTPS antes de implantar o seu aplicativo na produção.

  1. Finalmente, agora podemos observar o aplicativo em ação. Pressione F5: uma janela do navegador será aberta, tentando acessar a URL especificada nas configurações do projeto na seção "Criar um aplicativo MVC".

    Primeiro, você receberá um erro de certificado. Este é o comportamento esperado. Clique em Continuar neste site (não recomendado) Não ignore esse erro em um aplicativo de produção, mas é aceitável para a finalidade deste passo a passo.

    CertificateError Se você observar a barra de endereço, verá por um breve momento a URL do aplicativo. Porém, o módulo FAM na frente do aplicativo reconhece a chamada imediatamente como não autenticada, lê o que fazer na configuração e aciona o redirecionamento de logon para o AD do Azure. A barra de endereço da URL é substituída pela barra da autoridade e o usuário é solicitado a se autenticar através da interface do usuário do AD do Azure.

    noteObservação
    Não é possível usar a nova conta de usuário criada anteriormente para gerenciar sua assinatura do Azure, caso tenha entrado inicialmente no Portal de Gerenciamento usando uma conta Microsoft. Se tentar navegar de volta para o Portal de Gerenciamento depois de ter entrado no aplicativo como o novo usuário, você receberá uma mensagem de erro. Em vez disso, você deve entrar no Portal de Gerenciamento com a conta que usou para criar o seu locatário de diretório. Se tiver entrado inicialmente no Portal de Gerenciamento usando uma conta do AD do Azure e, se o novo usuário criado anteriormente tiver recebido função de Administrador Global, esse novo usuário poderá gerenciar sua assinatura do Azure.

    Entrar no AD do Windows Azure
  2. Digite as credenciais do usuário que você criou em seu locatário do Azure na primeira seção do passo a passo. Pressione o botão Entrar.

    Você deve se lembrar que quando criou o usuário no seu locatário do AD do Azure, o Portal de Gerenciamento atribuiu a ele uma senha temporária. Você deve se autenticar usando essa senha. No entanto, como essa senha deveria ser temporária, durante esta primeira operação de login, você será solicitado a escolher uma senha de usuário adequada antes de continuar com o fluxo de autenticação. Quando terminar de fazer isso, o fluxo normal de login do aplicativo será restaurado.

    Home page do aplicativo À medida que a autenticação for bem-sucedida, o WIF processa as solicitações do token de autenticação de entrada que, por sua vez, são usadas pelo código de exibição simples que adicionamos no controlador principal. De agora em diante, você pode navegar pelo site sem precisar se autenticar novamente: cada postagem terá o cookie de sessão tratado pelo módulo SAM.

  3. Para observar o que acontece quando você encerra a sessão, clique no link de Saída no canto superior direito. Você vai observar os redirecionamentos que codificamos antes, que acabarão aparecendo na exibição abaixo.

    Sair Para verificar se você realmente saiu, clique em qualquer outro elemento de interface do usuário: o ciclo de autenticação vai recomeçar.

A parte do passo a passo do documento lhe mostrou os procedimentos essenciais que você precisa executar para adicionar o logon da Web ao seu aplicativo Web. O restante do documento vai além do básico, se aprofundando em alguns tópicos importantes e abrangendo algumas das outras tarefas que talvez você precise executar para levar o aplicativo para o próximo nível.

Nesta seção, você vai aprender como modificar as configurações do seu aplicativo para implantá-lo e executá-lo no sites do Azure. O aplicativo permanece praticamente inalterado: as únicas coisas que requerem atenção são a acomodação do novo endereço e o gerenciamento de sessão para o seu aplicativo.

Esta parte do documento exige que você tenha um site do Azure para direcionar para a implantação do seu aplicativo. Se já tiver um site disponível, você poderá usá-lo; se não tiver, consulte este documento para saber como criar e publicar um site do Azure. Se seguir o tutorial desse documento, pare logo depois de ter baixado o perfil da publicação: há algumas coisas que precisamos ajustar antes de instalar o aplicativo.

Ajustar as configurações do aplicativo no Portal de Gerenciamento do Azure

Se você se lembrar da seção sobre o registro do aplicativo, vai-se lembrar que um parâmetro chave que define o seu aplicativo na interface do usuário do AD do Azure é a URL do aplicativo em si. As etapas passo a passo até agora presumiram que o IIS Express local era a localização do aplicativo. No entanto, uma implantação nos sites do Azure significa que a URL do aplicativo vai mudar e que as configurações no AD do Azure terão de refletir isso.

  1. Navegue de volta para o Portal de Gerenciamento; selecione a guia Active Directory à esquerda; clique no locatário do diretório; escolha o cabeçalho Aplicativos; clique na entrada correspondente do aplicativo com o qual está trabalhando. Clique no cabeçalho Configurar; você vai navegar para uma tela que lhe permitirá modificar as configurações do aplicativo que você inseriu durante a criação. Para o benefício deste tutorial, ignore as áreas principais da tela e vá para a seção de logon único.

    Logon Único
  2. Localize a caixa de texto URL DE RESPOSTA e insira o endereço do seu site do Azure de destino (por exemplo, https://aadga.windowsazure.net/). Isso vai permitir que o AD do Azure retorne tokens ao local do seu site do Azure após a autenticação bem-sucedida (e não ao local do momento do desenvolvimento que você usou no início do thread). Depois de atualizar o valor, clique em SALVAR na barra de comandos na parte inferior da tela.

noteObservação
Você deve notado que o URI de ID de aplicativo ainda está usando o valor com base no host local que você criou anteriormente no documento.

Tecnicamente, contanto que o identificador esteja em forma de URI e seja exclusivo entre todos os aplicativos no locatário do diretório atual, qualquer valor funcionará para os tipos de aplicativo abordados aqui; razão pela qual as instruções principais não incluem a atualização desse valor.

No entanto, para fins de gerenciamento, convém modificar o URI de ID de aplicativo para ter um valor que seja mais representativo do seu aplicativo. Um exemplo típico seria um derivado do valor de URL resposta.

Observe que, se mudar o valor de URI de ID de aplicativo, você vai precisar aplicar alterações mais extensas ao aplicativo antes da implantação. Mais detalhes posteriormente.

Preparar o aplicativo para execução nos sites do Azure

A configuração de logon Web é, na maior parte, preparada para a nuvem: há apenas uma mudança que você precisa aplicar, em grande parte, devido aos recursos dos sites do Azure.

O processo de logon Web resulta na criação de um cookie de sessão, que é enviado a todas as solicitações a partir do momento da autenticação. O cookie de sessão é criado pelo middleware WIF e, por padrão, ele é assinado e criptografado via DPAPI (veja este documento para obter informações de plano de fundo) de modo a evitar abusos do cliente (como alterar a lista de solicitações para elevar privilégios). Porém, as configurações do IIS nos sites do Azure evitam o uso de DPAPI para proteger sessões. Portanto, você precisa mudar a forma como o WIF protege o cookie associado. O .NET Framework 4.5 oferece uma alternativa pronta, que aproveita o MachineKey (consulte a documentação aqui) e funciona sem problemas nos sites do Azure.

A Ferramenta de Identidade e Acesso facilita muito essa mudança.

  1. Clique com o botão direito do mouse no projeto no Gerenciador de Soluções, escolha Identidade e Acesso… e selecione a guia Configuração. Você verá algo parecido com a captura de tela a seguir:

    Sites do Azure de identidade e acesso
  2. Basta marcar o sinalizador Habilitar cookies prontos para farm e pressione OK. A ferramenta será responsável por adicionar os elementos necessários no web.config (na prática, substitua a classe padrão SessionSecurityTokenHandler por MachineKeySessionSecurityTokenHandler) para mudar para o MachineKey como método de proteção de cookie.

    noteObservação
    No passo anterior, você alterou o URI DA ID DO APLICATIVO no Portal de Gerenciamento do Azure, você pode usar essa interface do usuário para aplicar facilmente essas alterações ao seu projeto: basta colar o valor do URI de ID de aplicativo nos dois campos de texto superiores e clicar em OK. A ferramenta aplicará essas alterações nos lugares certos no arquivo de configuração.

    Opcionalmente, você pode querer considerar desativar temporariamente as mensagens de erros personalizadas do ASP.NET, adicionando a entrada <customErrors mode="Off" /> na seção <system.web> do arquivo web.config. Isso vai lhe ajudar a solucionar problemas caso eles ocorram no momento da implantação. No entanto, lembre-se de reativá-los antes de ir para a produção: atacantes podem usar as mensagens de erro detalhadas para sondar o seu aplicativo em busca de brechas, e o customError vai evitar que isso aconteça.

Isso é tudo o que você precisa fazer para preparar o aplicativo para execução como um site do Azure. Use as configurações de publicação para implantar o aplicativo. Depois, abra um navegador, vá até o endereço azurewebsite.net do seu aplicativo e siga o mesmo fluxo abordado na seção de testes de aplicativo do passo a passo: como projetamos toda a lógica personalizada para ser independente de local, você vai poder executar as mesmas operações que experimentou no local.

A Ferramenta de Identidade e Acesso gera automaticamente as definições de configuração necessárias para o seu aplicativo para se integrar com o seu locatário do AD do Azure pelo Web Services Federation. Na melhor das hipóteses, você nunca vai precisar ver essas configurações na verdade; mas há casos em que você vai querer alterar o comportamento padrão, ou vai precisar solucionar um problema. Nesses casos, encontrar o caminho pelas definições de configuração do WIF pode ajudar.

As classes WIF e o método usados no fluxo de entrada da Web estão totalmente documentados no MSDN. Ali, vamos apresentar uma versão comentada do web.config após a Ferramenta de Identidade e Acesso modificá-la. Para sua conveniência, incluímos também as alterações da seção sobre a publicação para sites do Azure.

noteObservação
Por motivos de esclarecimento, o documento inclui toda a fonte do Web.config. Porém, somente as seções relevantes ao WIF são anotadas.

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

Nenhum comentário para a configuração acima.

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

Na configuração acima, essa área carrega as classes que o ASP.NET precisa para ler e interpretar as seções de configuração usadas pelo WIF para modelar as configurações de autenticação e fluxo do Web Services Federation.

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

Nenhum comentário para a configuração acima.

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

Para a configuração acima, essas entradas de appSettings são capturadas pela Ferramenta de Identidade e Acesso, para acompanhar as configurações importantes (como o endereço do documento de metadados, que usamos na seção de substituição de chaves) que não seriam salvas em outro lugar.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Para a configuração acima, esses dois elementos de <location> esculpem duas áreas do aplicativo Web que podem ser acessadas sem exigências de autenticação (veja abaixo). A seção FederationMetadata é criada pela Ferramenta de Identidade e Acesso: a ferramenta cria um documento de metadados que descreve o aplicativo, que pode ser usado pelas autoridades para provisionar o aplicativo. Você adicionou a seção SignOut como parte das instruções sobre como implementar uma saída da Web.

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

Para a configuração acima, por padrão, a Ferramenta de Identidade e Acesso define a autenticação do ASP.NET e as configurações de autorização para que todas as partes do aplicativo Web (a não ser pelas exceções acima) requeiram que os usuários sejam autenticados antes de atender solicitações. Embora isso seja geralmente apropriado para aplicativos LOB, às vezes, os desenvolvedores preferem manter áreas que possam ser acessadas anonimamente: se for esse o seu caso, altere as definições aqui adequadamente.

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

Nenhum comentário para a configuração acima.

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

Para a configuração acima, as entradas dessa seção inserem no pipeline SP.NET os HTTPModules que implementam os recursos principais de manipulação de sessão e protocolo. O WSFederationAuthenticationModule (FAM) aplica o Web Services Federation, validando tokens de entrada e gerando mensagens de logon para a autoridade, de acordo com as especificações do protocolo. O SessionAuthenticationModule (SAM) cria e valida os cookies de sessão, em colaboração com o FAM.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

Nenhum comentário para a configuração acima.

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

Para a configuração acima, o <system.identityModel> envolve todas as configurações específicas de classes do WIF. Seu primeiro elemento filho, o IdentityConfiguration, fornece uma descrição independente de protocolo do comportamento do aplicativo. A lista AudienceUris fornece todos os valores que o WIF vai considerar como escopos aceitáveis nos tokens de entrada para os aplicativos atuais. Normalmente, eles correspondem ao realm do aplicativo (ou URI DA ID DO APLICATIVO, na linguagem do AD do Azure). Um token de entrada deve declarar que seu destinatário pretendido é um dos valores listados aqui. Se esse não for o caso, o WIF vai presumir que este é um token roubado e recusará a chamada.

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

Para a configuração acima, o elemento ValidatingIssuerNameRegistry contém a lista de tuplas aceitáveis de chave de verificação de nome e assinatura do emissor. Neste passo-a-passo, as configurações irão refletir os valores associados ao seu locatário do AD do Azure: este elemento garante que nenhum outro emissor, incluindo outros locatários do AD do Azure de outras empresas, possam ter acesso ao seu aplicativo.

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

Para a configuração acima, este elemento desativa a validação do certificado no pipeline do WIF. Essa medida é necessária no caso do AD do Azure, uma vez que é usado um certificado autoassinado: na falta da instalação do certificado em si no repositório de certificados local, a validação de uma cadeia ou de pares vai falhar. Observação: isso não diminui muito a segurança da autenticação do AD do Azure, pois o ValidatingIssuerNameRegistry garante que o certificado correto seja usado. Porém, se estiver usando o WIF no mesmo aplicativo para usar outros emissores, lembre-se de que essas configurações se estenderiam até eles também.

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

Esta seção permite que você manipule o conjunto de classes que o WIF utiliza para processar tokens de segurança de entrada (os chamados manipuladores de token). Ele pode ser usado para influenciar o comportamento do manipuladores individuais, ou para adicionar e remover um tipo de manipulador. Neste caso, a ferramenta removeu o manipulador de sessão padrão (que tem como base o DPAPI e não funciona nos sites do Azure) e o substituiu por um que funciona com o MachineKey.

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

Para a configuração acima, o <system.identityModel.services> é usado para armazenar as coordenadas específicas do Web Services Federation.

O elemento wsFederation, especificamente, é usado aqui para registrar o ponto de extremidade de logon do Web Services Federation para o seu locatário do AD do Azure; o realm (URI DA ID DO APLICATIVO) do aplicativo, a ser enviado como identificador no momento do logon; e outros sinalizadores que influenciam o comportamento local do WIF, como se os erros 401 do aplicativo sempre precisassem acionar uma mensagem de entrada para a autoridade (passiveRedirectEnabled) ou se as transações no HTTP limpo precisassem ser permitidas.

Este elemento pode ser usado para especificar muito mais parâmetros de protocolo: eles são somente o mínimo absoluto para que o fluxo de logon funcione.

Este documento se concentra em uma tarefa bastante restrita, conectando o aplicativo a.NET ao AD do Azure para executar logon da Web usando o Web Services Federation. Há muitos mais cenários que você pode abordar, usando uma variedade de diferentes protocolos abertos, aproveitando qualquer pilha de programação em qualquer plataforma moderna ou trabalhando diretamente no nível do protocolo conectado.

Na seção sobre implantação do aplicativo para o Azure, você viu que o Portal de Gerenciamento oferece a chance de mudar muito mais os aspectos das configurações de registro do seu aplicativo: você vai conhecer a maioria desses controles extras no próximo passo a passo da série. Aqui vamos apenas mencionar brevemente como você pode obter as informações de que precisa caso escolha interagir com o AD do Azure no nível do protocolo, para logon da Web ou qualquer outro dos fluxos que ele suporta.

  1. Abra o Portal de Gerenciamento do Azure em uma janela do navegador e navegue até o cabeçalho Aplicativos na seção do AD do Azure. Você vai notar que a barra de comando na parte inferior da tela contém uma entrada: Exibir pontos de extremidade. Clique nela.

    Pontos de extremidade de aplicativo A caixa de diálogo lista todos os pontos de extremidade que você pode usar para interagir com o locatário do AD do Azure de forma programática. Aqui há uma breve explicação para todas as entradas:

    • Documento de metadados de federação: A localização do documento de metadados que descreve o locatário do AD do Azure como uma autoridade de logon da Web. Como você viu no passo a passo, na seção sobre atualização automática de chaves, este documento contém as coordenadas de metadados do Web Services Federation; ele também contém os metadados do protocolo SAML no mesmo pacote. Para obter mais informações, consulte Federation Metadata.

    • Ponto de extremidade de logon do Web Services Federation: O ponto de entrada para todas as transações do Web Services Federation. Este é o ponto de extremidade que você usou no passo a passo para fluxos de logon e de saída. Para obter mais informações, consulte WS-Federation Endpoint URL.

    • Ponto de extremidade de logon do SAML-P: O ponto de extremidade usado para implementar fluxos de logon no protocolo SAML. Para obter mais informações, consulte SAML Protocol Metadata and Endpoints.

    • Ponto de extremidade de saída do SAML-P: O ponto de extremidade usado para implementar fluxos de saída no protocolo SAML. Para obter mais informações, consulte SAML Protocol Metadata and Endpoints.

    • Ponto de extremidade do Azure AD Graph: as consultas para recuperar informações do diretório armazenadas no locatário atual do AD do Azure devem ser dirigidas a esse ponto de extremidade, usando a sintaxe da Graph API. Para obter mais detalhes, consulte Usar a Graph API para consultar o Azure AD.

    • Ponto de extremidade do token OAuth2: Este ponto de extremidade é usado para servidor para fluxos de autenticação entre servidores: por exemplo, ele pode ser utilizado para obter tokens de acesso para invocar o ponto de extremidade do Graph. Para obter mais informações, consulte OAuth 2.0 (Preview Version).

Contribuições da comunidade

Mostrar:
© 2014 Microsoft