学习身份验证语言

学习目标

完成本模块后，您将能够：

了解身份验证和访问权限管理采用的行业标准。
知道 SAML 和 XML 的关系。
知道身份提供商和服务提供商的区别。

身份验证标准和协议

很难相信用户不必登录外部网站或应用程序您也可以保证用户身份的安全吗？这么多公司的产品，甚至是互相竞争的产品，是如何一起工作的？

答案：针对身份验证和访问权限管理的行业标准与协议。这听起来可能有点不明觉厉，不过未必一定要这样。标准是指一套行业成员共同遵守的广泛认可的惯例。标准可以包含一项协议，规定系统如何交换信息。

下面是 Salesforce 和其他身份厂商在实施身份验证解决方案时共同遵守的三项协议。

SAML
OAuth 2.0
OpenID Connect

SAML 协议

如果想让用户在 Salesforce 组织和应用程序之间无缝切换而不必重复登录，您可以设置单点登录 (SSO)。安全声明标记语言 (SAML) 是实现这个功能的协议。

下面几个例子说明 SAML 的作用。

当您登录到 Salesforce，然后点击应用程序启动器就可以直接进入您的 Gmail 邮箱时，就是 SAML 在起作用。
当已经登录到另一个应用程序的用户无需再次登录就可以访问他们的 Salesforce 组织时，也是 SAML 在起作用。

SAML 声明

这是 SAML 的工作原理。一位用户试图访问一项服务。该服务提供商向身份提供商发出一条请求，大概是询问，“您好，这个用户可以访问我的服务吗？”身份提供商检查其数据库确认用户的真实身份，然后返回一条回复消息，即声明，说，“可以，该用户经过授权，这是该用户的一些信息。”

稍等。身份提供商和服务提供商的区别是什么？基本上来说，身份提供商是验证用户身份的人。服务提供商请求经过验证的身份。稍后我们将在本单元进一步讨论身份和服务提供商。

声明就是发出的信息。一份声明可以包含关于某个用户的详细信息。它还包括用户的属性，比如姓名、联系方式，可能还有职务。

SAML 发生在后台。您的用户看不到它的任何东西。他们只需点击一个图标或链接，打开另一个应用程序，无需提供额外信息或再次登录。有时候当他们抵达时，他们的目的地已经知道他们的一些情况（那些用户属性）。

SAML 和 XML

SAML 是一种基于 XML 的协议，意思是被交换的信息包是用 XML 语言编写的。XML 应该（几乎）是人类可读的，这样您可以大概知道在发生什么。当您在试图摸清楚事情做得是否正确时，这是好事。

下图展示 SAML 声明的一部分。看起来是不是有点像乱码？再看一下，您可以看到它看起来并没有那么糟。它包含用户的用户名、电话号码以及名字等信息。

在这个例子中，Salesforce 组织把该用户的信息传输给了另一个应用程序。该应用程序可以使用那些信息授权该用户，并且将用户体验个性化。不过最重要的是，该用户不必再次登录就可以访问该应用程序。

OAuth 2.0 协议

OAuth (Open Authorization) 2.0 是一种开放协议，用于应用程序之间的安全数据共享。用户在一个应用程序里工作，但是可以看到另一个应用程序的数据。比如，您登录 Salesforce 移动应用程序，看到来自您的 Salesforce 组织的数据。

在后台，应用程序执行一种握手，然后请用户授权本次数据共享。当开发人员想把他们的应用程序与 Salesforce 集成时，他们使用 OAuth API。

下面是几个例子。

一款从 Salesforce 组织读取联系人的移动应用程序使用 OAuth。
一个 Salesforce 组织从另一个服务获取联系人也使用 OAuth。

下面是一个应用程序使用 OAuth 2.0 请用户允许访问信息的例子。

OAuth 登录示例

OpenID Connect 协议

OpenID Connect 协议在 OAuth 2.0 之上增加了一个身份验证层，实现用户信息的安全交换。跟 SAML 一样，OpenID Connect 把身份信息从一个服务发到另一个。与 SAML 不同的是，OpenID Connect 是专门为当今的社交网络世界打造的。您是否在安装新的应用程序时遇到过“用您的 Google 帐户登录”这样的提示？那个应用程序使用的就是 OpenID Connect 协议。当您用 Google 登录时，您并不会创建一个帐户和另一个密码。只有 Google 掌握那些信息。

应用程序开发人员使用 OpenID Connect 协议来启用社交登录。

比如，当 Google 代表另一个服务确认用户的身份时，它在验证该用户。因此 Google 是身份提供商。

Salesforce 出厂就支持多个主要社交媒体身份提供商，包括 Google、Facebook 和 LinkedIn。如果某一提供商不是出厂就默认支持的，如果它实施了 OpenID Connect 协议，您仍然可以使用它—就像 Amazon 和 PayPal 那样。

对于用户来说，OpenID Connect 协议的优势是它可以减少独立帐户、用户名和密码的数量。另一方面，开发人员可以验证跨网站和应用程序的用户，不必拥有和管理密码文件。这个过程使黑客破解用户帐户要难得多。

服务提供商和身份提供商

在验证用户身份过程中，SAML 在信息持有者即身份提供商 (IdP) 与期望的服务即服务提供商之间交换身份信息。

某个用户登录 Salesforce 然后访问 Gmail 的情况下，Salesforce 是身份提供商，Google 是服务提供商。Salesforce 既可以是服务提供商，也可以是身份提供商。

Salesforce 作为服务提供商

经过身份验证的用户可以从一家外部身份提供商流入 Salesforce。在这种情况下，Salesforce 是服务提供商，用户希望获得这项服务的访问权限，而且他们的身份提供商允许他们这么做。这种 Salesforce 配置很常见，因为您的公司往往已经在使用一家身份提供商了。身份提供商可以是市面上的其中一家，如微软的 Active Directory Federation Services (ADFS)、Ping Identity 的 PingFederate、开源 Shibboleth 或 ForgeRock 的 OpenAM。

用户从一家身份提供商登录，然后被导流到 Salesforce（服务提供商）。在另一个模块中，您将设置 SSO（单点登录），以 Salesforce 作为服务提供商、一个第三方应用程序作为外部身份提供商。

Salesforce 作为身份提供商

经过身份验证的用户也可以从 Salesforce 流入其他云和应用程序。在这种情况下，Salesforce 充当身份提供商，为用户提供 SSO（单点登录），以连接不同服务提供商。

针对 SSO（单点登录）的 SAML 流

为了满足好奇心，下图展示 SAML 通讯在 SSO（单点登录）过程中是如何流动的。这是后台发生的事情。如果您没兴趣一窥究竟，也不要担心。它不是考试内容。

SSO（单点登录）过程以光速发生，但是涉及几个步骤。

一位用户试图访问 Salesforce。
Salesforce 识别 SSO（单点登录）请求并生成 SAML 请求。
Salesforce 把 SAML 请求返回给浏览器。
浏览器把 SAML 请求转发给外部身份提供商。
身份提供商验证用户身份并把 SAML 声明打包，其中包含用户身份验证。
身份提供商把 SAML 声明发给浏览器。
浏览器把声明转发给 Salesforce。
Salesforce 核实声明。
用户现在已经登录，可以访问 Salesforce。

身份验证术语小抄

上一个关于身份验证协议主题的速成班如何？当有些词听起来很像、区别很小时，很难分清它们。所以这里有一份小抄。希望它对您有帮助！

一个词	很容易与这个词混淆
身份验证是指某人是谁。如今，身份验证常常被用作授权和验证的缩写。	授权是指某人能够做什么。
协议规定一套规则，使系统可以交换信息。一般来说，协议和标准这两个词可以互换。	标准是指规范，厂商同意支持的一套行业惯例。标准往往包含一项协议，规定公司如何实施该标准。
用户名和密码是用户为了登录一个系统提供的东西。	凭据基本上是相同的东西。
单点登录 (SSO) 使一个人一次登录就可以访问其他应用程序和服务，无需再次登录。	社交登录使一个人可以用 Google 之类的社交帐户设置的凭据登录一个应用程序。那个应用程序接受 Google 凭据，然后用户无需创建另一个帐户和密码。
身份提供商是一个被信任的服务，使用户无需再次登录就可以访问其他网站和服务。	服务提供商是一个网站或服务，提供应用程序，接受来自另一个身份提供商的身份验证。

接下来做什么？

您已经快速学习了关于身份访问和管理的行业标准。如果觉得很难理清头绪，也不要担心。眼下只需记住 Salesforce Identity 使用协议来实施它的功能。

现在开始有趣的部分！是不是已经被一堆概念和定义烦死了？我们来运用您学到的一些东西吧。在本学习路径后面的部分，您将在您的 Salesforce 开发组织中设置安全功能。