Planejando a infraestrutura necessária para o novo modelo de aplicativo no SharePoint 2013

  • Article

Artigo original publicado na terça-feira, dia 4 de setembro de 2012

O SharePoint 2013 traz com ele um novo modelo de aplicativo, que chamamos sutilmente de "modelo de aplicativo" ou modelo de aplicativo em nuvem". Embora proporcione um conjunto de oportunidades totalmente novo sob uma perspectiva de desenvolvimento, ele também possui requisitos de infraestrutura que você deve planejar e criar para oferecer suporte a eles. Quando penso sobre o modelo de aplicativo, há três grandes partes que realmente analiso:

  1. O modelo de desenvolvimento - Trata-se de como desenvolverei meu aplicativo, quais novos recursos irei aproveitar, etc. É basicamente a atividade de um desenvolvedor.
  2. O modelo de segurança - O modelo de segurança desses novos aplicativos é uma combinação interessante de "coisas". Você tem um novo conceito de entidade de segurança, que é como você define direitos para seus aplicativos. Há o modelo OAuth, que define qual conteúdo você pode acessar, bem como um mecanismo para apresentar o SharePoint com um token que descreve quem você é (de forma bem parecida com as declarações para aplicativos). O modelo de segurança e os meios por meio dos quais esses tokens são criados e apresentados varia consideravelmente, dependendo de dois fatores: se o aplicativo é hospedado no SharePoint ou em outro local; e se você está usando os Serviços de Controle de Acesso (ACS) como agente de confiança ou não. Há várias coisas aqui que não abordarei neste post, mas que dizem respeito a atividades de desenvolvedores e profissionais de TI.
  3. A infraestrutura - Aqui, falaremos sobre toda a "cola" que faz com que os aplicativos funcionem em uma organização. Isso inclui os aplicativos de serviço, o domínio e prefixo do aplicativo, DNS, SSL e configurações de aplicativos Web. Esta é uma atividade principalmente de profissionais de TI e é a base deste post. Esta postagem também será focada nos aplicativos hospedados no próprio SharePoint em relação a um aplicativo hospedado externamente, em outro site ou nuvem, como o Windows Azure. Quando você instala um aplicativo hospedado no SharePoint, um novo SPWeb é criado para ele. Desse modo, cada aplicativo obtém um conjunto próprio de dados e não pode sobrescrever os dados de outro aplicativo. Ele também proporciona uma camada de segurança, de modo que alguém que tenha os direitos a um aplicativo não possa ter códigos mal-intencionados que usem os direitos do usuário atual para acessar dados em outro site do farm. Essa é uma entidade básica importante dos aplicativos com base no novo modelo de aplicativo para lembrar: quando eles são hospedados no SharePoint, um aplicativo = um SPWeb.

Agora, vamos começar a trabalhar na lista desses diferentes componentes de infraestrutura. Em primeiro lugar (e mais importante), você deve garantir que haja uma instância dos aplicativos de serviço Gerenciamento de Aplicativos e Configurações de Inscrição criada e em execução no farm. O serviço Gerenciamento de Aplicativos é usado para coisas como acompanhar os aplicativos e implantações, licenciamento, etc. O serviço Configurações de Inscrição é o mesmo aplicativo de serviço usado para implantações com vários locatários e também é usado pelo modelo de aplicativo para criar os URLs exclusivos usado pelos aplicativos.

Então, como esses URLs são criados? Tudo começa com a configuração de aplicativos realizada na Administração Central. Quando você acessa a Administração Central, é possível encontrar uma nova seção chamada Aplicativos. Se você clicar nela, verá uma opção Configure URLs de Aplicativos. Lá, você encontrará dois valores usados para criar o URL de um aplicativo: Domínio do Aplicativo e Prefixo de Aplicativo. O Domínio do Aplicativo é análogo ao nome do host que será usado para todos os aplicativos no farm. Há três coisas que você deve considerar ao planejar esse nome:

  1. Como é usado para todo o farm, é preciso que haja o mesmo nível de planejamento e reflexão usado para outros aplicativos Web.
  2. Além disso, ele precisa ser um nome de domínio totalmente qualificado (você verá que tentar usar um nome ao estilo NetBIOS para ele não funciona bem para resolução do nome). 
  3. Por fim, ele NÃO pode ser um domínio filho de seus aplicativos Web.

Agora, vejamos um exemplo específico. Suponha que seus aplicativos Web são team.contoso.com, my.contoso.com e portal.contoso.com. Em primeiro lugar, você provavelmente não deseja usar apenas "contoso.com" para o Domínio de Aplicativos, pois isso exigirá a criação de uma entrada DNS curinga para TODO o domínio contoso.com que aponta para o ponto de extremidade dos aplicativos (falaremos mais sobre isso em breve). Além disso, você também não deseja usar algo como "apps.contoso.com", pois este é um domínio filho daquele usado para os aplicativos Web (todos com raiz em "contoso.com"). Por isso, uma opção melhor com base nessas regras é algo como “contosoapps.com”. 

O valor de Prefixo de Aplicativo pode ser o que você quiser. Ele é conectado à primeira parte do URL do aplicativo, sobre o qual falaremos a seguir.

Mencionei o uso de uma entrada DNS curinga anteriormente, e é essa a próxima parte abordada. Quando um aplicativo é instalado e hospedado no SharePoint, ele tem um URL parecido com este: https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx. Os elementos do URL são decompostos da seguinte maneira:

  • “apps” – é o valor de Prefixo de Aplicativo (mencionado anteriormente) que você informou na administração central.
  • “87e90ada14c175” – é um valor exclusivo com base no conjunto do site e na Web, onde o aplicativo está instalado
  • “contosoapps.com” – é o Domínio do Aplicativo informado na administração central.
  • “myapp” – é o nome do aplicativo que foi instalado. O restante do URL (pages/default.aspx) é o que está contido no SPWeb onde o aplicativo está instalado.

Conforme você olhar para o URL e como ele é formado, com sorte compreenderá porque convém usar uma entrada DNS curinga. Como a primeira parte do URL será diferente para cada instância de aplicativo instalada (por mais que o mesmo aplicativo seja instalado em vários conjuntos de sites), não é viável atualizar continuamente o DNS para cada instância. Isso significa que, para o DNS do cenário que descrevi aqui, convém ter uma entrada DNS curinga para *.contosoapps.com. Já o endereço IP para o qual ele aponta é algo que discutiremos apenas um pouco.

Há uma entrada SSL curinga relacionada à entrada DNS curinga. Sejamos claros neste ponto: se você está usando aplicativos, deve usar SSL. O modelo de aplicativo envolve a transferências de tokens de acesso OAuth, que descrevem quem são o usuário e aplicativo atuais. Assim como se você estivesse transferindo tokens SAML para um usuário, convém criptografar o canal pelo qual esses tokens passam para evitar qualquer tipo de ataque ao estilo replay, que concede acesso ao conteúdo a alguém por aí que possa estar se aproveitando do tráfego de sua rede. O uso de SSL impede que esses cenários ocorram e, como você observou, os URLs desses aplicativos serão diferentes para cada instância instalada. Isso também significa que, para que haja capacidade de gerenciamento, você precisará de um certificado SSL curinga. Novamente, em nosso cenário, obteremos um certificado SSL curinga para *.contosoapps.com.

Até agora, falamos sobre os aplicativos de serviço necessários, a configuração necessária para o Domínio e Prefixo do Aplicativo, como os URLs são formados e entradas DNS e SSL necessárias. Agora, para juntarmos tudo, precisamos falar sobre como as solicitações de aplicativos são encaminhadas. De modo geral, você precisará de um aplicativo Web do SharePoint separado apenas para realizar o encaminhamento de solicitações de aplicativo. Vejamos o porquê. Novamente, suponha que você tem três aplicativos Web definidos da seguinte maneira. Todos usam SSL; portanto, usamos endereços IP exclusivos para cada um:

  • team.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portal.contoso.com – 192.168.1.12

Conforme descrito anteriormente, você só pode ter um Domínio do Aplicativo no farm, e ele não pode ser um domínio filho. Isso gera dois problemas muito sérios com os aplicativos acima:

  • Se instalamos aplicativos em cada um desses aplicativos Web, como as solicitações de aplicativos são encaminhadas aos aplicativos Web corretos? Temos apenas um Domínio do Aplicativo, mas três aplicativos Web.
  • Se tentarmos encaminhar uma solicitação e aplicativo para um desses aplicativos Web existentes, o SSL falhará. Por quê? Porque como estamos usando SSL em todos os aplicativos Web (como estamos usando aplicativos), todos terão um certificado SSL semelhante a *.contoso.com. Por isso, não podemos encaminhar solicitações de aplicativo a eles, já que não é possível obter um curinga SSL que funcione em *.contoso.com e *.contosoapps.com (que é o que nossos aplicativos estarão usando).

A solução é criar o quarto aplicativo Web. Você pode criá-lo sem um nome para o cabeçalho de host e atribuir a ele um IP compartilhado de 192.168.1.13. No DNS, a entrada curinga para *.contosoapps.com apontará para 192.168.1.13. No fim, o que acontece é que o aplicativo Web dos aplicativos "escuta" o endereço IP, e o módulo http do SharePoint responsável pelo encaminhamento pegará a solicitação do aplicativo. Em seguida, ele usará o aplicativo de serviço Gerenciamento de Aplicativos para determinar qual aplicativo Web está de fato hospedando aquele aplicativo e reencaminhar a solicitação a ele. A seguir, a solicitação é atendida naquele aplicativo Web, conjunto de sites e SPWeb onde o aplicativo se encontra, de modo que todas as configurações de segurança e autenticação relacionadas a ele sejam aplicadas corretamente.

Agora, a configuração do farm fica assim:

  •  Configuração dos Aplicativos
    • Domínio do Aplicativo – contosoapps.com
    • Prefixo de Aplicativo – apps
  • Aplicativos Web

    • team.contoso.com

      • Endereço IP: 192.168.1.10
      • Certificado SSL: *.contoso.com

    • my.contoso.com

      • Endereço IP: 192.168.1.11
      • Certificado SSL: *.contoso.com

    • portal.contoso.com

      • Endereço IP: 192.168.1.12
      • Certificado SSL: *.contoso.com

    • Sem cabeçalho de host, mas você pode usar algo como contosoapps, etc. (na realidade, isso não tem importância, pois não estamos realizando o encaminhamento com base no cabeçalho do host, e sim com base no endereço IP). PORÉM, se você estivesse usando cabeçalhos de host e todos os aplicativos Web usassem o mesmo endereço IP, o aplicativo Web ouvinte não poderia ter valor de cabeçalho de host. Caso contrário, o IIS não pegaria as solicitações de aplicativo de nenhum aplicativo Web.

      • Endereço IP: 192.168.1.13
      • Certificado SSL: *.contosoapps.com
  • DNS
    • team.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portal.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

Agora que abordamos todos os aspectos de configuração de infraestrutura dos aplicativos, há alguns outros pontos que devem ser lembrados durante o planejamento para a implantação de novos aplicativos para SharePoint 2013:

  • Os aplicativos do SharePoint não funcionam em aplicativos Web que usam SAML. Se você estiver usando autenticação SAML, não será possível usar os aplicativos do SharePoint nesses aplicativos Web. Esperamos que esse problema seja solucionado em um service pack futuro ou algum outro tipo de patch, mas essa é uma limitação do SharePoint 2013 RTM.
  • Os aplicativos do SharePoint não oferecem suporte a várias zonas (isto é, AAM); todas as solicitações são atendidas na zona padrão. se você estiver usando AAM para oferecer suporte a várias zonas, provavelmente não será possível usar os aplicativos do SharePoint. Todos os aplicativos são atendidos na zona padrão. Por isso, em teoria, se a zona padrão fosse exposta, de modo que todos pudessem acessá-la, e você estivesse usando o mesmo mecanismo de autenticação em todas as zonas (com possíveis limitações, muito detalhadas para serem abordadas neste momento), possivelmente tudo funcionaria. Porém, mais uma vez, se você está usando zonas, normalmente é porque você a) não deseja que todos os pontos de extremidade fiquem expostos a qualquer pessoa ou b) DESEJA usar métodos de autenticação diferentes. Novamente, isso é algo que pode mudar no futuro, mas, por enquanto, é o que está disponível para o SharePoint 2013 RTM.

 

Apenas mais uma observação importante: pode parecer que há muitas configurações, e realmente há. Entretanto, lembre-se de que, se você estiver usando o Office 365, ele cuidará de tudo para você: sem bagunça, sem confusão, apenas aplicativos fáceis de instalar e usar. Leve-o em consideração ao refletir sobre suas opções.

Conclusão: os aplicativos do SharePoint constituem uma parte importante do SharePoint 2013, mas exigem planejamento e um trabalho prévio de design para garantir que a infraestrutura de suporte esteja em operação.

 

Este é um post localizado. O artigo original está em Planning the Infrastructure Required for the new App Model in SharePoint 2013