坦率地说，这不仅仅是一个简单的介绍，而是对使用 ClearPass Guest 通过社交登录提供商进行身份验证时，底层发生的详细过程的深入解析。在这个特定的案例中，我将介绍使用 OAUTH 2.0 的 Microsoft Azure AD 时底层发生的情况。同样的逻辑适用于其他云提供商。在未来的文章中，我将介绍如何配置这个工作流程。现在，让我们专注于其详细的工作原理。
这篇文章背后的催化剂
客户希望其员工使用 Azure Active Directory 账户访问访客网络，而不是使用自助注册流程。我们都确信可以使用 OAUTH 或 SAML 实现，但我们不想在客户现场尝试，尤其是最近访问现场受到限制。因此，我们决定共同离线测试使用 SAML 和 OAUTH 的设置。在测试过程中，我们认为其他工程师可能会觉得这很有用，特别是因为相关文档不够完善，所以我们决定撰写这一系列文章，解释其背后的原理！
认证工作流程！
下图显示了认证工作流程以及各个组件之间的交互。下图中的“Azure AD”被用作“简化”来涵盖多个 Azure 服务，包括 Login、graph.windows.net 等。
逐步查看！
步骤 1/2：用户将连接到访客网络，并被重定向到 ClearPass 访客门户页面。用户将被置于访客登录角色，该角色将允许 DHCP、DNS、https 访问 ClearPass、https 访问社交提供商登录 FQDN，以及到 ClearPass 的强制门户重定向。
步骤 3：用户将按下登录按钮，这将启动 OAUTH 工作流程。
步骤 4/5：浏览器将被重定向到云服务提供商的登录页面（在此情况下为 Microsoft）
步骤 6：用户将填写账户详细信息和密码，然后登录。在请求中，将指定 client_id 和重定向 URL（回调）。浏览器将期望一个代码作为响应类型。
步骤 7：Azure 将返回一个访问代码，并重定向回步骤 6 中提交的 ClearPass 访客页面。
步骤 8：浏览器将被重定向回 ClearPass Guest 页面。它将回传从 Azure 获取的代码。
步骤 9/10：ClearPass 将使用该代码及其客户端 ID 和密钥来访问 Azure 图形 API。根据我对 OAUTH 代码工作流程的理解，ClearPass 应该将代码交换为访问令牌，但我在 ClearPass 上找不到此步骤的任何日志。可用的日志显示 ClearPass 调用 Azure API 以收集有关用户及其组成员的信息。
步骤 11：ClearPass 创建一个终端条目，并用从社交登录提供商获取的字段填充它。值得注意的字段是 social_password，它被发送回控制器以完成 radius 认证。
步骤 12：ClearPass 将指示控制器回传到控制器，以便控制器可以对 ClearPass 进行 RADIUS 认证。此处发送社交密码。
步骤 13/14：浏览器将回传至控制器，控制器将发送包含社交密码的 radius 请求至 ClearPass。
步骤 15/16：ClearPass 根据社交登录库验证提供的详细信息，并返回 Radius 接受。控制器更改用户的角色，用户现在具有访客访问权限。
这详细完成了此工作流程的步骤。请随时在下方分享您的意见和反馈。下一篇文章将深入解释配置。