步骤 3:规划如何使用 AD FS 预身份验证发布应用程序

发布时间: 2013年8月

更新时间: 2013年8月

应用到: Windows Server 2012 R2



本主题介绍使用 Active Directory 联合身份验证服务 (AD FS) 预身份验证时所要执行的常规预身份验证流(包括针对不同客户端和应用程序的预身份验证流),以及使用 AD FS 预身份验证通过 Web 应用程序代理发布应用程序时可以执行的规划任务。

对于可以使用 AD FS 预身份验证发布的所有类型的应用程序,必须向联合身份验证服务添加 AD FS 信赖方信任。

常规 AD FS 预身份验证流如下:

note备注
此预身份验证流不适用于使用 Windows 应用商店应用的客户端。

  1. 客户端设备尝试访问特定资源 URL(例如 https://app1.contoso.com/)上的已发布 Web 应用程序。

    该资源 URL 是 Web 应用程序代理在其上侦听传入 HTTPS 请求的公用地址。

  2. Web 应用程序代理使用 URL 编码的参数(包括资源 URL 和 appRealm(一个信赖方标识符))将 HTTPS 请求重定向到 AD FS 服务器。

    使用 AD FS 服务器要求的身份验证方法(例如,用户名和密码、结合一次性密码的双重身份验证,等等)对用户进行身份验证。

  3. 对用户进行身份验证后,AD FS 服务器颁发包含以下信息的安全令牌(即“边缘令牌”),并将 HTTPS 请求重定向回到 Web 应用程序代理服务器:

    • 用户尝试访问的资源标识符。

    • 用户主体名称 (UPN) 形式的用户标识。

    • 访问授权审批过期时间;也就是说,将向用户授予有限时间的访问权限,在此期限过后,需要重新对用户进行身份验证。

    • 边缘令牌中的信息签名。

  4. Web 应用程序代理从具有边缘令牌的 AD FS 服务器接收重定向的 HTTPS 请求,并按如下所述验证和使用该令牌:

    • 验证边缘令牌签名是否来自 Web 应用程序代理配置中配置的联合身份验证服务。

    • 验证令牌是否是针对正确的应用程序颁发的。

    • 验证令牌是否未过期。

    • 根据需要使用用户标识;例如,如果后端服务器配置为使用集成 Windows 身份验证,则获取 Kerberos 票证。

  5. 如果边缘令牌有效,则 Web 应用程序代理将使用 HTTP 或 HTTPS 将 HTTPS 请求转发到发布的 Web 应用程序。

  6. 现在,客户端可以访问发布的 Web 应用程序;但是,可将发布的应用程序配置为要求用户执行其他身份验证。例如,如果发布的 Web 应用程序是 SharePoint 站点且不需要执行其他身份验证,则用户将在浏览器中看到该 SharePoint 站点。

  7. Web 应用程序代理在客户端设备上保存 Cookie。Web 应用程序代理使用该 Cookie 来确认此会话已经过预身份验证,且不需要进一步进行预身份验证。

note备注
Web 应用程序代理不支持通配符域发布。也就是说,你不能使用通配符配置外部 URL,例如 https://*.contoso.com。

 

任务 描述

3.1.规划基于声明的应用程序

在发布使用基于声明的身份验证的应用程序之前,应该先规划好需要满足的所有先决条件。

3.2.规划基于集成 Windows 身份验证的应用程序

在发布使用集成 Windows 身份验证的应用程序之前,应该先规划好需要满足的所有先决条件。

3.3.为 MSOFBA 客户端规划应用程序

为使用基于 Microsoft Office 窗体的身份验证 (MSOFBA) 的客户端发布应用程序之前,应该先规划好需要满足的所有先决条件。

3.4.为使用 Windows 应用商店应用的客户端规划应用程序

为使用 Windows 应用商店应用的客户端发布应用程序之前,应该先规划好需要满足的所有先决条件。

若要发布使用声明进行身份验证的应用程序,必须向联合身份验证服务添加该应用程序的信赖方信任。

在发布基于声明的应用程序以及从浏览器访问应用程序时,要执行的常规身份验证流如下:

  1. 客户端尝试使用 Web 浏览器访问基于声明的应用程序,例如 https://appserver.contoso.com/claimapp/。

  2. Web 浏览器将一个 HTTPS 请求发送到 Web 应用程序代理服务器,后者将该请求重定向到 AD FS 服务器。

  3. AD FS 服务器对用户和设备进行身份验证,然后将请求重定向回到 Web 应用程序代理。现在,该请求包含边缘令牌。AD FS 服务器将单一登录 (SSO) Cookie 添加到该请求,因为用户已针对 AD FS 服务器执行身份验证。

  4. Web 应用程序代理验证令牌,添加自身的 Cookie,然后将请求转发到后端服务器。

  5. 后端服务器将请求重定向到 AD FS 服务器,以获取应用程序安全令牌。

  6. ADFS 服务器将请求重定向到后端服务器。现在,该请求包含应用程序令牌和 SSO Cookie。已授予用户对应用程序的访问权限,并且用户无需输入用户名或密码。

可以通过 Web 应用程序代理发布使用集成 Windows 身份验证的应用程序;也就是说,Web 应用程序代理将根据需要执行预身份验证,然后可对使用集成 Windows 身份验证的已发布应用程序执行 SSO。若要发布使用集成 Windows 身份验证的应用程序,必须向联合身份验证服务添加该应用程序的非声明感知信赖方信任。

若要允许 Web 应用程序代理执行单一登录 (SSO) 及使用 Kerberos 约束委派执行凭据委派,必须将 Web 应用程序代理服务器加入域。请参阅 1.4. 规划 Active Directory

若要允许用户访问使用集成 Windows 身份验证的应用程序,Web 应用程序代理服务器必须能够向发布的应用程序提供用户委派。可以在域控制器上针对任何应用程序执行此操作。如果后端服务器在 Windows Server 2012 R2 或 Windows Server 2012 上运行,则也可以在后端服务器上执行此操作。有关详细信息,请参阅 Kerberos 身份验证的新增功能

有关如何配置 Web 应用程序代理以发布使用集成 Windows 身份验证的应用程序的操作实例,请参阅步骤 3:配置并测试使用集成 Windows 身份验证访问网站

为后端服务器使用集成 Windows 身份验证时,Web 应用程序代理与发布的应用程序之间不是基于声明进行身份验证,而是使用 Kerberos 约束委派在应用程序上对最终用户进行身份验证。下面描述了常规流:

  1. 客户端尝试使用 Web 浏览器访问非基于声明的应用程序,例如 https://appserver.contoso.com/nonclaimapp/。

  2. Web 浏览器将一个 HTTPS 请求发送到 Web 应用程序代理服务器,后者将该请求重定向到 AD FS 服务器。

  3. AD FS 服务器对用户进行身份验证,然后将请求重定向回到 Web 应用程序代理。现在,该请求包含边缘令牌。

  4. Web 应用程序代理验证该令牌。

  5. 如果令牌有效,Web 应用程序代理将代表用户从域控制器获取 Kerberos 票证。

  6. Web 应用程序代理将该 Kerberos 票证作为简单的受保护 GSS-API 协商机制 (SPNEGO) 的一部分添加到请求,然后将请求转发到后端服务器。该请求包含 Kerberos 票证;因此,已向用户授予对应用程序的访问权限,且无需用户进一步进行身份验证。

Web 应用程序代理支持从 Microsoft Word 等 Microsoft Office 客户端访问后端服务器上的文档和数据。这些应用程序与标准的浏览器之间的唯一差别在于,重定向到 STS 不是通过普通的 HTTP 重定向完成的,而是使用以下网页中指定的特殊 MSOFBA 标头实现的:http://msdn.microsoft.com/en-us/library/dd773463(v=office.12).aspx。后端应用程序可以是声明或 IWA。
若要为使用 MSOFBA 的客户端发布应用程序,必须向联合身份验证服务添加该应用程序的信赖方信任。根据具体的应用程序,你可以使用基于声明的身份验证或集成 Windows 身份验证。因此,必须根据应用程序添加相关的信赖方信任。

若要允许 Web 应用程序代理执行单一登录 (SSO) 及使用 Kerberos 约束委派执行凭据委派,必须将 Web 应用程序代理服务器加入域。请参阅 1.4. 规划 Active Directory

如果应用程序使用基于声明的身份验证,则无需执行其他规划步骤。如果应用程序使用了集成 Windows 身份验证,请参阅 3.2.规划基于集成 Windows 身份验证的应用程序

下面描述了使用 MSOFBA 协议进行基于声明的身份验证的客户端的身份验证流。对于此方案,身份验证可以使用 URL 中或正文中的应用程序令牌。

  1. 用户正在操作一个 Office 程序,并从“最近使用的文档”列表中打开了 SharePoint 站点上的某个文件。

  2. 该 Office 程序显示了一个窗口,其中包含的浏览器控件要求用户输入凭据。

    note备注
    在某些情况下,由于客户端已经过身份验证,因此可能不显示该窗口。

  3. Web 应用程序代理将请求重定向到 AD FS 服务器,后者将执行身份验证。

  4. AD FS 服务器将请求重定向回到 Web 应用程序代理。现在,该请求包含边缘令牌。

  5. AD FS 服务器将单一登录 (SSO) Cookie 添加到该请求,因为用户已针对 AD FS 服务器执行身份验证。

  6. Web 应用程序代理验证令牌,然后将请求转发到后端服务器。

  7. 后端服务器将请求重定向到 AD FS 服务器,以获取应用程序安全令牌。

  8. 请求已重定向到后端服务器。现在,该请求包含应用程序令牌和 SSO Cookie。已授予用户对 SharePoint 站点的访问权限,并且用户无需输入用户名或密码就能查看文件。

若要为 Windows 应用商店应用发布应用程序,必须向联合身份验证服务添加该应用程序的信赖方信任。

若要允许 Web 应用程序代理执行单一登录 (SSO) 及使用 Kerberos 约束委派执行凭据委派,必须将 Web 应用程序代理服务器加入域。请参阅 1.4. 规划 Active Directory

note备注
Web 应用程序代理仅支持为使用 OAuth 2.0 协议的 Windows 应用商店应用发布应用程序。

在 AD FS 管理控制台中,必须确保为 OAuth 终结点启用了代理。若要检查是否为 OAuth 终结点启用了代理,请打开 AD FS 管理控制台,展开“服务”,单击“终结点”,在“终结点”列表中找到 OAuth 终结点,并确保“已启用代理”列中的值为“是”。

下面描述了使用 Windows 应用商店应用的客户端的身份验证流:

note备注
Web 应用程序代理重定向到 AD FS 服务器以请求身份验证。由于 Windows 应用商店应用不支持重定向,因此,如果你使用 Windows 应用商店应用,则需要使用 Set-WebApplicationProxyConfiguration cmdlet 和 OAuthAuthenticationURL 参数设置 AD FS 服务器的 URL。

只能使用 Windows PowerShell 发布 Windows 应用商店应用。

  1. 客户端尝试访问使用 Windows 应用商店应用的已发布 Web 应用程序。

  2. 该应用向 Web 应用程序代理发布的 URL 发送 HTTPS 请求。

  3. Web 应用程序代理向该应用返回 HTTP 401 响应,其中包含了 AD FS 身份验证服务器的 URL。此过程称为“发现”。

    note备注
    如果应用已知道 AD FS 身份验证服务器的 URL,并且已获取包含 OAuth 令牌和边缘令牌的组合令牌,则会跳过此身份验证流中的步骤 2 和 3。

  4. 该应用向 AD FS 服务器发送 HTTPS 请求。

  5. 该应用使用 Web 身份验证代理生成一个对话框,用户需要在其中输入凭据以通过 AD FS 服务器的身份验证。有关 Web 身份验证代理的信息,请参阅 Web 身份验证代理

  6. 身份验证成功后,AD FS 服务器将创建包含 OAuth 令牌和边缘令牌的组合令牌,然后将该令牌发送到应用。

  7. 该应用将包含组合令牌的 HTTPS 请求发送到 Web 应用程序代理发布的 URL。

  8. Web 应用程序代理将组合令牌拆分成两部分,并验证边缘令牌。

  9. 如果边缘令牌有效,则 Web 应用程序代理只使用 OAuth 令牌将请求转发到后端服务器。已授予用户对发布的 Web 应用程序的访问权限。

社区附加资源

显示: