是什么？
- 当某一用户已经拥有了一个其他App的用户身份（比如：Google、Okta..）
- 此时，不需要为这个用户在IAM中创建一个user并且给这个user配置
policy - 该用户可以直接通过比如Google的用户身份去访问AWS的资源。
--> 此时Google就是身份提供商
工作流程
- 如果某个用户想要访问AWS service
- 而作为root用户的你，却没有给他在IAM 上给他创建一个user
- 当时此用户拥有一个Okta账号密码
- 此时你在IAM中
create IDP for okta配置相关选项，在两者间建立互信机制 - 并为该Okta账户赋予权限（role）
此时：
- 该用户访问AWS资源首先输入自己的okta用户名和密码
- 通过登录后即可访问role中赋权限访问的资源
内容包含什么？
- 如何建立AWS与IDP之间的信任关系
- 如何给来自IDP的外部账号赋予访问不同service的权限
image.png
补充：
AWS Security Token Service (AWS STS) 创建可控制对您的 AWS 资源的访问的临时安全凭证，并将这些凭证提供给可信用户。
建立AWS与IDP之间的信任关系
在AWS的IAM中选择Identity Provider实体，然后创建。
- 选择type是SAML
- 到你选用的IDP中创建
saml-metadata.xml上传至AWS
给来自IDP的外部账号赋予访问不同service的权限
首先需要了解AWS的ROLE实体
AWS ROLE
- what：是一个AWS实体，这个实体可以被赋予不同的
策略（Policy）,也就意味着某一个ROLE具有对某个AWS SERVICE的某种操作权限。但是这个ROLE并不是分配给某个USER的，而是分配给AWS资源或者IDP的。- why：不同于USER需要输入
Access key ID和access key使用AWS API访问AWS资源。只要当前的资源被赋予了某个可以访问AWS资源的ROLE就可以直接访问。不用担心key被泄露的危险- how：创建ROlE之后可以copy出
Instance Profile ARNsattach到需要使用这个role的AWS资源即可
image.png
- 参考资料：http://blogzhoubo.iteye.com/blog/2381624
- 原理：ec2内部是通过role name调用sts(AWS Security Token Service)来获取credentials信息的。这种动态获取的credentials是有生存周期的，过期自动失效，ec2 instance会在过期之前自动获取新的credentials，ec2 instance会把有效的credentials保存在meta-data中
- 给IDP用户的权限通常都是通过给Role实现的
- 因此可通过到AWS UI上选择
SAML 2.0 federation创建角色
