Usar a autenticação multilocatário de servidor a servidor

 

Publicado: janeiro de 2017

Aplicável a: Dynamics 365 (online)

Este é o cenário mais comum e o que é usado para aplicativos distribuídos com o Microsoft AppSource, mas você também pode usar o multilocatário sem listar o aplicativo com o Microsoft AppSource.

Cada organização do Dynamics 365 (online) é associada a um locatário do Active Directory do Azure (Azure AD). Seu aplicativo Web ou serviço é registrado com seu próprio locatário do Azure AD.

Neste cenário, qualquer locatário do Dynamics 365 (online) pode potencialmente utilizar seu aplicativo multilocatário após conceder permissão para que o aplicativo acesse dados.

Neste tópico

Requisitos

Visão geral: Desenvolver e testar o aplicativo

Criar um usuário do aplicativo associado ao aplicativo registrado no Dynamics 365

Testar o aplicativo usando o locatário do Dynamics 365

Testar o aplicativo usando um locatário do Dynamics 365 separado

Preparar um método para implantar o usuário do aplicativo

Requisitos

Para criar e testar um aplicativo multilocatário que use autenticação de servidor a servidor (S2S), é necessário:

  • Um locatário do Azure AD que será usado para publicar o aplicativo ou serviço.

  • Duas assinaturas do Dynamics 365 (online)

    • Uma será associada ao locatário do Azure AD que será usado para publicar o aplicativo ou serviço.

    • A outra pode ser uma assinatura de avaliação para testar como um assinante acessará o aplicativo.

Visão geral: Desenvolver e testar o aplicativo

O aplicativo que você criar deve ser registrado com o locatário do Azure AD que será usado quando você publicar o aplicativo.

Em um alto nível, o processo consiste em:

  1. Criar um aplicativo Web multilocatário registrado com seu locatário do Azure AD.

  2. Criar um usuário do aplicativo associado ao aplicativo registrado em seu locatário do Dynamics 365 (online)

  3. Criar uma função de segurança personalizada e atribuí-la ao usuário do aplicativo em seu locatário do Dynamics 365 (online)

  4. Testar o aplicativo usando o locatário do Dynamics 365 (online)

  5. Testar o aplicativo usando um locatário do Dynamics 365 (online) separado

Para obter um exemplo completo desse processo, consulte Passo a passo: Autenticação de servidor para servidor multilocatário.

Criar um aplicativo Web multilocatário registrado com seu locatário do Azure AD

Você criará um aplicativo Web multilocatário ou serviço que utilize o Azure AD como o provedor de autenticações.

Como se faz isso exatamente não será o foco deste tópico. Há diversas maneiras como abordar isso e fazer e as escolhas que se ajustem às suas preferências ou requisitos. Consulte os links a seguir para saber mais e ver exemplos:

O Azure AD exige os seguintes valores para registrar seu aplicativo:

Valor

Descrição

URI da ID do Aplicativo

O identificador de um aplicativo. Este valor é enviado ao Azure AD durante a autenticação para indicar de qual aplicativo o chamador deseja um token. Além disso, o valor é incluído no token para que o aplicativo saiba que é o destino planejado.

URL de resposta e URI de redirecionamento

No caso de uma API da Web ou de um aplicativo Web, a URL de resposta é o local para o qual o Azure AD enviará a resposta da autenticação, incluindo um token se a autenticação for bem-sucedida.

ID do cliente

A ID de um aplicativo, que é gerada pelo Azure AD quando o aplicativo for registrado. Ao solicitar um código de autorização ou um token, a ID do cliente e a chave serão enviadas ao Azure AD durante a autenticação.

Chave

A chave que é enviada com uma ID do cliente ao fazer autenticação no Azure AD para chamar a API da Web.

Quando o aplicativo for registrado, será designado um ID do Objeto do Azure Active Directory, um identificador exclusivo do aplicativo registrado.

Se você criar um novo aplicativo MVC via ASP.NET com o Visual Studio 2015 você terá opções para especificar que o aplicativo oferecerá suporte à funcionalidade de multilocatário. Um modelo para um aplicativo MVC fornece a opção para especificar o tipo de autenticação que ocorre. Você terá a opção de escolher o método de autenticação configurando as propriedades do projeto quando criar o aplicativo. O diagrama a seguir mostra as opções disponíveis:

ASP.NET MVC Change Authentication Dialog

Quando você configurar o projeto com essas opções, ele será configurado para usar o middleware e o scaffolding OWIN para um aplicativo básico que ofereça suporte a esse cenário. Com algumas alterações básicas, ele poderá ser adaptado para funcionar com o Dynamics 365 (online). Esta é abordagem demonstrada em Passo a passo: Autenticação de servidor para servidor multilocatário.

No processo de criação e registro de seu aplicativo para desenvolvimento, você muito provavelmente usará https://localhost como os valores URL de Entrada e URL de Resposta para que possa testar e depurar o aplicativo localmente antes de publicá-lo. Você precisará alterar esses valores antes de publicar o aplicativo.

Ao registrar o aplicativo, você deve gerar uma chave, também conhecida como ClientSecret Essas chaves podem ser definidas para ter a duração de um ou dois anos. Como host do aplicativo, você deve tratar esse valor como uma senha e é sua responsabilidade gerenciar a renovação das chaves antes que expirem. Talvez você queira usar o Cofre de Chaves do Azure.Para obter mais informações:https://azure.microsoft.com/en-us/services/key-vault/

Conceder ao aplicativo os direitos de acesso a dados do Dynamics 365 (online)

Este é o motivo pelo qual a instância do Dynamics 365 (online) deve ser associada ao locatário do Azure AD. Se o locatário do Azure AD não estiver associado a um locatário do Dynamics 365 (online), você não poderá executar as seguintes etapas:

  1. Vá para https://portal.azure.com e selecione Azure Active Directory.

  2. Clique em Registros de aplicativo e procure pelo aplicativo que você criou usando o Visual Studio.

  3. Você precisa atribuir ao aplicativo os privilégios para acessar dados do Dynamics 365 (online). Na área Acesso à API clique em Permissões necessárias . Você verá que ele já tem permissões para o Active Directory do Microsoft Azure.

  4. Clique em Adicionar, então em Selecionar uma API. Na lista, selecione Dynamics 365 e clique no botão Selecionar.

  5. Em Selecionar permissões, selecione Acessar o Dynamics 365 como usuários da organização. Em seguida, clique no botão Selecionar.

  6. Clique Concluído para adicionar essas permissões. Quando terminar, você deverá ver as permissões aplicadas.

    Grant Dynamics 365-Permissions to application

Criar um usuário do aplicativo associado ao aplicativo registrado no Dynamics 365

Quando seu aplicativo acessa os dados do Dynamics 365 de um dos assinantes do aplicativo, ele exigirá um usuário do aplicativo na organização do Dynamics 365 do assinante. Como qualquer usuário do Dynamics 365, esse usuário do aplicativo deve estar associado a pelo menos um direito de acesso que defina os dados que o usuário pode acessar.

A entidade systemuser tem três novos atributos para armazenar esses dados.

Nome do esquema

Nome para exibição

Digite

Descrição

ApplicationId

ID do Aplicativo

UniqueidentifierType

O identificador do aplicativo. É usada para acessar dados em outro aplicativo.

ApplicationIdUri

URI da ID do Aplicativo

StringType

O URI usado como um identificador lógico exclusivo para o aplicativo externo. Isso pode ser usado para validar o aplicativo

AzureActiveDirectoryObjectId

ID do objeto do Azure AD

UniqueidentifierType

É a ID do objeto do diretório de aplicativos.

Esse valor da propriedade systemuserAzureActiveDirectoryObjectId deve ser uma referência à ID do objeto do Azure Active Directory do aplicativo registrado. Isso será definido no Dynamics 365 quando o usuário do aplicativo for criado, com base no valor ApplicationId.

Observação

Quando desenvolve inicialmente o aplicativo com seu próprio locatário do Dynamics 365 e com o locatário do Azure AD associado a ele, você pode simplesmente criar o usuário do aplicativo, pois o aplicativo registrado já faz parte do locatário do Azure AD.

No entanto, para criar o usuário do aplicativo em uma organização diferente para teste, ou sempre que um assinante usar seu aplicativo, é necessário primeiramente conceder permissão ao aplicativo. Portanto, as etapas no processo são diferentes. Consulte Testar o aplicativo usando um locatário do Dynamics 365 separado para obter mais informações.

Criar um direito de acesso para o usuário do aplicativo

Na próxima etapa você criará um usuário do aplicativo Dynamics 365. Os privilégios e direitos de acesso desse usuário serão definidos pelo direito de acesso personalizado que você configurar. Antes de criar o usuário do aplicativo, será preciso criar um direito de acesso personalizado para que você possa associá-lo ao usuário. Para saber mais: TechNet: Criar ou editar um direito de acesso.

Observação

O usuário do aplicativo não pode estar associado a um dos direitos de acesso padrão do Dynamics 365. Você deve criar um direito de acesso personalizado a ser associado ao usuário do aplicativo.

Criar manualmente um usuário do aplicativo Dynamics 365

O procedimento para criar esse usuário é diferente do processo para criar um usuário licenciado. Use as seguintes etapas:

  1. Navegue até Configurações > Segurança > Usuários

  2. Na lista suspensa da exibição, selecione Usuários do aplicativo.

  3. Clique em Novo. Depois, verifique se você está usando o formulário Usuário do aplicativo.

    Se você não vir os campos ID do Aplicativo, URI da ID do Aplicativo e ID do Objeto do Azure AD no formulário, você deverá selecionar o formulário Usuário do aplicativo na lista:

    Select Application User Form

  4. Adicionar os valores adequados aos campos:

    Campo

    Valor

    ID do Aplicativo

    O valor da ID do Aplicativo para o aplicativo registrado com o Azure AD.

    Nome Completo

    O nome do seu aplicativo.

    Email Primário

    O endereço de email que deseja que os assinantes usem para entrar em contato com você.

    Os campos Nome de usuário, URI da ID do Aplicativo e ID do Objeto do Azure AD estão bloqueados e você não pode definir valores para esses campos.

    Quando você cria esse usuário, os valores desses campos serão recuperados do Azure AD com base no valor ID do aplicativo ao salvar o usuário.

  5. Associe o usuário do aplicativo ao direito de acesso personalizado que você criou em Criar um direito de acesso para o usuário do aplicativo. Para saber mais: TechNet: Atribuir um direito de acesso a um usuário

Testar o aplicativo usando o locatário do Dynamics 365

Como o aplicativo foi registrado no locatário do Azure AD e o usuário do aplicativo na sua organização de desenvolvimento já está configurado, você pode continuar a desenvolver o aplicativo em relação a seu próprio locatário do Dynamics 365. Mas isso não é um teste válido da capacidade de multilocatário. É necessário testar o aplicativo em um locatário do Dynamics 365 separado.

Testar o aplicativo usando um locatário do Dynamics 365 separado

Antes de testar seu aplicativo com um locatário do Dynamics 365 separado, um administrador do locatário do Azure AD precisa conceder permissão ao aplicativo. O administrador concede permissão indo até o aplicativo usando um navegador. Na primeira vez que acessar o aplicativo, uma caixa de diálogo como esta será exibida:

Grant consent to access Dynamics 365 data

Ao conceder permissão, o aplicativo registrado será adicionado à lista de aplicativos empresariais do Azure AD e ficará disponível aos usuários do locatário do Azure AD.

Somente depois que o administrador conceder permissão, você poderá criar o usuário do aplicativo no locatário do Dynamics 365 do assinante. Você pode criar manualmente o usuário do aplicativo usando as etapas descritas em Criar manualmente um usuário do aplicativo Dynamics 365.

Em testes iniciais, é aconselhável executar essas etapas manualmente. Quando estiver pronto para disponibilizar seu aplicativo ou serviço para os assinantes, você vai querer ter um procedimento mais eficiente. Isso será abordado na próxima seção.

Preparar um método para implantar o usuário do aplicativo

Depois que os assinantes concederem permissão a seu aplicativo ou serviço, você precisará de um modo fácil e confiável para que eles adicionem o usuário do aplicativo e quaisquer outros componentes necessários à organização do Dynamics 365.

Você deve incluir um direito de acesso personalizado que define quais privilégios o aplicativo exige e então certificar-se de que o aplicativo esteja associado a esse direito de acesso personalizado. Como um direito de acesso personalizado pode ser incluído em uma solução, é necessário preparar uma solução gerenciada que contenha a definição do direito de acesso personalizado e quaisquer outros componentes da solução que o aplicativo exigir.

Para saber mais sobre a criação de direitos de acesso personalizados, consulte

Para saber mais sobre a criação de uma solução Dynamics 365, consulte os seguintes tópicos:

No entanto, o usuário do aplicativo não pode ser incluído em uma solução, por isso você precisará fornecer um modo de criar esse usuário do aplicativo e associá-lo ao direito de acesso personalizado.

Há várias maneiras de se fazer isso, incluindo escrever seu próprio programa usando o SDK do Microsoft Dynamics 365 e fazer com que um assinante execute o programa.

O SDK do Microsoft Dynamics 365 fornece um aplicativo de Implantação de Pacotes do CRM que pode ser usado para a preparação de um pacote para automatizar a transferência de soluções e dados para uma organização do Dynamics 365 diferente.Para obter mais informações:Criar pacotes para Dynamics 365 Package Deployer

Confira Também

Passo a passo: Autenticação de servidor para servidor multilocatário
Usar a autenticação de locatário único de servidor a servidor
Criar aplicativos da web usando a autenticação S2S (servidor para servidor)
Conectar a Microsoft Dynamics 365

Microsoft Dynamics 365

© 2017 Microsoft. Todos os direitos reservados. Direitos autorais