身份验证类型
本文内容
适用于:SDK v4
Bot Framework 中有两大身份验证类别:机器人身份验证和用户身份验证。 每种类别都有一个用于访问受保护资源的关联令牌。 下图显示了机器人身份验证和用户身份验证涉及的元素。
在此图中:
- “主机平台”是机器人托管平台。 它可以是 Azure 或你选择的任何主机平台。
- “机器人连接器服务”可以简化机器人与通道之间的通信。 它将从通道接收的消息转换为活动对象,并将这些对象发送到机器人的消息传递终结点。 同样,它将从机器人接收的活动对象转换为通道可识别的消息,并将这些消息发送到通道。
- Bot Adapter 是默认的 Bot Framework 适配器。 其:
- 将 JSON 有效负载转换为活动对象。
- 创建轮次上下文并将活动对象添加到其中。
- 运行中间件(如果有)。
- 将轮次上下文转发到机器人。
备注
使用自定义通道适配器时,适配器本身会执行机器人连接器服务和默认机器人适配器所执行的任务。 此外,它还为相关的 Webhook API 提供身份验证机制。
机器人由其 MicrosoftAppID 和 MicrosoftAppPassword 标识,这些属性保存在机器人的设置文件(appsettings.json
(.NET)、.env
(JavaScript)、config.py
(Python))或 机密或密钥管理器中。
有关详细信息,请参阅 MicrosoftAppID 和 MicrosoftAppPassword。
通过在 Azure 门户中注册机器人时,Azure 会创建 Microsoft Entra ID 注册应用程序。 如果使用 Bot Framework CLI,则必须专门执行一个步骤来创建 Microsoft Entra ID 注册。 此注册具有应用程序 ID (MicrosoftAppID
) 和客户端机密 (MicrosoftAppPassword
)。 Azure 使用这些值生成一个令牌,机器人可以使用该令牌来访问安全资源。
当通道通过机器人连接器服务向机器人发送请求时,将在该请求的授权头中指定一个令牌。 通过验证该令牌的真实性,机器人可以对来自机器人连接器服务的调用进行身份验证。
当机器人通过机器人连接器服务向通道发送请求时,将在该请求的授权头中指定令牌。 所有请求必须包含访问令牌,在为请求授权时,机器人连接器服务将验证该令牌。
所述操作由 Bot Framework SDK 自动执行。
有关详细信息,请参阅有关如何对从机器人连接器服务向机器人发出的请求进行身份验证和对从机器人向机器人连接器服务发出的请求进行身份验证的 REST API 文档。
通常,通道通过“Bot Connector 服务”与机器人通信,因此以前的身份验证原则通常适用。 某些通道和功能需要考虑独特的身份验证问题。
除了支持的标准通道外,客户端应用程序还可以使用 Direct Line 通道来与机器人通信。
客户端应用程序使用从 Azure 门户中的“Direct Line 通道配置”页获取的机密,或者最好是使用在运行时获取的令牌,对向 Direct Line(版本 3.0)发出的请求进行身份验证。 该机密或令牌在每个请求的授权头中指定。
重要
将 Azure AI 机器人服务身份验证与 Web 聊天配合使用时,必须牢记一些重要的安全注意事项。 有关详细信息,请参阅 REST 身份验证文章中的安全注意事项部分。
有关详细信息,请参阅将机密保持隐藏状态,用机密交换令牌,然后生成嵌入。
Web 聊天有两种实现:通道和控件。
- 将机器人注册到 Azure 时,会自动将 Web 聊天通道配置为允许测试机器人。 有关详细信息,请参阅将机器人连接到 Web 聊天。
- 可将 Web 聊天控件与 Direct Line 通道结合使用,以便在客户端应用程序中提供对机器人的访问。 有关该控件的详细信息,请参阅 Bot Framework Web 聊天。
技能和技能使用者是两个不同的机器人,其中每个机器人具有自身的应用 ID 和密码。
- 使用者可将用户活动转发到技能,并将技能的响应转发到用户。
- 对于技能而言,技能使用者充当通道。 使用者有一个技能主机终结点,该终结点充当技能将活动发送到的服务 URL。
- 有关技能的详细信息,请参阅技能概述。
服务级别身份验证由 Bot Connector 服务管理。 框架使用持有者令牌和机器人应用程序 ID 来验证每个机器人的标识。
重要
这要求所有机器人(技能使用者及其使用的任何技能)具有有效的应用程序凭据。
除了此基本级别的身份验证以外,还必须将声明验证程序添加到技能和技能使用者的身份验证配置中。 声明在身份验证标头之后进行评估。 此流程让每个机器人能限制可以接受来自其他哪些机器人的活动。
Bot Framework Emulator 有自身的身份验证流和自身的令牌。 Emulator 有自身的通道和内置服务器。
有时,机器人必须代表用户访问受保护的联机资源。 为此,机器人必须获得授权。 这是因为,若要执行某些操作(例如查看电子邮件、查看航班状态或者下单),机器人需要调用外部服务,例如 Microsoft Graph、GitHub 或某个公司的 REST 服务。 OAuth 用于对用户进行身份验证以及为机器人授权。
备注
要使机器人能够访问用户的资源,需要执行两个宏步骤。
- “身份验证”。 验证用户身份的过程。
- 授权。 验证机器人能否访问用户资源的过程。
如果第一个步骤成功,则颁发基于用户凭据的令牌。 在第二个步骤,机器人使用该令牌访问用户的资源。
有关详细信息,请参阅用户身份验证。
标识提供者对用户或客户端标识进行身份验证,然后颁发可使用的安全令牌。 它以服务的形式提供用户身份验证。 客户端应用程序(如 Web 应用程序)将身份验证委托给受信任的标识提供者。
机器人可以使用受信任的标识提供者来执行以下操作:
- 启用单一登录 (SSO) 功能,使应用程序能够访问多个受保护的资源。
- 代表用户连接到云计算资源,从而减少用户重新身份验证的需要。
备注
在“机器人身份验证”期间颁发的令牌与“用户身份验证期”间颁发的令牌不同。 第一种令牌用于在机器人、通道以及最终的客户端应用程序之间建立安全通信。 第二种令牌用于授权机器人代表用户访问受保护的资源。
请注意,通道提供自身不同的用户身份验证,使用户能够登录到通道。
有关机器人如何使用标识提供者代表用户访问资源的详细信息,请参阅标识提供者。