鲁达 Matt是AWS合作伙伴网络（APN）的解决方案架构高级管理者，与APN SaaS（软件即服务）合作伙伴合作密切。
如果你正在AWS中构建一个SaaS解决方案，很重要的一点是追踪谁正在使用你的应用。大多数SaaS解决方案也要求有一个认证层和连接的连接的加密数据来识别以便你可以建立一种个性化的用户体验，允许用户存储文档和设置，并进行访问控制。没有人喜欢再记住另一个密码，减少用户磨蹭对保持高客户率是很重要的。管理员也不喜欢密码，因为除了需要资源来处理登录请求外，在安全地存储它们时也会涉及到额外的操作负担。也许最重要的是，如果你的应用并未连接到企业身份商店，例如LDAP（ 轻量级目录访问协议）或Microsoft Active Directory（微软活动目录），当员工离职或改变角色时，撤销访问权限可能会很复杂。为了解决这一问题，SSO已经被广泛采用，因为它允许人们使用另一来源授予的认证方法登录你的SaaS应用。这意味着你的用户需要记住密码更少和拥有更多的灵活性，而且当正确实施时，你可以获取关于你应用的有用分析结果和更高的安全性。在本博客贴中，我们探索了SSO背后的一些技术和概念，并探索着将第三方用户身份和你的应用联系起来（即身份联合），此外还将探索可以帮助实施身份联合的AWS产品和合作伙伴解决方案。
对终端用户来说，SSO应该是一项简单的体验，但是它在后台则依赖一连串复杂的事件。“身份，授权和认证”是任何标准的SSO过程中所需步骤的通用描述。身份说明你是谁，授权证明你是那个人或事件，认证决定你被允许的操作。大多数SaaS解决方案也会实施第四个步骤，审计。这允许你将既定的身份和活动（从登录到针对特定应用的动作）联系起来。
授权
身份联合中的授权部分与亚马逊EC2中AWS身份及访问管理 （IAM）角色遵循一套类似的模式：你在亚马逊被认证是否有权访问AWS API或管理控制台，然后使用一个IAM角色启动一个EC2实例。与该IAM角色相关联的策略决定了运行在该亚马逊EC2实例上的应用所具备的作用。身份联合和这一模式几乎一样，因为认证发生在应用之外，然后一套安全程序和策略决定了一旦用户成功登录并访问你的应用，将能看到的东西和所能进行的操作。
我们在我们自己的AWS管理控制台上也采用了这种方法，使你能够利用你自己的联合身份解决方案向你的用户授予基于角色的访问权限：
这里就是身份协议引入的地方。这些协议允许你将存储在别的地方的身份与你的应用将关联，决定了身份应该如何与应用级的许可相映射。
身份协议
在单点登录AWS管理控制台的情况下，你使用AWS STS创建临时证书（特定时间后就会失效）。IAM策略用来决定继承那些证书的用户可以访问的AWS业务和特性。在你自己的应用中，你可以有一个自定义的令牌和证书生成器。在你交出访问密钥，分配访问策略前，你还需要一个来自你信任的身份供应商的断言，证明一个合法用户正在请求访问密钥但并不要求知道该用户的密码。SAML 2.0和OpenID Connect是解决这一问题的更为广泛使用的两个身份协议。
SAML 2.0于2005年三月底最终完成，是使用XML语言来交换信息的登录协议。在XML令牌的主体中，数字签名在身份供应商和营业间建立起信任关系。你也可以随意地加密数据和增强安全策略，如强制的双因子认证。我喜欢开玩笑说,SAML 2.0是你的祖母的身份协议。它被尝试，信任，并且是有效的（也很容易受到欢迎），但是它已经开始显示出它的不足了。
OpenID Connect 1.0是建立在OAuth 2.0协议之上的简单身份层。像SAML 2.0一样，它允许第三方在不知道你的密码的情况下确认你的身份。不像SAML的是，它的令牌格式要简洁的多，而且是基于JSON的。很多人拒绝它，连同它的更老的基于XML的堂兄弟，OpenID 2.0和OAuth 2.0。OAuth 2.0其本身并不用户授权，认证或联合；它只是用于委托。OpenID Connect 1.0扩展了OAuth 2.0协议，顾及到很多方面，像有效负载中包含的加密和身份信息。与SAML 2.0不同的是，在令牌中没有签署的身份信息，所以需要一个额外的往返过程来验证令牌。尽管如此，OpenID Connect灵活的令牌和协议设计使很多开发者在身份联合或单点登录中采用它。使用案例包括Google+登录，微软和Salesforce。其他受欢迎的web身份联合（WIF）系统，例如Facebook登录和亚马逊登录，也使用OAuth 2.0，但是使用它们自己的像OpenID Connect 1.0的身份层。
选择身份存储方式
确定使用什么身份存储方式是你第一个，可能也是最重要的决定。信任关系对SaaS供应商，特别是那些承载敏感信息的供应商来说是非常重要的，你可以通过将你的身份存储外包到你的用户信任的一个安全的第三方，从而潜在地减少风险，增强安全性。这些用户可能是受欢迎的web服务，如亚马逊，Facebook或Twitter。企业通常有它们自己信任的身份存储方式，你可以在你的应用中间接地利用这些存储方式。这些存储方式包括LDAP，Microsoft Active Directory/ADFS，Shibboleth，CA SiteMinder，Oracle Identity Manager，Novell SecureLogin等等。
AWS Directory Service（AWS目录服务）则是另一个选择。基于SAMBA 4，AWS目录服务允许你提供一个用户目录，增加小组成员，将机器添加到域，实施Kerberos单点登录，应用Group Policy（组策略）。AWS目录服务也可以将一个既存的活动目录（AD）扩展到云中，与IAM集成。这种方法可以使与目录关联的用户直接或通过你的AD服务器单点登录到AWS管理控制台。
代理多个身份存储方式
好消息是你不必只选择一种身份存储方式，有很多受欢迎的身份代理解决方法可以为你的用户提供多种登录选择。这些解决方案也允许你审计访问活动，使你能够跨多个身份存储方式，可视化地展示你的应用用户和使用方式。重要的是，其中的几个解决方案支持多因子认证。在多因子认证中，在用户进行本地登录或多因子认证与一个补充的AWS合作伙伴解决方案联合使用时，用户必须输入通过SMS收到或在个人硬件设备上生成的代码。Ping，Okta，SecureAuth和Auth0只是AWS合作伙伴中的一些，为单点登录和跨多身份供应商的联合登录提供身份管理解决方案。点击这里，阅读更多关于可用选择的信息。
Amazon Cognito服务使在AWS中存储用户数据，如应用喜好或应用状态，变得更简单，它不需编写任何后台代码或管理任何基础设施。它也可以充当一个身份中介，实际上是提供WIF所提供功能的超集。Amazon Cognito支持若干流行的WIF，包括亚马逊登录，Google登录，Facebook登录，Twitter登录和任何与OpenID Connect兼容的身份供应商（IdP）。它也有一个嵌入的证书供应商，又因为它与AWS SDK实现了集成，与为AWS构建的应用一起使用是很简单的。
总结
用户越来越想使用一套证书来跨越多个SaaS应用使用。我们自己已经看到了AWS管理控制台单点登录或联合访问的需求。管理员也想将账户，认证和授权管理集中化，以便减少与用户和策略管理相关的操作开销，同时获取有关使用模式的有价值见解。安全小组想要在员工离职和改变角色时能轻松地撤销访问权限，也想增强像双因子认证这样的安全策略。所有这些需求都可以通过正确地组合身份供应商，身份协议，代理解决方案，临时令牌和基于角色的访问来得到满足。
在AWS，我们在研发新产品和特性时，总是从客户需求出发，逆向操作。当你决定如何构建SaaS应用的身份，认证，授权和审计部分时，你也可以使用从需求出发，逆向操作这种方法。你的客户是否已经有了一个它们更钟爱的用于单点登录的企业身份存储方式？那种身份存储方式支持SAML 2.0或OpenID Connect 1.0吗？你是否为你的用户提供多种身份，因而身份代理业务是否会是一个好的选择呢？问自己和其他与以上信息有关的人这些问题将会在后面的过程中节省很多时间，并带来更好的用户体验。
总之，
- 放开：除非你真的需要它，将身份管理进行外包，减少无差别的沉重负担以便你可以专注核心业务。
- 以客户需求为出发点逆向操作：选择最适合客户的身份存储方式和协议。
- 灵活：使用身份代理，使你支持多个身份协议和身份供应商。
- 少为精：仅请求你的应用所需的用户数据，将剩余数据交由身份供应商存储，由此获取客户信任，减少责任或风险。
- 拥抱未来：不要将自己拘泥于SAML 2.0这样的老化协议。
点击这里了解更多关于AWS SaaS Partner Program（AWS SaaS合作伙伴项目）的信息。