Добавление проверки подлинности в расширение для сообщений

Важно!

Примеры кода в этом разделе основаны на 4.6 и более поздних версиях SDK Bot Framework. Если вы ищете документацию для более ранних версий, см. раздел Расширения обмена сообщениями — раздел v3 SDK в папке Ресурсы документации.

Определение пользователя

Каждый запрос в службы включает пользовательский ИД, имя отображения пользователя и Azure Active Directory объекта.

"from": {
  "id": "29:1C7dbRrC_5yzN1RGtZIrcWT0xz88KPGP9sxdpVpV8sODlgPHeQE9RqQ02hnpuKzy6zZ-AaZx6swUOMj_Dsdse3TQ4sIaeebbFBF-VgjJy_nY",
  "name": "Larry Jin",
  "aadObjectId": "cd723fa0-0591-416a-9290-e93ecf3a9b92"
},

Данные и значения гарантируются для пользователя, id aadObjectId Teams проверки подлинности. Они используются в качестве ключей для слежки за учетными данными или любым кэшным состоянием в службе. Кроме того, каждый запрос содержит Azure Active Directory клиента, который используется для идентификации организации пользователя. Если это применимо, запрос также содержит командный ИД и ИД канала, из которого был зародился запрос.

Проверка подлинности

Если ваша служба требует проверки подлинности пользователей, пользователи должны войти, прежде чем использовать расширение обмена сообщениями. Этапы проверки подлинности аналогичны шагам бота или вкладки. Последовательность будет следующим образом:

  1. Пользователь выдает запрос или запрос по умолчанию автоматически отправляется в службу.
  2. Служба проверяет, проверяется ли проверка подлинности пользователя, проверяя Teams пользователя.
  3. Если у пользователя нет проверки подлинности, отправьте ответ с предложенным действием, включая auth openUrl URL-адрес проверки подлинности.
  4. Клиент Microsoft Teams запускает диалоговое окно с размещением веб-страницы с помощью данного URL-адреса проверки подлинности.
  5. После того как пользователь войдет, необходимо закрыть окно и отправить код проверки подлинности Teams клиенту.
  6. Затем Teams переиздает запрос в службу, которая включает код проверки подлинности, переданный в шаге 5.

Служба должна убедиться, что код проверки подлинности, полученный на шаге 6, соответствует коду из шага 5. Это гарантирует, что вредоносный пользователь не пытается подменить или скомпрометировать вход в потоке. Это эффективно "закрывает цикл", чтобы завершить безопасную последовательность проверки подлинности.

Ответ с помощью знака в действии

Чтобы подсказывать неавентированному пользователю войти, ответьте предложенным действием типа, которое включает URL-адрес проверки openUrl подлинности.

Пример ответа для знака в действии

{
  "composeExtension":{
    "type":"auth",
    "suggestedActions":{
      "actions":[
        {
          "type": "openUrl",
          "value": "https://example.com/auth",
          "title": "Sign in to this app"
        }
      ]
    }
  }
}

Примечание

Чтобы вход в окне Teams, доменная часть URL-адреса должна быть в списке допустимого домена вашего приложения. Дополнительные сведения см. в схеме манифеста validDomains.

Запуск знака в потоке

Ваш вход должен быть отзывчивым и соответствовать всплывающее окно. Он должен интегрироваться с клиентом Microsoft Teams JavaScript SDK,который использует передачу сообщений.

Как и в других встроенных Microsoft Teams, коду в окне необходимо сначала microsoftTeams.initialize() позвонить. Если код выполняет поток OAuth, вы можете передать Teams пользователя в окно, которое затем передает его в URL-адрес для регистрации OAuth.

Завершить вход в поток

Когда вход в запросе завершается и перенаправляется обратно на страницу, он должен выполнить следующие действия:

  1. Создание кода безопасности, случайное число. Необходимо кэшировать этот код в службе вместе с учетными данными, полученными в потоке входа, например маркерами OAuth 2.0.
  2. Вызов microsoftTeams.authentication.notifySuccess и пропуск кода безопасности.

На этом этапе окно закрывается и управление передается Teams клиенту. Теперь клиент переизбирает исходный запрос пользователя вместе с кодом безопасности в state свойстве. Код безопасности может использовать код безопасности для проверки учетных данных, хранимых ранее, для завершения последовательности проверки подлинности и выполнения запроса пользователя.

Пример повторного запроса

{
    "name": "composeExtension/query",
    "value": {
        "commandId": "insertWiki",
        "parameters": [{
            "name": "searchKeyword",
            "value": "lakers"
        }],
        "state": "12345",
        "queryOptions": {
            "skip": 0,
            "count": 25
        }
    },
    "type": "invoke",
    "timestamp": "2017-04-26T05:18:25.629Z",
    "localTimestamp": "2017-04-25T22:18:25.629-07:00",
    "entities": [{
        "locale": "en-US",
        "country": "US",
        "platform": "Web",
        "type": "clientInfo"
    }],
    "text": "",
    "attachments": [],
    "address": {
        "id": "f:7638210432489287768",
        "channelId": "msteams",
        "user": {
            "id": "29:1A5TJWHkbOwSyu_L9Ktk9QFI1d_kBOEPeNEeO1INscpKHzHTvWfiau5AX_6y3SuiOby-r73dzHJ17HipUWqGPgw",
            "aadObjectId": "fc8ca1c0-d043-4af6-b09f-141536207403"
        },
        "conversation": {
            "id": "19:7705841b240044b297123ad7f9c99217@thread.skype"
        },
        "bot": {
            "id": "28:c073afa8-7e77-4f92-b3e7-aa589e952a3e",
            "name": "maotestbot2"
        },
        "serviceUrl": "https://smba.trafficmanager.net/amer-client-ss.msg/",
        "useAuth": true
    },
    "source": "msteams"
}

Пример кода

Название примера Описание .NET Node.js
Расширения обмена сообщениями — auth и config Расширение обмена сообщениями, которое имеет страницу конфигурации, принимает запросы на поиск и возвращает результаты после того, как пользователь войт. View Просмотр

Дополнительные ресурсы

Поддержка единой системы регистрации (SSO) для расширений обмена сообщениями