Hello大家好，我们接下来讨论AWS联合身份验证的内容。

AWS联合身份验证

对于考试，联合身份验证部分是一块非常重要的内容。那什么是联合身份验证，它是做什么用的呢？

联合身份验证，是用来允许AWS外部用户，如您的公司目录中的用户，外部三方用户，通过代入AWS的角色，然后通过代入角色的临时安全凭证的方式访问AWS的资源。

我们看一下联合身份验证大致的流程：

• 首先，您的用户通过第三方的用户系统进行身份验证，AWS要信任这个第三方。
• 当用户登陆时从三方那拿回了凭证，然后通过交换或使用这个凭证来访问AWS资源。

联合身份验证的核心思想是通过AWS信任的第三方的用户系统来执行所有的用户管理行为。

AWS的联合身份有多种形式，我们需要了解所有这些形式，以及在面对不同的使用场景选择最适合的方案：

• 第一个是，SAML 2.0
• 第二个是，用户自定义身份代理
• 然后是使用Cognito的WEB身份验证及【12】不使用Cognito的WEB身份验证
• 还有SSO，单点登陆
• 以及AWS托管的 Microsoft AD (Non-SAML)

使用联合身份验证，不需要我们为这些用户在AWS账户中创建IAM用户，用户管理工作是在AWS外的用户系统中完成的。

那我们接下来的内容就开始讨论上面联合身份验证的几种形式。

SAML 2.0联合身份验证

首先，SAML 2.0联合身份验证。

SAML 2.0，也就是安全断言标记语言 2.0，它支持联合身份验证，是许多身份验证提供商 (IdP) 使用的一种开放标准。

如您的公司已使用支持 SAML 2.0 的身份提供商，比如本地的Active Directory（活动目录），或者ADFS（活动目录联合服务）等，那么可以使用 SAML来简化为AWS 配置联合身份验证的过程。

那在这种场景下，您公司的员工的用户已经在您公司支持 SAML 2.0的身份提供商中存在了，通过配置就可以实现联合单一登录 (SSO)，就可以通过临时凭证，然后实现这些用户的登录AWS控制台或调用 Amazon API 操作，而不需要为每个员工都创建一个 IAM 用户。

我们来看下大致的流程：

1、您公司的用户使用客户端应用程序来请求您公司的 IdP （身份提供商）进行身份验证。

2、IdP 根据身份存储对用户进行身份验证。

3、验证通过，IdP 构建一个具有用户相关信息的 SAML 断言，并将此断言发送到客户端应用程序。

4、客户端应用程序调用 AWS STS AssumeRoleWithSAML API，并传递 SAML 提供商的 ARN、要代入的角色的 ARN 以及来自 IdP 的 SAML 断言。

5、然后STS的API 对客户端应用程序的返回临时安全凭证。

6、最后客户端应用程序使用收到的这个临时安全凭证来调用 Amazon S3 API 操作。

同样，整个流程也适用于访问AWS控制台：

1、首先用户通过一个网站比如您公司的门户网站，验证用户的身份。通常在这个场景，门户网站充当处理您公司与 AWS 之间的信任交换的 IdP。

2、然后同样该门户网站生成一个 SAML 身份验证响应，将此返回给客户端浏览器

3、该客户端浏览器将被重定向到 AWS 单一登录终端节点并发布 SAML 断言。

4、SSO终端节点将代表用户请求临时安全凭证，并创建一个使用这些凭证的控制台登录 URL，并作为重定向返回给客户端。

5、最终该客户端浏览器将重定向到 AWS管理控制台。

综上，如果您公司的身份验证提供商 (IdP) 是支持SAML 2.0的，建议采用上述的两种方式调用AWS的API或者访问AWS管理控制台。

SAML 2.0联合身份验证 - Active Directory FS

还有一部分是ADFS联合身份验证过程，

整个过程与前面讨论的SAML 2.0的IdP过程基本是一致的。

可以看到不在使用IdP，取而代之使用ADFS对用户进行身份验证，后端使用AD作为身份存储，ADFS返回给用户SAML断言，发送给STS，然后用户使用临时凭证访问AWS管理控制台或者AWS资源。

那么如何配置SAML 2.0 联合身份验证呢？

在使用前面所述的基于 SAML 2.0 的联合身份验证之前，您必须先配置组织的 IdP 和您的 AWS 账户，使之相互信任。

然后在通过相应配置，就可以通过SAML 2.0 实现基于WEB的跨域SSO（单点登陆）。当您公司的用户登陆公司的门户后，即可获得对多个AWS账户的访问，而不需要在重复登陆AWS进行身份认证。

这种方式是通过客户端应用程序调用 AWS STS AssumeRoleWithSAML API，前面流程我们已经讨论过了，要记住这一点。

目前AWS有一个服务叫做AWS Single Sign-On，可以更加简单的实现上述的SAML 2.0联合身份验证，也是AWS更加推荐的方式，我们也会在后面的课时讨论。

自定义身份代理

前面我们讨论了基于SAML2.0的联合身份验证，那如果您公司的IdP不兼容SAML2.0，就需要使用自定义身份代理，来访问AWS控制台或资源。

这种方式需要在身份代理处分配给用户适当的IAM策略，所以需要在这里做更多的工作。为用户获取临时安全凭证通过AssumeRole（推荐）或 GetFederationToken API 操作。

我们看下整个流程，和之前有些区别：

• 用户进行登陆，然后到身份代理程序，通过公司的身份存储进行用户登陆验证；
• 验证通过后，身份代理程序直接和STS通信，获取临时安全凭证，用于允许用户执行授权的操作。大家注意，这部分和之前SAML2.0的流程是有区别的，之前是在用户侧和STS进行通信，而这里是身份代理程序直接和STS通信。
• 然后身份代理获取临时凭证后，将其传给用户，然后用户就可以通过这些凭证访问AWS的资源如EC2、S3等或访问AWS管理控制台。

所以这里主要和之前SAML2.0联合身份验证的主要区别是，自定义身份代理方案，不是用户侧和STS交互临时凭证，而是在身份代理这里与STS交互临时凭证。

**对于考试而言，只有在您的组织没有使用与 SAML 兼容的身份提供商 (IdP)时，才使用自定义身份代理。**还有一点，这个方案的身份代理部分是否配置正确非常的重要，而且会涉及到很多的工作。

Web联合身份验证 - AssumeRoleWithWebidentity API

好的，接下里我们讨论下Web 联合身份验证。

比如我们创建了一个移动程序，或者WEB应用程序，我们希望能够让用户访问到我们AWS账户下的指定的资源，如S3，DynamoDB，存储一些用户的数据，这是非常常见的场景。

• 第一种实现方式是编写代码然后通过调用 AssumeRoleWithWebIdentity API；这也是常用的方式；
• 而AWS更推荐使用AWS Cognito来取代上面这种方式。AWS认为Cognito更棒，除了实现所有功能，还允许匿名访问，支持数据同步，以及MFA认证。

那我们也看一下第一种方式的流程：
1、手机的应用程序调用第三方身份提供商对用户和应用程序进行身份验证，比如amazon，google,facebook等等。身份提供商会返回 Web 身份验证令牌到应用程序。
2、然后应用程序通过AssumeRoleWithWebIdentity API调用STS并传递Web 身份验证令牌，STS返回临时凭证，允许应用代入IAM角色和访问AWS资源。
3、最后应用程序就可以访问如这个图示中的例子DynamoDB的表。

SAML 2.0联合身份验证 - AWS Cognito

那前面也提到了，AWS推荐使用AWS Cognito来实现WEB联合身份验证，我们来看一下。

• 需要使用 Amazon Cognito 创建一个IAM角色，这个角色的权限要遵循所需最小权限原则；
• 同样在OIDC IdP和Cognito两侧要建立信任。

我们来看下整个架构：

您的应用程序的用户可以使用他的三方如google、facebook、amazon、cognito账密登陆；

然后应用程序使用 Cognito API 操作将 登陆三方的令牌交换成 Cognito 令牌；

接着应用程序使用 Cognito 令牌从 AWS STS 请求临时安全凭证；

最后应用程序可使用临时安全凭证访问应用程序运行所需的 AWS 资源，与临时安全凭证关联的角色及其分配的策略将决定它可访问的资源。

整个流程和API的方式有些类似，但是使用Cognito的优势是：

• Cognito支持匿名用户，而WebIdentity API是不支持的。
• 它支持MFA,所以可以在过程中强制使用MFA，这样我们就有了更多的安全保障。
• 最后是数据同步。

另外如果大家在哪里看到一个叫做TVM，Token Vending Machine，这是AWS比较老的一个解决方案，目前使用Cognito来替代它。

最后如果在考试中看到WEB联合身份验证相关的内容，AWS总是希望您会选择使用Cognito，它有很多的优势，另外AWS总是希望您选择AWS的服务来实现需求。

Web联合身份验证 - 识别用户的身份

在使用Web 联合身份验证在 IAM 中创建访问策略时，可根据已使用外部身份提供商 (IdP) 进行身份验证的用户的 ID 指定权限，这是通过IAM的策略变量来实现的。策略变量对我们面对一些场景时是非常有帮助的。

那在IAM策略中如何获取用户登陆后外部身份提供商对应的该用户的ID呢：

我这里列了一下congnito，amazon，facebook，google这4家的方式：

• congnito是通过：cognito-identity.amazonaws.com:sub
• amazon.com是通过：www.amazon.com:user_id
• facebook是通过：graph.facebook.com:id
• google是通过：accounts.google.com:sub

我们来看一个例子：

这是一个IAM策略，允许操作，动作是s3:ListBucket。

关键是在这个condition，它的意思是只有在 Amazon S3 中的存储桶前缀与这个字符串匹配时，该策略才会为该存储桶授予访问权限。而这里变量www.amazon.com:user_id，会代入用户通过amazon.com登陆后对应的该用户的ID，所以也就是说，这个策略的作用是假定用户使用 Login with Amazon 登录，该用户只能访问对应自己的ID的这个存储桶前缀位置。

这为使用Web 联合身份验证时，分配用户的权限提供了更多的灵活性。

那我们最后概括一下，使用联合身份验证，来管理 AWS 外部的用户身份；而IAM策略可以通过策略变量代入用户ID的方式，为外部的联合身份用户分配适当的访问权限。

好的，以上就是联合身份验证的内容，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们