Modelo de identidade
Os Serviços de Comunicação do Azure são um serviço independente de identidade, que oferece vários benefícios:
- Reutilize as identidades existentes do sistema de gerenciamento de identidades e mapeie-as com as identidades dos Serviços de Comunicação do Azure.
- Funciona bem com qualquer sistema de identidade existente e não tem dependência em um provedor de identidade específico.
- Mantenha os dados do usuário, como seu nome, privados, pois você não precisa duplicá-los nos Serviços de Comunicação do Azure.
O modelo de identidade dos Serviços de Comunicação do Azure funciona com dois conceitos principais.
Identidade/mapeamento do usuário
Ao criar uma identidade de usuário por meio do SDK ou da API REST, os Serviços de Comunicação do Azure criam um identificador de usuário exclusivo. Identificadores externos, como números de telefone, IDs de usuário/dispositivo/aplicativo ou nomes de usuário, não podem ser usados diretamente nos Serviços de Comunicação do Azure. Em vez disso, use as identidades dos Serviços de Comunicação e mantenha um mapeamento para seu próprio sistema de ID de usuário, conforme necessário. A criação de identidades de usuário do Serviço de Comunicação do Azure é gratuita e os encargos são incorridos somente quando o usuário consome modalidades de comunicação, como um chat ou uma chamada. A forma como você usa a identidade dos Serviços de Comunicação gerada depende do seu cenário. Por exemplo, você poderá mapear uma identidade 1:1, 1:N, N:1 ou N:N e usá-la para usuários ou aplicativos humanos. Um usuário pode participar de várias sessões de comunicação, usando vários dispositivos simultaneamente. Gerenciar um mapeamento entre as identidades de usuário dos Serviços de Comunicação do Azure e seu próprio sistema de identidade é sua responsabilidade como desenvolvedor e não é interno. Por exemplo, adicione uma coluna CommunicationServicesId
em sua tabela de usuário existente para armazenar a identidade associada dos Serviços de Comunicação do Azure. Um design de mapeamento é descrito com mais detalhes na arquitetura cliente-servidor.
Tokens de acesso
Depois que uma identidade de usuário é criada, um usuário precisa de um token de acesso com escopos específicos para participar de comunicações usando chat ou chamadas. Por exemplo, somente um usuário com um token com o escopo chat
pode participar do chat e um usuário com um token com escopo voip
pode participar de uma chamada VoIP. Um usuário pode ter vários tokens simultaneamente. Os Serviços de Comunicação do Azure dão suporte a vários escopos de token para considerar os usuários que exigem acesso total versus acesso limitado. Os tokens de acesso têm as propriedades a seguir.
Propriedade | Descrição |
---|---|
Assunto | A identidade do usuário representada pelo token. |
Expiração | Um token de acesso é válido por pelo menos 1 hora e até 24 horas. Após expirar, o token de acesso fica inválido e não pode ser usado para acessar o serviço. Para criar um token com um tempo de expiração personalizado, especifique a validade desejada em minutos (>=60, <1440). Por padrão, o token é válido por 24 horas. Recomendamos o uso de tokens de vida útil curta para reuniões pontuais e tokens de vida útil mais longa para usuários que usam o aplicativo por períodos mais longos. |
Escopos | Os escopos definem quais primitivos de comunicação (Chat/VoIP) podem ser acessados com o token. |
Um token de acesso é um JWT (Token Web JSON) e tem proteção de integridade. Ou seja, suas declarações não podem ser alteradas sem invalidar o token de acesso porque a assinatura do token não corresponde mais. Se os primitivos de comunicação forem usados com tokens inválidos, o acesso será negado. Mesmo que os tokens não sejam criptografados ou ofuscados, seu aplicativo não deve depender do formato de token ou de suas declarações. O formato do token pode ser alterado e não faz parte do contrato oficial de API. Os Serviços de Comunicação do Azure dão suporte aos escopos para tokens de acesso a seguir.
Escopos de token de chat
Há suporte para três escopos de token de chat diferentes. As permissões para cada escopo são descritas na tabela a seguir.
chat
chat.join
chat.join.limited
Escopo de funcionalidade/token | chat | chat.join | chat.join.limited |
---|---|---|---|
Criar a conversa de chat | N | N | N |
Atualizar o thread de chat com a ID | N | N | N |
Excluir thread de chat com ID | N | N | N |
Adicione o participante a um thread de chat | N | S | N |
Remover um participante de uma conversa de chat | N | S | N |
Obter threads de chat | N | N | S |
Obter thread de chat com a ID | N | N | S |
Obter ReadReceipt | N | N | S |
Criar ReadReceipt | N | N | S |
Criar mensagem para o thread de chat com a ID | N | N | S |
Obter mensagem com a ID da mensagem | N | N | S |
Atualizar sua própria mensagem com a ID da mensagem | N | N | S |
Excluir sua própria mensagem com a ID da mensagem | N | N | S |
Enviar indicador de digitação | N | N | S |
Obter participante para a ID do thread | N | N | S |
Escopos de token VoIP
Há suporte para dois escopos de token VoIP. As permissões para cada escopo são descritas na tabela a seguir.
voip
voip.join
Escopo de funcionalidade/token | voip | voip.join |
---|---|---|
Iniciar uma chamada voIP | N | N |
Inicie uma chamada VoIP em Virtual Rooms, quando o usuário já estiver convidado para a Sala | N | S |
Ingressar em uma chamada VoIP em andamento | N | S |
Ingressar em uma chamada VoIP em andamento no Virtual Rooms, quando o usuário já estiver convidado para a Sala | N | S |
Todas as outras operações em chamada, como ativar/desativar mudo, compartilhamento de tela etc. | N | S |
Todas as outras operações em chamada, como ativar/desativar mudo, compartilhamento de tela etc. em Virtual Rooms | Determinado pela função de usuário | Determinado pela função de usuário |
Use o escopo voip.join
junto com Salas para criar uma chamada agendada em que somente os usuários convidados tenham acesso e onde os usuários são proibidos de criar outras chamadas.
Revogar ou atualizar o token de acesso
- A biblioteca de identidades dos Serviços de Comunicação do Azure pode ser usada para revogar um token de acesso antes do seu tempo de expiração. A revogação de token não é imediata. Pode levar até 15 minutos para propagar.
- A exclusão de uma identidade, um recurso ou uma assinatura revoga todos os tokens de acesso.
- Se você quiser remover a capacidade do usuário de acessar a funcionalidade específica, revogue todos os tokens de acesso do usuário. Em seguida, emita um token de acesso que tenha um conjunto mais limitado de escopos.
- A rotação de chaves de acesso revoga todos os tokens de acesso ativos que foram criados usando uma tecla de acesso anterior. Consequentemente, todas as identidades perdem o acesso aos Serviços de Comunicação do Azure e precisam de novos tokens de acesso.
Arquitetura do servidor-cliente
Crie e gerencie tokens de acesso do usuário por meio de um serviço confiável e não crie tokens em seu aplicativo cliente. A cadeia de conexão ou as credenciais do Microsoft Entra necessárias para criar tokens de acesso do usuário precisam ser protegidas, passando-os para um cliente correria o risco de vazar o segredo. A falha ao gerenciar corretamente tokens de acesso pode resultar em encargos extras em seu recurso quando os tokens são dispensados livremente e são mal utilizados por outra pessoa.
Caso armazene em cache tokens de acesso a um repositório de backup, recomendamos criptografar os tokens. Um token de acesso fornece acesso a dados confidenciais e pode ser usado para atividades mal-intencionadas se não estiver protegido. Qualquer pessoa com o token de acesso de um usuário pode acessar os dados de chat desse usuário ou participar de chamadas representando o usuário.
Inclua somente os escopos no token de que seu aplicativo cliente precisa para seguir o princípio de segurança de privilégios mínimos.
- Um usuário inicia o aplicativo cliente.
- O aplicativo cliente entra em contato com seu serviço de gerenciamento de identidades.
- O serviço de gerenciamento de identidade autentica o usuário do aplicativo. É possível ignorar a autenticação para cenários em que o usuário é anônimo, mas tenha cuidado para adicionar outras medidas de proteção, como limitação e CORS ao seu serviço, para atenuar o abuso de token.
- Criar ou localizar uma identidade dos Serviços de Comunicação para o usuário.
- Cenário de identidade estável: seu serviço de gerenciamento de identidades mantém um mapeamento entre identidades de aplicativo e identidades de Serviços de Comunicação. (As identidades do aplicativo incluem seus usuários e outros objetos endereçáveis, como serviços ou bots.) Se a identidade do aplicativo for nova, uma nova identidade de comunicação será criada e um mapeamento será armazenado.
- Cenário de identidade efêmera: o serviço de gerenciamento de identidade cria uma nova identidade de comunicação. Nesse cenário, o mesmo usuário acaba com uma identidade de Comunicação diferente para cada sessão.
- O serviço de gerenciamento de identidade emite um token de acesso do usuário para a identidade aplicável e o retorna ao aplicativo cliente.
O Serviço de Aplicativo do Azure ou o Azure Functions são duas alternativas para operar o serviço de gerenciamento de identidades. Esses serviços são dimensionados facilmente e têm recursos internos para autenticar usuários. Eles são integrados ao OpenID e a provedores de identidade de terceiros, como o Facebook.
Próximas etapas
- Para saber como emitir tokens, consulte Criar e gerenciar tokens de acesso.
- Para obter uma introdução à autenticação, confira Autenticar para os Serviços de Comunicação do Azure.
- Para se informar sobre a privacidade e a residência de dados, confira Disponibilidade de região e residência de dados.
- Para saber como criar identidades e tokens rapidamente para teste, confira o guia de início rápido para criação rápida de identidade.
- Para obter uma amostra completa de um serviço de gerenciamento de identidade simples, visite o Tutorial de serviço confiável.
- Para obter um exemplo de gerenciamento de identidade mais avançado que se integra à ID do Entra e ao Microsoft Graph, acesse o Exemplo de destaque do serviço de Autenticação.