Sobre o logon único

APLICA-SE A: SDK v4

O logon único (SSO) permite que o acesso aos recursos seja compartilhado entre aplicativos independentes. Por exemplo, um usuário pode entrar em um serviço em um bot raiz, e o bot raiz pode compartilhar o token de acesso com um bot de habilidade. Atualmente, apenas o provedor de identidade Microsoft Entra ID é suportado.

O SSO aplica-se aos seguintes cenários:

• Um bot raiz e um ou mais bots de habilidade. O usuário entra a partir do bot raiz. Em seguida, o bot invoca várias habilidades em nome do usuário.
• Um controle de Web Chat incorporado em um site. O utilizador inicia sessão a partir do website. Em seguida, o site invoca um bot ou uma habilidade em nome do usuário.

O SSO oferece as seguintes vantagens:

• O utilizador não tem de iniciar sessão várias vezes.
• O bot raiz ou site não precisa saber as permissões do usuário.

Interação de componentes SSO

Os diagramas de sequência de tempo a seguir mostram as interações entre os vários componentes do SSO.

• O diagrama a seguir ilustra o fluxo para um bot raiz.

  

• O diagrama a seguir ilustra o fluxo e o fluxo de fallback para um controle de Web Chat.

  

  Se a troca de token falhar, o fall-back é solicitar que o usuário entre. Tais falhas podem acontecer quando permissões extras são necessárias ou o token é para o serviço errado.

Vamos analisar o fluxo.

1. O cliente inicia uma conversa com o bot acionando um cenário OAuth.

2. O bot envia de volta um cartão OAuth para o cliente.

3. O cliente interceta o cartão OAuth antes de exibi-lo ao usuário e verifica se ele contém uma TokenExchangeResource propriedade.

4. Se a propriedade existir, o cliente enviará um TokenExchangeInvokeRequest para o bot. O cliente deve ter um token trocável para o usuário, que deve ser um token de ID do Microsoft Entra e cujo público deve ser o mesmo que TokenExchangeResource.Uri a propriedade. O cliente envia uma atividade Invoke para o bot com o corpo mostrado abaixo.

   {
       "type": "Invoke",
       "name": "signin/tokenExchange",
       "value": {
           "id": "<any unique ID>",
           "connectionName": "<connection Name on the skill bot (from the OAuth Card)>",
           "token": "<exchangeable token>"
       }
   }
   

5. O bot processa o TokenExchangeInvokeRequest e retorna um TokenExchangeInvokeResponse retorno para o cliente. O cliente deve esperar até receber o TokenExchangeInvokeResponsearquivo .

   {
       "status": "<response code>",
       "body": {
           "id":"<unique ID>",
           "connectionName": "<connection Name on the skill bot (from the OAuth Card)>",
           "failureDetail": "<failure reason if status code isn't 200, null otherwise>"
       }
   }
   

6. Se o TokenExchangeInvokeResponse tiver um status de 200, então o cliente não mostra a placa OAuth. Veja o fluxograma normal. Para qualquer outro status ou se o TokenExchangeInvokeResponse não for recebido, o cliente mostra o cartão OAuth para o usuário. Consulte o diagrama de fluxo de fallback. Isso garante que o fluxo SSO volte ao fluxo OAuthCard normal, se houver erros ou dependências não atendidas, como o consentimento do usuário.

Próximos passos