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 identidades existentes do seu sistema de gerenciamento de identidades e simplesmente mapeie-as com identidades dos Serviços de Comunicação do Azure.
- Fornece flexibilidade de integração, pois o modelo agnóstico de identidade funciona bem com seu sistema de identidade existente.
- Você pode Manter os dados do usuário, como o nome dele, privados, pois 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 do usuário / mapeamento
Identifica exclusivamente um usuário por meio de um identificador de usuário, que é gerado pelos Serviços de Comunicação do Azure quando um usuário é criado. Identificadores externos, como números de telefone, usuários, dispositivos, aplicativos e GUIDs, não podem ser usados para identidade nos Serviços de Comunicação do Azure. Você pode criar identidades de usuário do Serviço de Comunicação do Azure gratuitamente. As cobranças só são cobradas quando o usuário consome modalidades de comunicação, como um bate-papo ou uma chamada. A identidade dos usuários pode ser mapeada para a Identidade do usuário dos Serviços de Comunicação do Azure nas configurações 1:1, 1:N, N:1 e N:N. Um usuário pode participar de várias sessões de comunicação, usando vários dispositivos, simultaneamente. O mapeamento entre a identidade do usuário dos Serviços de Comunicação do Azure e a identidade de usuário privada do cliente é mantido e mantido pelo cliente. Por exemplo, os clientes podem adicionar uma CommunicationServicesId coluna em sua tabela de usuário para armazenar a identidade associada dos Serviços de Comunicação do Azure.
Tokens de acesso
Depois que uma identidade de usuário é criada, um usuário recebe a capacidade de participar de comunicações usando chat ou chamadas, usando tokens de acesso. Por exemplo, apenas um usuário com token de chat pode participar de bate-papo e usuário com token 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 tipos de tokens para conta para usuários que precisam de acesso total versus acesso limitado. Os tokens de acesso têm as seguintes propriedades.
| Property | Description |
|---|---|
| Identidade | Identifica exclusivamente um token |
| Expiração | Um token de acesso é válido por um período de tempo entre 1 e 24 horas. Depois de expirar, o token de acesso é invalidado e não pode ser usado para acessar nenhuma primitiva. Para gerar um token com uma validade personalizada, especifique o período de validade desejado ao gerar o token. Se nenhuma validade personalizada for especificada, o token será válido por 24 horas. Recomendamos o uso de tokens de vida curta para reuniões pontuais e tokens de vida mais longa para agentes que usam o aplicativo por períodos de tempo mais longos |
| Âmbito | O parâmetro scope define um conjunto não vazio de primitivos (Chat/VoIP) que podem ser usados. |
Um token de acesso é um JSON Web Token (JWT) e tem proteção de integridade. Ou seja, suas reivindicações não podem ser alteradas depois de emitidas. Portanto, uma alteração manual de propriedades como identidade, expiração ou escopos invalidará o token de acesso. Se primitivos forem usados com tokens invalidados, o acesso será negado aos primitivos. Os Serviços de Comunicação do Azure dão suporte aos seguintes escopos para tokens de acesso.
Escopos de token de chat
Três tipos de escopos de token de chat são suportados. As permissões para cada token são descritas abaixo.
- chat
- bate-papo.junte-se
- chat.join.limited
| Capacidade / Escopo do token | chat | bate-papo.junte-se | chat.join.limited |
|---|---|---|---|
| Criar thread de bate-papo | Y | N | N |
| Atualizar thread de bate-papo com ID | Y | N | N |
| Excluir thread de bate-papo com ID | Y | N | N |
| Adicionar participante a um tópico de chat | Y | Y | N |
| Remover participante de um tópico de chat | Y | Y | N |
| Obter tópicos de bate-papo | Y | Y | Y |
| Obter thread de bate-papo com ID | Y | Y | Y |
| Obter ReadReceipt | Y | Y | Y |
| Criar ReadReceipt | Y | Y | Y |
| Criar mensagem para thread de chat com ID | Y | Y | Y |
| Obter mensagem com ID de mensagem | Y | Y | Y |
| Atualize a sua própria mensagem com o ID da mensagem | Y | Y | Y |
| Excluir sua própria mensagem com ID de mensagem | Y | Y | Y |
| Enviar indicador de digitação | Y | Y | Y |
| Obter participante para ID de thread | Y | Y | Y |
Escopos de token VoIP
Dois tipos de escopos de token VoIP são suportados. As permissões para cada token são descritas abaixo.
- VoIP
- voip.junte-se
| Capacidade / Escopo do token | VoIP | voip.junte-se |
|---|---|---|
| Iniciar uma chamada VoIP | Y | N |
| Iniciar uma chamada VoIP em Salas Virtuais, quando o usuário já estiver convidado para a Sala | Y | Y |
| Participar de uma chamada VoIP da InProgress | Y | Y |
| Participar de uma chamada VoIP da InProgress em Salas Virtuais, quando o usuário já estiver convidado para a Sala | Y | Y |
| Todas as outras operações em chamada, como silenciar/desativar o som, compartilhamento de tela, etc. | Y | Y |
| Todas as outras operações em chamada, como silenciar/desativar o som, compartilhamento de tela, etc., em Salas Virtuais | Determinado pela função do usuário | Determinado pela função do usuário |
Revogar ou atualizar 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 de seu tempo de expiração. A revogação do token não é imediata. Pode levar até 15 minutos para se propagar.
- A remoção de uma identidade, recurso ou assinatura revoga todos os tokens de acesso.
- Se você quiser remover a capacidade de um usuário acessar funcionalidades específicas, revogue todos os tokens de acesso. Em seguida, emita um novo 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 chave de acesso anterior. Nesse caso, todas as identidades perdem o acesso aos Serviços de Comunicação do Azure e devem emitir novos tokens de acesso.
Considerações
- Recomendamos a emissão de tokens de acesso em seu serviço do lado do servidor e não no aplicativo do cliente. O raciocínio é que a emissão requer uma chave de acesso ou autenticação do Microsoft Entra. O compartilhamento de segredos com o aplicativo do cliente não é recomendado por motivos de segurança.
- O aplicativo cliente deve usar um ponto de extremidade de serviço confiável que possa autenticar clientes. O ponto de extremidade deve emitir tokens de acesso em seu nome. Para obter mais informações, consulte Arquitetura de cliente e servidor.
- Se você armazenar tokens de acesso em cache em um repositório de backup, recomendamos o uso de criptografia. Um token de acesso são dados confidenciais. Ele pode ser usado para atividades maliciosas se não estiver protegido. Alguém que tenha um token de acesso pode iniciar o SDK e acessar a API. A API acessível é restrita apenas com base nos escopos que o token de acesso tem.
- Recomendamos a emissão de tokens de acesso que tenham apenas os escopos necessários.
Próximos passos
- Para obter uma introdução ao gerenciamento de tokens de acesso, consulte Criar e gerenciar tokens de acesso.
- Para obter uma introdução à autenticação, consulte Autenticar nos Serviços de Comunicação do Azure.
- Para obter uma introdução à residência e privacidade de dados, consulte Disponibilidade de região e residência de dados.
- Para saber como criar identidades rapidamente para teste, consulte o Guia de início rápido de criação rápida de identidade.