Windows Azure: Autentique o Windows Azure com o ADFS

A demanda por acesso ininterrupto e de qualquer lugar a dados corporativos requer vários níveis de autenticação remota.

Dan Griffin e Tom Jones

Executivos experientes estão usando móveis e cloud computing como um ativo estratégico para aumentar a velocidade e a flexibilidade de seus processos de tomada de decisão. Dispositivos móveis já provaram seu valor no negócio. Os usuários em qualquer lugar, a qualquer momento têm acesso aos dados de que precisam para se manter produtivo.

A proliferação de smartphones e tablet computadores — para não mencionar a demanda para a nuvem de computação — aumentou a pressão sobre os departamentos de TI para fornecer acesso móvel seguro para conteúdo corporativo valioso. Em suma, se você não está investindo no formal-suporte para a computação móvel segura, você pode ter certeza que são seus concorrentes. Eles vão fazer isso um diferencial.

Qualquer investimento interno na computação móvel deve conta para segurança de dados. Você também deve planejar o custo potencial de satisfação do usuário com barreiras de segurança podem incorrer. Por exemplo, tem havido um desejo de um mecanismo unificado que autenticar com segurança tanto em usuários locais e remotos. Isto inclui dispositivos handheld, dispositivos de desktop e aplicativos novos e legados.

Soluções de gerenciamento de identidade flexíveis e de baixo custo tem sido difícil de encontrar. Os usuários se irrita em pedidos de mais uma credencial de logon. Além disso, quando o usuário tiver o mesmo credenciais de logon armazenados em vários locais, aumenta o risco de roubo de identidade ou divulgação acidental.

A boa notícia para ele é que a computação móvel é um exemplo claro de segurança de TI como um facilitador de negócios. Além disso, as tecnologias de autorização e autenticação mais recente podem fazer verdadeira segurança transparente para o usuário.

Na Conferência da RSA 2013, gerente de missão da Agência dos Estados Unidos nacional segurança mobilidade explicou por que mesmo os ambientes mais confidenciais requerem suporte coesa para o guerreiro de estrada. Os departamentos de TI precisam habilitar serviços e dispositivos que oferecem suporte a uma variedade de mecanismos de autenticação de usuário.

Você pode adaptar uma solução de gerenciamento de identidades existentes tais como o Microsoft Active Directory Federation AD FS (serviços) de um típico linha de negócios (LOB) oaplicativo executando no ambiente de nuvem Windows Azure. Você pode também facilmente aplicar a forma geral da solução descrita aqui para outras soluções de gerenciamento de identidades, aplicações e serviços em nuvem.

Métodos de autenticação existentes

No âmbito de Windows, serviços de diretório sempre foi tradicional repositório de identidades de usuário da empresa. Isto é projetado para dar acesso de funcionários a ativos de rede atrás de um firewall onde Kerberos é o protocolo de dominar.

Porque o Kerberos não é recomendado para uso na Internet, a maioria das organizações usam protocolos de autenticação baseados em Web como SAML Security Assertion Markup Language (), Token de Web simples (SWT) e JSON Web Token (JWT). Esses símbolos de Web mais recentes não são ainda acomodados pela maioria dos serviços de diretório corporativo, então você vai precisar de um serviço adicional — chamado o servidor de Token de segurança (STS) — para conectar o diretório tradicional para os mais recentes aplicativos de Web.

Separação de funções é importante. Cada servidor de aplicativos de LOB não deve ser responsável pela autenticação do usuário. Precisa de que o servidor de aplicativos é a capacidade de confiar em algum outro serviço para fazer o trabalho pesado de fornecer informações de identidade e autorização de forma flexível. Isso é o que é geralmente referido como "identidade federada".

Federação significa que o servidor de aplicativos (a terceira parte confiável, ou RP) estabelece uma relação de confiança com o provedor de identidade. Ele deve entender como avaliar os metadados de identidade de usuário fornecidos na forma de declarações.

Por exemplo, imagine um usuário tentar acessar o conteúdo em um serviço de rede (ver Figura 1). O RP solicita uma coleção de declarações roteados por um aplicativo (por exemplo, o navegador da Web) do dispositivo do usuário para um ou mais STSs. O usuário se autentica para o STS com qualquer credencial foi fornecida: senha, cartão inteligente e assim por diante. A conexão somente direta entre a RP e o STS é a configuração inicial, em que a confiança é estabelecida entre os dois (normalmente, configure cada uma com o certificado de servidor de outro).

When a user requests secure content, that request kicks off a series of cross-checks.

Figura 1 quando um usuário solicita conteúdo seguro, esse pedido arranca uma série de controlos cruzados.

O AD FS e Windows Azure no mundo real

Uma opção é configurar o AD FS como o STS. AD FS protege o interno serviços Active Directory domínio (AD DS) contra ataques externos aceitando pedidos de autenticação da Internet. AD FS traduz a identidade baseada em Active Directory em um formato de Internet compatível.

Neste caso, o dispositivo externo é uma tablet Windows. O dispositivo está se comunicando em uma conexão de rede externa para um servidor de aplicações Web (RP) hospedado na nuvem Windows Azure. O servidor de aplicativos precise saber o usuário autenticado pelo AD FS está usando um computador que está em conformidade com as diretivas de rede.

Como segurança especialista Butler Lampson disse há anos, "toda a confiança é local." Em outras palavras, o RP deve ser capaz de realizar sua própria validação de créditos antes de ele pode autorizar o acesso ao conteúdo do aplicativo. Que autorização e validação se baseia os usuário identidade e dispositivo conformidade declarações emitidas por um STS. Dispositivo do usuário, em seguida, dirige essa troca de dados de autenticação (consulte Figura 2).

It takes a series of claim responses to validate a data request. 

Figura 2 leva uma série de respostas de reivindicação para validar uma solicitação de dados.

Um agente no dispositivo de coleta de reivindicações de uma variedade de fontes e combina em uma resposta para o servidor de aplicativos. Que resposta deve cumprir todos os critérios para permitir o acesso os dados protegidos. Declarações de identidade do usuário e dispositivo-saúde-conformidade pode vir de diferentes STSs, como descrito em Figura 2, ou de um único STS com múltiplas fontes de metadados de alegações (por exemplo, Active Directory e Microsoft System Center Configuration Manager).

Você pode alterar a mistura de provedores de identidade e atributo para atender as necessidades do serviço da Web de RP. Por exemplo, você poderia combinar autenticação do Office 365 com medições de dispositivo cliente para atender às políticas de prevenção de perda de dados. Em todos os casos, a solicitação RP vai-se a um agente de usuário do dispositivo do usuário. Que vai empacotar as reivindicações de várias fontes para atender às demandas da RP.

Muitos cenários de autenticação da Web permitem que o usuário dispositivo reivindicações de cache para uso posterior. Isto é chamado frequentemente um cenário de "Manter Me assinado em". O RP ainda tem a opção de solicitar declarações adicionais do usuário conforme a necessidade a transação solicitada pelo usuário. Isso é conhecido como "step up" autorização.

Suporte AD FS e identidade

Para desenvolvedores de aplicativos LOB baseados em Windows, o suporte à Federação de baseia-se no Microsoft .NET Framework 4.5. Os desenvolvedores não precisam tornar-se especialistas em segurança, a fim de permitir os cenários descritos aqui.

Enquanto o .NET Framework 4.5 não acompanham o SWT e apoio da JWT, adicionando essas estruturas é bem documentado. A Microsoft lançou um manipulador da JWT para o .NET Framework 4.5. Windows Server 2012 vem com o AD FS 2.1 como uma função de servidor integrado que suporta agora os pools de aplicativos do .NET Framework 4. Você vai precisar para apoiar o manipulador da JWT e outros recursos avançados.

Controle de acesso baseado em declarações é útil quando a parceria entre os limites da empresa, porque ele separa a autenticação (por exemplo, no local do Active Directory) de autorização (por exemplo, para serviços de dados compartilhados na nuvem). Reivindicações facilitar controle de acesso baseado em função administrar porque AD FS e outros provedores de identidade podem emitir declarações que suportam uma variedade de autorização verifica em RP.

Este artigo demonstra como você pode usar os créditos para permitir autenticação segura do usuário de uma ampla variedade de dispositivos. Os usuários têm vindo a esperar a qualquer hora, em qualquer lugar de acesso aos recursos da empresa. Ela é obrigada a realizar um ato de equilíbrio delicado.

Você tem que habilitar o negócio com a infra-estrutura escalável que suporta computação móvel. Ao mesmo tempo, você tem que proteger o negócio com mecanismos de segurança dos dados que são manejáveis e minimamente invasiva.

Tom Jones

Tom Jones foi o Presidente fundador da American National Standards Subcomissão ASC X9A10 pagamentos electrónicos. Ele trabalhou dentro da Comunidade de serviços financeiros com várias organizações, incluindo a Electronic Data Interchange (EDI X 12) e Accredited Standards Committee X9 Inc. pagamentos electrónicos, bem como com a primeira Data Corp, Intel Corp. e a Microsoft.

 

Dan Griffin

Dan Griffin é o fundador do JW Secure Inc. e uma segurança da empresa de Microsoft MVP. É autor dos livros "Nuvem e controle de segurança" (CreateSpace independente plataforma de publicação, 2012) e "Os quatro pilares do Endpoint Security," a ser publicado em 2013. Ele também é palestrante freqüente da conferência.

Conteúdo relacionado