View a markdown version of this page

身份验证 - 部署 Amazon WorkSpaces 应用程序的最佳实践
确定最佳的方法配置身份提供商

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

身份验证

对于 WorkSpaces 应用程序，身份验证可以在亚马逊 WorkSpaces 应用程序之外进行，也可以作为 WorkSpaces 应用程序服务的一部分进行。选择 WorkSpaces 应用程序部署的身份验证方式是设计的基本考虑因素。对于一个组织来说，针对不同的用例部署多个 WorkSpaces 应用程序的情况并不少见。每个使用案例可以有不同的身份验证方法。

WorkSpaces 应用程序有三种类型的身份验证方法：

确定最佳的方法

Amazon A WorkSpaces pplications 的架构非常灵活，可以满足大多数组织设计要求。在确定最佳的身份验证方法时，最佳实践是考虑服务使用者以及组织策略和程序使用者的目标和用途。

以下是一些将使用案例与组织目标相结合的示例。

表 4 — 不同组织目标的使用案例

示例 描述 身份验证
需要加入域的实例集实例 只有加入域的资源才能访问安装在 WorkSpaces 应用程序映像上的应用程序。 SAML 2.0
与 Microsoft 服务高度集成 组织依赖于正在开发的 Microsoft 组策略和后端基础架构 SAML 2.0
现有企业单一 Sign-on (SSO) 所有新服务都必须利用已确立多个报告和安全流程的企业 SSO 解决方案。 SAML 2.0
对应用程序的智能卡支持 智能卡（例如私人身份验证和通用访问卡），用于通过智能卡读卡器对流式应用程序进行会话中身份验证。 SAML 2.0
使用临时人员的临时员工队伍 在一年中的几个月中，会为临时工作人员分配一小部分应用程序，其中不包括用于完成活动的内部资源。 用户池
IT 支持有限 用户少于 50 以及 IT 员工有限的小型组织，他们希望消除维护身份提供商 (IdP) 的开销 用户池
独立软件供应商 (ISV) 由您的组织构建的专有解决方案，包括用户授权和身份验证，将 WorkSpaces 应用程序扩展为解决方案的一部分。 * 编程方式
技术展示 完全短暂的环境，在您的解决方案导览展示中展示专有技术，无需存储用户信息。 编程方式
交互式网站体验

让您的网站与 Windows 流式应用程序进行交互。**

编程方式

*有关更多信息，请参阅软件供应商：将应用程序交付给任何用户设备。

**有关更多信息，请参阅嵌入 WorkSpaces 应用程序流式传输会话。

如果您的组织有未在前面给出的示例中列出的用例或策略，则最佳做法是预测 WorkSpaces 应用程序工作流消耗的预期最终状态，以确保身份验证解决方案不会与之冲突。

配置身份提供商

SAML 2.0

安全断言标记语言 (SAML) 2.0 是允许用户使用资源的常用部署选项。 AWS 各种第三方 SAML 2.0 身份提供商都支持 WorkSpaces 应用程序。无论您的 WorkSpaces 应用程序资源是否加入了域名，SAML 2.0 IdP 都要求您使用 IAM。

由于大多数应用程序会为每个 SAML 应用程序 IdPs 生成具有特定 SAML 属性的唯一 metadata.xml，因此每个 WorkSpaces 应用程序堆栈都需要一个与 SAML IdP 具有可信关系的角色和一个对 AppStream: Stream 具有单一权限的策略，其条件符合 SAML IdP 和应用程序堆栈的 ARN 的要求。 WorkSpaces

《 WorkSpaces 应用程序管理指南》提供了单个 WorkSpaces 应用程序堆栈设计的示例配置。有关多堆栈部署，请参阅使用 SAML 2.0 多堆栈应用程序目录的可选步骤。

用户池

“ WorkSpaces 应用程序” 中的 “用户池” 选项卡是进行小型概念验证的有效选项。最佳做法是，对于任何使用应用程序交付生产 WorkSpaces 应用程序的用例和组织，最好避免使用用户池。

关于用户池，需要注意的一点是，用户的电子邮件地址区分大小写；因此，最佳实践是确保用户了解如何正确输入用户凭证。

流式传输 URL

对于从集中式服务（通常是 ISV）调用 WorkSpaces 应用程序资源的部署，编程身份验证依赖于应用程序进行编程调用， AWS 以动态传递信息并为其用户创建 WorkSpaces 应用程序会话。使用 URL 操作创建直播网址时，请使用 API 身份验证方法（通常称为 “编程式CreateStreaming”）。进行 CreateStreamingURL 调用的用户必须使用具有 appstream:CreateStreamingURL 权限的有效用户或角色。

在创建编程访问策略时，最佳做法是通过在 “资源” 部分指定确切的 WorkSpaces 应用程序堆栈 ARN 来代替默认的 “*” 来保护访问安全。例如：

例
JSON
{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "appstream:createStreamingURL"
            ],
            "Resource": "arn:aws:appstream:us-east-1:031421429609:stack/BestPracticesStack"
        }
    ]
}
注意

您可以使用描述堆栈 API 或 AWS CLI 快速检索 WorkSpaces 应用程序堆栈的 ARN。

WorkSpaces 应用程序实例应以通用实例的形式启动。通过从应用程序传递给它的信息，Applic WorkSpaces ations 实例使用会话上下文来建立环境，为用户提供动态信息。

虽然本地 GPO 可用于在用户登录时指定设置，但在 WorkSpaces 应用程序会话中使用CreateStreamingURL和传递关键属性（例如客户 ID 或数据库连接设置）时，会话上下文是最佳做法。

应用程序授权

WorkSpaces 应用程序可以动态构建呈现给用户的应用程序目录。应用程序授权基于 SAML 2.0 属性，或者使用 WorkSpaces 应用程序动态应用程序框架。

Attribute-based 在大多数情况下，建议使用 SAML 2.0 进行应用程序授权。要管理应用程序包的交付，建议使用动态应用程序框架。