Azure Insider

Artigo
01/29/2015

Desafio BYOD: Conecte os dispositivos móveis à empresa

Bruno Terkaly Ainda existem muitas preocupações em torno do movimento BYOD (Traga seu próprio dispositivo) em ambientes corporativos e como os Serviços Móveis do Azure podem ajudar os desenvolvedores. Um valor fundamental dos Serviços Móveis é que ele democratiza a identidade e reduz o custo e esforço para fornecer acesso seguro aos recursos corporativos protegidos. Neste artigo, daremos uma olhada mais de perto no que é preciso para suportar cenários mais complexos ao conectar aplicativos móveis aos recursos na empresa.

Vamos começar definindo a identidade das partes interessadase olhando para as semelhanças e diferenças no que diz respeito aos funcionários, parceiros comerciais e clientes. Nós também olharremos para sa arquiteturas de software que fornecem conectividade segura para os usuários do navegador e dos dispositivos móveis ao acessar os serviços e sites locais. Posteriormente no artigo, demonstraremos essas técnicas usando um aplicativo iOS que se conecta a um back-end dos Serviços Móveis, bem como um ponto de extremidade do serviço local.

Nem todos os acessos são iguais

Existem várias metas importantes deste esforço. A primeira é a de proporcionar acesso a recursos locais com um mínimo de código personalizado ou mudanças de infraestrutura, incluindo configurações de rede existentes. Outra meta é gerenciar esses cenários de uso para garantir o controle e a visibilidade, enquanto é ágil e flexível.

Nem todos os usuários que precisam de acesso por trás do firewall corporativo são criados iguais. E nem todos os dados por trás do firewall corporativo precisam do mesmo nível de proteção. Alguns funcionários precisam de um acesso maior a informações protegidas. Funcionários como vendedores de campo precisam ter acesso às informações mais atualizadas sobre os preços dos produtos e níveis de estoque. Eles podem até precisar de acesso aos dados de contabilidade sobre os seus clientes, tais como pagamentos recentes na conta. Eles provavelmente, no entanto, não precisam de acesso a aplicativos de recursos humanos.

Os parceiros comerciais têm as suas próprias necessidades específicas. Os parceiros de negócios confiáveis frequentemente associam a identidade através de uma extranet. Os parceiros comerciais geralmente gerenciam sua própria infraestrutura de identidade para autenticar usuários e usará "declarações" para acesso moderado aos recursos protegidos da empresa. Assim, tanto o parceiro como a empresa usará a política de confiança para mapear as declarações de entrada para declarar a compreensão por um recurso protegido, como um aplicativo da Web interno.

Existem duas outras partes interessadas de identidade menos comuns. Os clientes geralmente precisam ter acesso a suas informações de conta, algo como PayPal ou Netflix. Uma perspectiva é efetivamente um cliente potencial. Ele poderia ter desistido das informações do cartão de crédito, mas realmente ainda não comprei nada. Todos estes tipos de usuários compartilham um aspecto comum: Todos querem levar e usar seus dispositivos iOS, Android e Windows Phone para trabalhar na empresa.

Gerenciamento de segurança da empresa

Pelo menos cinco pilhas de software desempenham um papel nos dispositivos móveis de segurança na empresa. Aqui, vamos dar uma olhada nas conexões híbridas, no barramento do serviço do Azure, no proxy do Active Directory do Azure e no gerenciamento do API do Microsoft Azure.

Seria simples ter funcionários apresentando suas credenciais ao Active Directory através de uma interface Web, obter um token de acesso e começar a trabalhar, mas o mundo da identidade é mais sutil e complexo. A noção de "tamanho único" simplesmente não é verdade. Os funcionários são normalmente obrigados a usar um provedor de identidade corporativa.

A maioria das empresas trouxeram identidade internamente, normalmente alavancando o Active Directory, que em sua maioria expõe um protocolo com base no LDAP. Neste novo mundo móvel, mundo habilitado para nuvem, as empresas precisam de um protocolo de comunicação com base em HTTP para dispositivos móveis. A Microsoft criou tal sistema de identidade no Azure chamado Active Directory do Azure (AD do Azure). Uma das grandes características do AD do Azure é que as empresas podem sincronizar identidades para a nuvem usando a sincronização de diretório. Leia mais sobre esse processo em bit.ly/1ztaB9Z.

Existe um par de outras características interessantes no AD do Azure. O AD do Azure oferece a conveniência de SSO (logon único). Isso permite recursos protegidos do acesso de funcionários ao longo do tempo, semestar forçando repetidamente o logon e fornecer credenciais. O token de acesso é armazenado localmente como um cookie no dispositivo do funcionário. Você pode limitar o acesso através de técnicas de expiração do token.

O AD do Azure também suporta OAuth 2.0, talvez o padrão aberto mais popular para autenticação. Isso fornece aplicativos do cliente garantindo o acesso delegado aos recursos do servidor em nome do proprietário de um recurso. Usando o OAuth 2.0, o AD do Azure pode autenticar um usuário e emitir seja um SAML 2.0 como um token JWT. Leia mais sobre como os tokens funcionam em bit.ly/1pDc0rg.

Parceiros comerciais

As empresas de método tradicional conseguiram autenticação gerenciada através de infra-estruturas de TI umas das outras, através de confiança da federação. Isso envolve o estabelecimento de uma relação de confiança entre os serviços da federação das duas empresas (consulte Figura 1). Estas transações com base na Web seguras suportadas com parceiros comerciais. No entanto, não é tão simples quanto parece, e pode de fato apresentar desafios.

Figura 1 Modelo de identidade tradicional para Federação do Active Directory

O parceiro tem que configurar uma relação de confiança entre o seu Active Directory e Active Directory da outra empresa. sso permite que um empregado de uma empresa autentique através do seu próprio Active Directory e, em seguida, troque tokens de autenticação com o Active Directory da outra empresa, a fim de ter acesso a um aplicativo na outra rede. Essa abordagem requer um monte de coordenação e fluxos de trabalho manual para administradores de TI.

A Figura 2 descreve uma abordagem mais moderna de gerenciamento de identidade. Geralmente, uma cópia das identidades dos funcionários estão hospedadas no Azure, embora algumas identidades possam residir no Azure sozinhas. A manutenção [e mantida no mínimo, uma vez que a cópia original da maioria das identidades é gerenciada no local. Um processo de sincronização de segundo plano mantém a cópia das identidades na nuvem totalmente sincronizada. Os usuários podem se conectar diretamente no AD do Azure em um datacenter na nuvem e, em seguida, serem redirecionados para o aplicativo adequado.

Figura 2 A Abordagem moderna para o gerenciamento de Identidade

Para os desenvolvedores de aplicativos móveis, você encontrará uma série de bibliotecas no GitHub que você pode usar para aproveitar o AD do Azure (bit.ly/1qmeipz).

Android, iOS, Microsoft .NET Framework, JavaScript, Node.js e mais são todos suportados. Por exemplo, o exemplo do iOS mostra como obter um código de autorização interativo para trabalhar com uma conta de trabalho. Você pode associar esta conta de trabalho para um servidor de Active Directory em execução no seu datacenter ou viver completamente na nuvem com o AD do Azure. No back-end, você poderia usar um Node.js API baseado em REST ou .NET Web API.

Acesso do cliente

Você não costuma pensar em sites e serviços voltados para o cliente que tenham acesso a recursos da empresa protegidos. No entanto, isso é mais comum do que você pensa. Por exemplo, Wells Fargo pode querer expor dados financeiros do cliente em toda a Web através de um site seguro ou aplicativo móvel, enquanto a Netflix pode querer fornecer acesso seguro aos recursos protegidos, tais como saldo em conta corrente ou histórico de pagamentos. Isto se torna especialmente importante para os clientes que usam dispositivos móveis.

Em alguns cenários, ele ainda faz sentido para alavancar provedores de identidade social, tais como Microsoft Account, Facebook, Google ou Twitter. Esta abordagem foi demonstrada em detalhes no artigo de novembro do Azure Insider (msdn.microsoft.com/magazine/dn818496), em que escrevemos um aplicativo iOS nativo que usa o Twitter como o provedor de identidade.

A suposição aqui é que qualquer pessoa pode fazer o download do aplicativo ou acessar o site da Web. Existe uma camada de serviço disponível ao público. As perspectivas normalmente têm uma experiência não autenticada, e exibem apenas informações publicamente disponíveis. Mesmo neste caso, pode haver alguma necessidade de acessar recursos no local. Seu serviço pode fornecer uma camada não autenticada de serviço ou responder a um conjunto de credenciais padrão.

Ferramentas de conectividade segura

Identidade de lado, existem várias ferramentas que podem ajudar com segurança a conectar os usuários aos recursos em redes corporativas. Um exemplo é o Relé de barramento do Serviço do Azure (consulte Figura 3), que fornece uma maneira elegante de facilitar o acesso a recursos protegidos. Você pode pensar no relé do barramento do Serviço do Azure como um serviço hospedado em nuvem agindo como um gatekeeper para intermediar a conexão entre um cliente e os recursos corporativos. O Relé de barramento do serviço é autenticado e só abre portas de saída. Ele suporta tópicos e filas, assim, para que você possa implementar uma forma de mensagem distribuída. Você pode até mesmo incorporar os Hubs do REvento se for necessário para ingerir grandes quantidades de eventos.

Figura 3 O Relé de barramento do Serviço do Azure

A vantagem dessa abordagem é que não há alterações de configuração necessárias para as redes no local. Isso inclui o provisionamento de usuários ou altera as configurações de firewall, pois tanto o cliente como o serviço de back-end usa a conectividade de saída para a porta 80 ou 443. Em outras palavras, nenhuma porta adicional precisa ser aberta para o tráfego de entrada e nenhum proxy é obrigatório.

Abordagem do proxy do aplicativo

A segunda abordagem para fazer recursos protegidos disponíveis fora do firewall é usar o serviço do Proxy do aplicativo do AD do Azure, atualmente em Visualização. Isso fornece acesso seguro a aplicativos da Web internos da organização e serviços através de protocolos Web HTTP e HTTPS.

A grande vantagem dessa abordagem é que os usuários podem desfrutar de SSO e uma experiência de aplicativo nativo e ainda usar um dispositivo não gerenciado, não associado a um domínio. Em um artigo anterior, discutimos o conceito de uma "associação do local de trabalho", que é uma versão leve de um dispositivo totalmente associado a um domínio (bit.ly/1tE7dRR). Isso suporta esses cenários BYOD, onde os usuários querem manter o controle de seu dispositivo pessoal.

o Proxy do aplicativo do AD do Azure fornece integração total com o AD do Azure, com suporte ao SSO, aplicativos de Software como um serviço e no local, autenticação multifatorial e de registro do dispositivo. O conector trás o recurso para o proxy do aplicativo e, portanto, o aplicativo móvel. Esses conectores essencialmente determinam o gtráfego e suportam redundância, escala e múltiplos sites.

Um proxy de aplicativo fornece algumas vantagens. Em primeiro lugar, você pode implementar um controle refinado a um nível de aplicativo, dispositivo, usuário e localização. Aplicativos existentes do cliente não precisam de modificação e os dispositivos em si não precisam ser modificados. Ele também suporta a autenticação multifatorial (MFA), que pode fornecer um nível extra de proteção de recursos altamente confidenciais. MFA fornece vários serviços de suporte, como alertas de fraude, listas brancas de IP e telefone móvel ou SMS como um segundo fator de autenticação.

A terceira vantagem de um proxy de aplicativo é que proporciona isolamento entre redes celulares e redes no local. Os serviços back-end nunca são expostos diretamente pois o proxy de aplicativo em si vive no AD do Azure e o conector alcança diretamente a partir do recurso protegido. Finalmente, um proxy de aplicativo protege contra ataques de negação de serviço, o que fornece a você controle sobre a limitação, gerenciamento de filas e de sessão.

Gerenciamento API

Uma terceira abordagem para fornecer acesso a recursos protegidos é o Gerenciamento API do Azure, que também se comporta como um proxy para os seus recursos no local. Isso permite que você exponha serviços da Web implementados dentro de seu firewall para o mundo exterior. Para fazer esta opção funcionar, você precisará fazer algumas modificações no seu servidor Web no local, bem como criar e configurar um API no portal do Azure. Você pode criar seu API tanto no .NET Web API ou no Node.js.

Primeiro, consideraremos a autenticação com o gerenciamento API do Azure - autenticação básica para fornecer acesso externo a um servidor Web baseado no IIS local. A primeira etapa para permitir este cenário é fazer algumas alterações em seu servidor da Web do IIS local e permitir a autenticação básica. Dentro do IIS, você pode escolher o ícone de autorização e detalhar a autenticação básica para adicionar um usuário. O Gerenciamento APi do Azure acessará o IIS local com este perfil de usuário.

A próxima abordagem que você pode usar com o Gerenciamento API do Azure é a autenticação secreta compartilhada. Isso significa que o proxy de gerenciamento API será necessário para armazenar uma chave secreta. Ele colocará essa chave no cabeçalho HTTP antes de tentar se conectar ao serviço Web back-end local. Não deve ser nenhuma surpresa que o serviço da Web back-end precisará puxar a chave secreta do cabeçalho HTTP e processar a solicitação de autorização.

Você pode implementar a autenticação secreta compartilhada, indo para o Portal de Gerenciamento do Azure, navegar para a seção de Gerenciamento do API e selecionando Políticas a partir do menu. Aqui, você adicionará uma política, que nada mais é do que uma chave secreta enviada para o seu servidor Web no local. O arquivo de definição de política que você adicionará é um documento XML.

Conexões híbridas

A quarto e, sem dúvida, mais simples abordagem para a concessão de acesso a recursos protegidos está usando as Conexões Híbridas (consulte a Figura 4), um recurso dos Serviços BizTalk do Azure, atualmente na visualização. As conexões híbridas aproveita a tecnologia de Relé de barramento do Serviço para criar uma conexão simples, segura e eficaz entre o processo no local e um serviço dos Serviços Móveis do Azure ou um site dos Sites da Web do Azure. Você pode usar conexões híbridas para se conectar a qualquer recurso no local que use TCP ou HTTP para conectividade, incluindo bancos de dados e soluções ERP, tais como SQL, Oracle e SAP.

Figura 4 Serviços BizTalk do Microsoft Azure — Conexões Híbridas

Um requisito para isso é que o processo no local deve ser acessível através de uma porta TCP estática, como o SQL Server na porta 1433. Você pode usar qualquer estrutura para se conectar ao recurso, incluindo Node.js, Java ou .NET Framework. A maioria dos requisitos de configuração do Relé do barramento do Serviçoé abstraída por Conexões Híbridas. Não existe mudanças necessárias para o código-fonte do processo no local.

Para usar as Conexões Híbridas, configure uma pequena quantidade de metadados no Portal de Gerenciamento do Azure. Instale um agente no servidor que hospeda o seu processo (SQL Server, MySQL, seu serviço Web e assim por diante). Existe uma conexão do Relé do barramento do Serviço debaixo das conerturas, utilizando uma chave de SAS para autenticação. Você pode girar as duas teclas do lado do serviço e do lado do cliente, independentemente de estar dentro do portal. Porque ele usa o Relé do barramento do serviço, não são necessários pontos de extremidade de entrada ou proxies.

Se preferir mais simplicidade em seus esforços de configuração e desenvolvedor, as Conexões Híbridas podem ser a sua solução. Melhor ainda, pelo fato de ele estar disponível na camada livre dos Serviços BizTalk do Azure, você pode usá-lo de forma rentável, pagando somente a largura de banda de saída.

Agora para uma demonstração

Como prometido, agora demonstraremos algumas das técnicas descritas aqui, usando um aplicativo iOS nativo mais seu back-end AMS como a plataforma. Adicionaremos um serviço Web no local e um SQL Server no local usando as Conexões Híbridas. Por uma questão de economia de espaço e utilização de recursos já existentes, consulte o tutorial da equipe do AMS em bit.ly/1mK1LQF. Nas instruções, você encontrará ramificações para recursos do tutorial adicional (bit.ly/1vFiPuv and bit.ly/1xLWuuF) para criar a solução completa, que consiste no seguinte:

Um back-end API da Web instalado como um serviço AMS e registrado com um locatário AD do Azure
Um aplicativo iOS nativo registrado com o mesmo locatário AD do Azure
Ligação bi-direcional dentro do locatário entre o API Web e o serviço AMS

Existem várias etapas que envolvem a criação de metadados no Portal de Gerenciamento do Azure, enquanto outras envolvem o uso de ferramentas de desenvolvimento nativas (Visual Studio, Xcode, Android e muito mais) para criar os aplicativos reais. Quando concluído, você deve ter um sistema de trabalho que requer autenticação em seu aplicativo iOS, inserindo credenciais AD do Azure. Em seguida, ele permitirá que você faça operações CRUD nos dados To Do. Adicione o código na Figura 5 para o código de serviço móvel.

Figura 5 Código do Cliente aproveita os recursos protegidos através de uma conexão híbrida

// Use the SQL Server connection
try
{
  SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder();
  builder["Data Source"] = "myserver";
  builder["Integrated Security"] = false;
  builder["Initial Catalog"] = "mydb";
  builder["User ID"] = "greg";
  builder["Password"] = "S3cr3t";
  int count = 0;
  string query = "SELECT COUNT(*) FROM mytable";
  using (SqlConnection conn = new SqlConnection(builder.ConnectionString))
  using (SqlCommand cmd = new SqlCommand(query, conn))
  {
    conn.Open();
    cmd.CommandType = System.Data.CommandType.Text;
    count = Convert.ToInt32(cmd.ExecuteScalar());
  }
  string results = string.Format("Count of records in mytable is {0}", 
    count);
  Services.Log.Info(results);
}
catch (Exception ex)
{
  Services.Log.Error(ex.Message);
}
// Use the Web service connection
try
{
  const string URL = "http://mydevbox:31106/";
  HttpClient client = new HttpClient();
  client.BaseAddress = new Uri(URL);
  client.DefaultRequestHeaders.Accept.Clear();
  client.DefaultRequestHeaders.Accept.Add(
  new MediaTypeWithQualityHeaderValue("application/json"));
  string response = await client.GetStringAsync("api/values/5");
  Services.Log.Info("Accessing the web service succeeded.");
}
catch (Exception ex)
{
  Services.Log.Error(ex.InnerException.Message);
}

Nas informações de conexão para SQL Server e o endereçamento do serviço Web (um simples modelo de serviço Web), apenas o nome da Conexão Híbrida está envolvido.

Conclusão

A identidade está se tornando cada vez mais importante no mundo do BYOD. As empresas estão sob crescente pressão para oferecer suporte a dispositivos móveis no local de trabalho. Se torna mais complexo pelo fato de que vivemos em um mundo híbrido. Os principais recursos estão localizados na nuvem e no local. A autenticação pode ocorrer na nuvem ou no local, ou ambos. Os recursos protegidos podem incluir aplicativos de negócios, serviços em execução no local ou serviços Web hospedados na nuvem. Com tantas variáveis, você precisa de várias abordagens flexíveis.

Para detalhes completos sobre esta implementação, verifique a publicação no blog do Go Live on Azure em bit.ly/1rVbtCp, e para um tratamento com base no Java do tópico, em bit.ly/1zW7XpZ.

Greg Oliver *entrou para a organização Microsoft Azure ISV em 2010. Ele passa a maior parte de seu tempo ajudando as empresas com os seus planos de migração e implementações. Mais recentemente, ele tem trabalhado com uma empresa de jogos de consumo populares com a sua migração a partir de um provedor em nuvem concorrente. Antes de entrar na Microsoft, ele era um parceiro de tecnologia em uma empresa startup. *

Bruno Terkaly é um engenheiro de software diretor da Microsoft com o objetivo de permitir o desenvolvimento dos principais aplicativos e serviços da indústria através de dispositivos. Ele é responsável por conduzir a nuvem superior e oportunidades móveis nos Estados Unidos e além de uma perspectiva de ativação da tecnologia. Ele ajuda os parceiros a trazer os seus aplicativos para o mercado, fornecendo orientação de arquitetura e compromisso técnico profundo durante a avaliação, desenvolvimento e implantação do ISV. Ele também trabalha em estreita colaboração com os grupos de engenharia móvel e em nuvem, fornecendo feedback e influenciando o mapa.

Agradecemos ao seguinte especialista técnico da Microsoft pela revisão deste artigo: Santosh Chandwani