上几个月，Amazon IAM Identity Center 新推出了一项功能——可信身份和传播。这篇文章将向大家介绍一个基于可信身份传播的新使用案例。
常用商业智能（BI）应用程序 Tableau 现在可以将最终用户的身份向下传播到 Amazon Redshift。这一功能有三重好处：简化了最终用户的登录体验；使数据所有者能够根据真实的最终用户身份定义访问权限；使审计人员能够验证用户的数据访问权限。
可信身份传播
扫码了解更多
Amazon IAM Identity Center
扫码了解更多
Amazon Redshift
扫码了解更多
左右滑动查看更多
可信身份传播允许使用数据的应用程序（例如 Amazon QuickSight、Amazon Redshift 查询编辑器、Amazon EMR Studio 等）将用户的身份和群组成员资格传播到存储和管理数据访问权限的服务，例如 Amazon Redshift、Amazon Athena、Amazon Simple Storage Service（Amazon S3）、Amazon EMR 等。
可信身份传播是 IAM Identity Center 的一项功能，可改善多个分析应用程序的登录体验，并简化数据访问管理和审计。最终用户将受益于单点登录，无需指定要代入的 IAM 角色即可连接到系统。
Amazon QuickSight
扫码了解更多
Amazon Redshift 查询编辑器
扫码了解更多
Amazon EMR Studio
扫码了解更多
Amazon Athena
扫码了解更多
Amazon S3
扫码了解更多
Amazon EMR
扫码了解更多
左右滑动查看更多
在深入探讨更多细节之前，让我们先就术语达成一致。
我使用“身份提供者”一词来指代保有用户身份和群组成员资格的系统。这些系统会提示用户输入凭证并执行身份验证。扫描下方二维码查看我们支持的身份提供者的完整列表。
我们支持的身份提供者完整列表
扫码了解更多
我使用“面向用户的应用程序”一词来指代使用数据的应用程序，例如 Amazon QuickSight、Amazon Redshift 查询编辑器等。
Amazon Redshift 查询编辑器
扫码了解更多
最后，我在使用“下游服务”时，指的是处理、存储或管理数据访问权限的分析引擎和存储服务：Amazon Redshift、Amazon Athena、Amazon S3、Amazon EMR 等。
为了了解可信身份传播的好处，我们先来简要谈谈在此之前是如何授予数据访问权限的。当面向用户的应用程序访问来自下游服务的数据时，上游服务会使用通用凭证（例如“tableau_user”），或者代入 IAM 角色来对下游服务进行身份验证。由此产生了两个挑战。
首先，这使得下游服务管理员很难定义针对提出请求的实际用户进行微调的访问策略。从下游服务来看，所有请求都来自该普通用户或 IAM 角色。如果 Jeff 和 Jane 都映射到 BusinessAnalytics IAM 角色，则无法为他们提供不同的访问权限级别，例如只读和读写。此外，如果 Jeff 还是财务群组的一员，则需要选择一个角色来执行操作，他无法在同一个会话中访问两个组的数据。
其次，将数据访问事件与最终用户关联的任务涉及一些无差别的繁重工作。如果请求来自一个名为 BusinessAnalytics 的 IAM 角色，那么还需要做其他工作来找出执行该操作的用户。
这个具体示例看起来可能很简单，但在现实生活中，组织有数百个用户和数千个群组，需要与数百个数据集进行匹配。对我们来说，这是一个创新和简化的机会。
创新和简化
扫码了解更多
配置完成后，新的可信身份传播将提供一种技术机制，使面向用户的应用程序能够代表键盘背后的实际用户访问数据。了解实际用户身份有三个主要优势。
首先，它使下游服务管理员能够根据实际用户身份、用户所属的群组或结合两者来创建和管理访问策略。下游服务管理员现在可以根据用户、群组和数据集来分配访问权限。这是我们大多数客户对数据访问顺理成章的看法，即不再需要中间映射到 IAM 角色来实现这些模式。
其次，审计人员现在可以访问系统日志中的原始用户身份，并且可以验证策略已正确实施且符合公司或行业层面政策的所有要求。
第三，商业智能应用程序的用户可以受益于应用程序之间的单点登录。最终用户不再需要了解贵公司的亚马逊云科技账户和 IAM 角色。相反，他们可以使用习惯的公司单点登录方式登录到 EMR Studio（举个例子），完成他们在工作中需要执行的许多其他工作。
可信身份传播的工作原理
可信身份传播依赖于我们行业的标准机制：OAuth2 和 JWT。OAuth2 是一种用于访问委托的开放标准，允许用户在不泄露其凭证的情况下，向第三方面向用户的应用程序授予对其他服务（下游服务）上的数据的访问权限。
JWT（JSON Web 令牌）是一种紧凑、URL 安全的方式，用于表示要在双方之间传输的身份和声明。JWT 经过签名，这意味着其完整性和真实性可以得到验证。
OAuth2
扫码了解更多
JWT
扫码了解更多
左右滑动查看更多
如何配置可信身份传播
要配置可信身份传播，需要在 IAM Identity Center、面向用户的应用程序和下游服务中进行设置，因为需要告知其使用最终用户身份。尽管每个应用程序在细节上存在差异，但它们都将遵循以下模式：
在 Amazon IAM Identity Center 配置身份源。如果您的身份提供者支持，亚马逊云科技建议启用自动配置（大多数提供者都支持此设置）。自动配置通过 SCIM 同步标准，将您的目录用户和组同步到 IAM Identity Center。如果您目前使用 IAM Identity Center 对员工进行亚马逊云科技管理控制台联合身份验证，那么您可能已经配置了此功能。这是一个一次性配置，您不必为每个面向用户的应用程序重复此步骤。
配置面向用户的应用程序，通过身份提供者对其用户进行身份验证。例如，配置 Tableau 以使用 Okta。
配置面向用户的应用程序与下游服务之间的连接。例如，配置 Tableau 以访问 Amazon Redshift。在某些情况下，需要使用适用于 Amazon Redshift 的 ODBC 或 JDBC 驱动程序。
Amazon IAM Identity Center
身份源
扫码配置
SCIM 同步
扫码了解更多
亚马逊云科技管理控制台
扫码了解更多
适用于 Redshift 的 ODBC
或 JDBC 驱动程序
扫码了解更多
左右滑动查看更多
然后是特定于可信身份传播的配置。例如，假设您的组织开发了一个面向用户的 Web 应用程序，该应用程序通过您的身份提供者对用户进行身份验证，并且您想代表当前已经过身份验证的用户访问亚马逊云科技中的数据。
对于此使用案例，您将在 IAM Identity Center 创建可信令牌颁发者。这个强大的新构造使您能够将应用程序经过身份验证的用户映射到 IAM Identity Center 目录中的用户，以便利用可信身份传播。
我的同事 Becky 撰写了一篇博客文章，介绍如何开发此类应用程序。只有在使用在亚马逊云科技之外进行身份验证的第三方应用程序（例如 Tableau）或客户开发的应用程序时，才需要此额外配置。使用由亚马逊云科技管理的面向用户的应用程序（例如 Amazon QuickSight）时，无需进一步设置。
可信令牌颁发者
扫码了解更多
Becky 博客
扫码了解更多
左右滑动查看更多
最后，下游服务管理员必须根据用户身份和组成员资格配置访问策略。确切的配置因下游服务而异。如果应用程序在 Amazon S3 中读取或写入数据，则数据所有者可以使用 Amazon S3 控制台中的 Amazon S3 访问授权向用户和组授予对 Amazon S3 中前缀的访问权限。
Amazon S3 访问授权
扫码了解更多
如果应用程序对 Amazon Redshift 数据仓库进行查询，则数据所有者必须在 Amazon Redshift 控制台中配置 IAM Identity Center 可信连接，并匹配来自身份提供者的受众声明（aud）。
现在您已经对配置有了大致的了解，接下来让我们深入了解最重要的部分：用户体验。
最终用户体验
尽管最终用户的确切体验显然会因应用程序而异，但在所有情况下，对于工作人员用户来说，它都将比以往更加简单、更加熟悉。用户交互将从基于重定向的身份验证单点登录流程开始，该流程会将用户引导至其身份提供者处，在那里，他们可以使用凭据凭证、多重身份验证等方式登录。
我们来详细了解一下配置可信身份传播后，最终用户如何与 Okta 和 Tableau 进行交互。
以下是系统和服务之间的流程和主要交互的示意图。
下面介绍了具体流程：
作为用户，我尝试登录 Tableau。
Tableau 启动基于浏览器的流程并重定向到 Okta 登录页面，我可以在其中输入登录凭证。成功进行身份验证后，Okta 会向 Tableau 颁发身份验证令牌（ID 和访问令牌）。
Tableau 启动与 Amazon Redshift 的 JDBC 连接，并在连接请求中包含访问令牌。Amazon Redshift JDBC 驱动程序发出 Amazon Redshift 调用请求。由于您的 Amazon Redshift 管理员启用了 IAM Identity Center，因此 Amazon Redshift 会将访问令牌转发到 IAM Identity Center。
IAM Identity Center 验证并确认访问令牌，并用访问令牌交换 Identity Center 颁发的令牌。
Amazon Redshift 将解析 Identity Center 令牌以确定相应的 Identity Center 用户并向其授予资源访问资源。授权成功后，我可以从 Tableau 连接到 Amazon Redshift。
经过身份验证后，我可以像往常一样开始使用 Tableau。
当我连接到 Amazon Redshift 查询编辑器时，我可以观察 sys_query_history 表以了解谁是进行查询的用户。该表正确报告了 awsidc:<email address>:，这是我从 Tableau 进行连接时使用的 Okta 电子邮件地址。
可用性
以下是有关可信身份传播和下游服务配置的更多详细信息。
使用 IAM Identity Center 和可信令牌颁发者简化员工身份管理：
*https://aws.amazon.com/blogs/security/simplify-workforce-identity-management-using-iam-identity-center-and-trusted-token-issuers/
使用 Amazon IAM Identity Center 将 Okta 与 Amazon Redshift 查询编辑器 V2 集成，以实现无缝单点登录:
*https://aws.amazon.com/blogs/big-data/integrate-okta-with-amazon-redshift-query-editor-v2-using-aws-iam-identity-center-for-seamless-single-sign-on/
使用 Amazon Redshift 和 Amazon Lake Formation 为外部身份提供者中的用户简化访问管理:
*https://aws.amazon.com/blogs/big-data/simplify-access-management-with-amazon-redshift-and-aws-lake-formation-for-users-in-an-external-identity-provider/
将您的员工身份带到 Amazon EMR Studio 和 Athena:
*https://aws.amazon.com/blogs/big-data/bring-your-workforce-identity-to-amazon-emr-studio-and-athena/
如何使用 IAM Identity Center 和 Amazon S3 访问授权开发面向用户的数据应用程序（分为两部分）:
祝您阅读愉快！
借助可信身份传播，您现在可以配置分析系统以将实际用户身份、组成员身份和属性传播到亚马逊云科技服务（例如 Amazon Redshift、Amazon Athena 或 Amazon S3）。
Amazon Athena
扫码了解更多
此功能不仅可以简化对这些服务的访问策略的管理，还使审计人员能够验证您组织的合规状况，以了解访问数据的用户的真实身份。
立即开始使用并配置 Tableau 与 Amazon Redshift 的集成。
* 附注：即使文章标题下只有一个署名，但撰写亚马逊云科技的文章始终离不开团队的共同努力。对于这篇文章，要感谢 Eva Mineva、Laura Reith 和 Roberto Migli 帮助我理解可信身份传播的许多微妙之处和技术细节。
本篇作者
Sébastien Stormacq
亚马逊云科技首席开发者布道师。自八十年代中期第一次接触 Commodore 64 以来，Seb 一直从事代码编写工作。他对软件架构、开发人员工具和移动计算领域充满热情，致力于激励构建者更好使用和发挥亚马逊云科技的价值。
星标不迷路，开发更极速！
关注后记得星标「亚马逊云开发者」
听说，点完下面4个按钮
就不会碰到bug了！
点击阅读原文查看博客！获得更详细内容！
扫一扫
9306
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
