mongodb启用身份验证
社交网络和用户“身份疲劳”正迫使企业接受分布式身份作为其数据和应用程序的身份验证途径。 实际上，根据ISACA，国际专业协会致力于IT治理（请参阅参考资料 ）：
“ IT的消费化”是近年来影响IT组织的最重要趋势之一，并且随着市场上越来越多的新型智能设备的涌现以及普通员工的移动性越来越强，重要性可能会越来越高。 这一重要趋势不仅涉及新设备。 它关系到IT及其用户群之间的整个关系。 此外，这种趋势还带来了重大的安全问题，因为关键的IT资产需要安全地提供给使用自己选择的消费类设备的，越来越分散和多样化的用户群。 当最初的消费化宣传重点放在自带设备（BYOD）趋势上时，我们现在看到了自带身份（BYOI）的出现。 用户的“身份疲劳”推动了BYOI的兴起。 用户拥有太多帐户，太多用户名和太多密码。 这就使得在一个新站点注册一次恶性肿瘤的仅仅一步就太多了。 当竞争从字面上单击时，组织必须提供尽可能简单的用户体验，或者用户迁移到提供最简单的注册和登录过程的站点。 值得庆幸的是，许多网站已经Swift接受了来自流行的在线身份提供商（例如Facebook，Google和LinkedIn）的身份。
根据IDG Connect（请参阅参考资料 ）：
- 消费者身份的主要和次要来源是社交媒体（21％）。
- 目前，有58％的欧洲企业向外部用户开放其应用程序。
结果就是您自己的身份（BYO-ID） ，即在企业系统中使用和保护用户现有的社交媒体ID的能力。
在本文中，我们描述了一种利用安全开放标准来实现企业到消费者渠道中的身份生命周期操作的方法。 这些操作包括BYO-ID身份验证和用户注册。 您将了解如何通过利用IBM Security Systems解决方案产品中的产品功能，与流行的社交和云提供商实施身份验证和注册模式。 要观看实际操作中的BYO-ID的视频演示，请参阅“ 使用Tivoli Federated Identity Manager进行的自我注册和自带身份 ”。
BYO-ID的背景
首先，让我们探讨实现BYO-ID的一些背景，包括如何管理企业用户帐户和访问，身份验证和身份控制的开放标准是什么以及BYO-ID如何影响身份验证保证。
互联网帐户生命周期管理
在企业内部管理用户帐户和访问的过程是众所周知的。 它通常包括使用身份管理产品（例如IBM Security Identity Manager），并且不仅关注帐户管理操作。 云计算和相关联的在线身份的影响正在改变企业查看和处理企业对消费者环境的帐户供应和管理方式。
在基于Internet的企业对客户方案（B2C）中，其中在线服务用于注册，注销和帐户管理的授权模式，可以采用更简单，更轻松的解决方案。 许多较小的社交和云产品都不构建自己的解决方案，而是利用较大的社交网络的身份验证功能来减轻密码管理的负担。 这种趋势摆脱了传统的在线注册过程，传统的在线注册过程依靠用户使用其所有个人详细信息填写Web表单，取而代之的是，用户现在已经习惯于与现有社交网络合作以在新产品中引导其注册过程的想法。 。 BYO-ID的社交网络组件包括允许用户将他们现有的社交媒体帐户（Google，Facebook，Twitter）带到新服务中，以减少与传统帐户注册相关的手动任务。
企业客户也希望这些功能成为企业帐户注册过程的一部分。 为了加快用户对B2C服务的采用，企业也在考虑如何简化在线注册流程。 尽管企业可能不信任社交网络为其内部服务提供单点登录（SSO），但B2C集成方案必须考虑提供类似的流量，即使这意味着对此类身份验证事件主张较低的信任度。
BYO-ID开放标准
安全开放标准主要是针对供应商的互操作性而开发的，在大型社交和云供应商领域中，这一方面最为重要。 如果没有可靠的互操作性标准，这些服务将根本无法提供其所能提供的价值。 同样，在B2C环境中，如果不需要实体之间的法律和业务协议，采用率也会增加。
访问管理开放标准的采用有所加快，这在很大程度上是由于Twitter，Facebook和Google等社交网络巨头对标准的支持（和开发）。 本文中描述的模式是指以下开放标准：
- SAML（1.x-2.x）：安全性声明标记语言是实现用户身份联合SSO和供应的标准。 它记录了用于在安全域之间交换身份验证数据的在线协议标准； 也就是说，在提供身份的用户或过程（断言的产生者）和服务提供者（断言的使用者）之间。
- OpenID：一种开放标准，描述如何以分散方式对用户进行身份验证。 它为用户提供了一种在连接到不同网站时通过使用单个OpenID来巩固其数字身份的方法。 有效地，它消除了对在本地维护身份密码的服务的需求。 SAML和OpenID之间的主要区别在于，SAML要求在系统可用之前，身份和服务提供者之间的联合信任，而OpenID不提供。 还有其他差异，但这是主要差异。
- OAuth（开放授权）：提供委托授权的开放标准。 它为用户提供了一种以委托方式与第三方实体共享资源托管站点上的个人资源的方法。 在此标准中，永远不会与该第三方实体共享用户的身份验证信息（例如，密码）。
认证与信任
企业倾向于要求高水平的业务和法律协议来信任第三方服务，以验证用户的身份。 这些组织在从事金融服务或在其他受到严格监管的政府领域中尤其如此。 这与社会服务的重要区别是，社会服务向大量用户免费或以低成本提供服务。 该业务模型侧重于增加服务之间的用户交互； 在某些情况下，不存在（来自用户的）服务信任。
您必须考虑的一件事是，在线社交企业的注册无法提供任何依据来相信一个人对此注册负有责任。 因此，可以使用社会身份向另一个服务提供商或组织进行身份验证，但是可能有必要限制它们可以执行的访问或操作，而无需其他或第二种身份验证。 至少，信任此模型的服务提供商必须与个人之间已有某种预先存在的关系，以便他们可以在需要时增加身份验证保证（例如，用户名/密码）。
在本文中，我们还将向您展示在BYO-ID方案中如何使用身份验证机制在不同的注册状态之间进行转换。 这些机制可以允许企业将身份验证级别分配给社交身份验证事件，从而可以使用安全策略来控制此类会话允许的访问权限。
与BYO-ID相关的产品和服务
让我们关注可以使用IBM Security Systems解决方案实现的BYO-ID集成模式，包括用于实现BYO-ID用例的解决方案组件和开放标准。 相关的IBM Security Systems产品功能包括：
- 网络安全联络点
- 联合SSO
- 用户自我保健
- 一次性密码认证服务
让我们进一步研究实现BYO-ID的相关产品和功能。
IBM Security Access Manager Web网关设备
IBM Security Access Manager Web网关设备是提供Web应用程序防火墙功能的单点登录设备。 Web Gateway Appliance提供了具有集中式用户访问管理功能的Web反向代理安全解决方案，以向Web应用程序提供高度可扩展的用户身份验证，授权和审核服务。 它利用IBM X-Force团队提供的情报网络来提供策略驱动的Web应用程序漏洞保护。
Web Gateway Appliance也可以实现为Web Gateway Appliance部署的前端负载平衡器。 IBM Security Systems WebSEAL软件在此设备内提供代理功能。
从BYO-ID标准的角度来看，Web Gateway Appliance提供联合标准的联系点，联合标准是支持OAuth标准的授权框架，并提供对各种身份验证机制的支持。
IBM Tivoli联合身份管理器
IBM Tivoli Federated Identity Manager提供了一种松散耦合的模型，用于管理供应商，合作伙伴或安全域之间的身份中介。 它通过提供WS-Security和Federated SSO领域内的一系列开放标准来提供此解决方案。 以下部分概述了针对BYO-ID用例的Tivoli Federated Identity Manager的相关子组件。
用户自理能力
用户自理（USC）功能允许用户自我管理在线帐户。 USC提供了一种解决方案，可以轻松地在B2C环境中将用户帐户设置到帐户中，并随后允许帐户自助服务。
USC提供了一组操作，使用户可以管理自己的帐户生命周期。 表1显示了USC支持的操作。
表1. Tivoli Federated Identity Manager用户自助（USC）操作
| 用户自理操作 | 内容描述 |
|---|---|
| 用户注册 | 用户可以通过执行注册工作流程在Internet上建立帐户。 |
| 用户ID存在检查 | 在初始注册页面上，提供了一个按钮供用户单击以确定注册表中是否已存在在关联字段中输入的用户ID。 |
| 密码变更 | 可以由用户启动以执行密码更改操作，也可以由于密码过期而自动启动。 |
| 个人资料管理 | 允许客户管理特定于其帐户的扩展信息，例如地址或联系电话。 |
| 忘记用户名 | 恢复客户忘记的用户ID。 |
| 忘记密码 | 恢复客户忘记的密码。 |
| 帐号删除 | 停用或删除客户的Internet帐户。 |
要获取有关IBM Tivoli Federated Identity Manager用户自助功能的更多信息，请参阅参考资料 。 从BYO-ID的角度来看，Tivoli Federated Identity Manager USC可以提供注册功能，该功能使用户不仅可以将其身份信息纳入注册顺序，还可以设置用户名/密码以及机密问题和答案。 当客户想要执行更高价值的交易时，此类注册使企业还可以应用其他身份验证保证。
联合SSO支持
IBM Tivoli Federated Identity Manager提供对联合SSO的支持。 对于BYO-ID方案，联合SSO标准既用于B2C帐户的自举注册，也用于基于标准（和其他方法）的身份验证。 Tivoli Federated Identity Manager还支持各种开放标准，例如SAML（1.0、1.1和2.0），OpenID，OAuth和WS-Federation。 从BYO-ID的角度来看，Tivoli Federated Identity Manager联合SSO为从社交提供程序到企业的联合单点登录提供了基于标准的支持。
一次性密码认证服务
Tivoli Federated Identity Manager提供了一次性密码功能（OTP），可以通过配置来实现。 此功能利用了与USC和Federated SSO功能相同的集成框架，因此将在Tivoli Federated Identity Manager中管理和部署不同组件的技能成本降至最低。
常见的OTP集成模式已使用电子邮件，3G / 4G短消息服务和HMAC或基于软件的令牌（例如Google Authenticator）实现。 可以将Tivoli Federated Identity Manager解决方案配置为向认证事件分配不同的保证级别。 对于BYO-ID，可以为联合事件（如SAML 1.x）分配比密码或OTP更低的身份验证保证级别。
BYO-ID实施模式
如今，典型的Web用户拥有太多的在线帐户以及太多的用户名和密码组合来管理。 有时，需要为网站注册一个新帐户的想法可能被视为太多。 幸运的是，当今许多网站已经意识到这一点，并且正在Swift采取行动以采用BYO-ID模式。 此模式使客户可以使用流行的在线身份提供者提供的现有在线身份来进行身份验证，而几乎不需要注册过程就可以完成注册过程。
表2列出了一些流行的社交网络以及该社交网络提供商支持的开放标准。 我们将在本文后面探讨这些标准的BYO-ID解决方案。
表2.社交网络对开放标准的支持
| 社交网络 | 相关开放标准 |
|---|---|
| 脸书 | OAuth |
| 推特 | OAuth |
| 雅虎 | OpenID |
| 谷歌 | OpenID和OAuth |
| 领英 | OAuth |
在撰写本文时，列出的标准已得到记录的支持，但它们可能会发生变化，因此，请访问社交网络提供商的网站以获取最新的开放标准支持。
在本文的其余部分，我们将参考和讨论一些列出的社交媒体提供商，以帮助说明使用IBM Security产品的BYO-ID的实现模式。
使用社交身份验证
使用BYO-ID对网站进行身份验证会给客户和企业（或服务提供商）带来一系列好处：
- 通过允许消费者利用他们现有的来自Facebook或Twitter的在线身份来对网站进行身份验证，这导致用户需要记住或减少一个密码或一个帐户的使用。
- 对于服务提供商，BYO-ID消除了用户帐户设置流程和正在进行的密码管理操作，从而使帐户管理责任降至最低。 在企业希望减少注册开销的情况下，他们可以预先填写原本需要输入的信息。 这还允许企业捕获其他身份验证数据，例如问答和移动电话号码，以便服务提供商可以调用更高级别的身份验证。
使用IBM Security产品来实现BYO-ID认证模式将通过利用针对SSO和USC的同一联合身份管理产品来帮助企业减少工作量，时间和管理成本。
图1捕获了使用IBM Security产品的BYO-ID认证模式的高级工作流：
图1. BYO-ID身份验证工作流概述
图1中的Security Access Manager组件包含Web Gateway Appliance，一个用户注册表和Tivoli Federated Identity Manager。 提出的工作流程基于以下概念：允许客户使用来自选定身份提供商的现有帐户间接地对其目标网站（服务提供商）进行身份验证。 有效地，将身份验证过程委托给所选的身份提供者。
就用户而言，他们只知道使用其在线社交身份登录。因此，由选定的身份提供者颁发的凭据可让他们无缝地对目标企业网站进行身份验证。 从技术上更精明的用户会知道，在幕后，服务提供商内存在一些注册表，用于存储帐户信息（而不存储密码）； 此配置方面未在图1中显示 。
有许多开放标准可用于实现此解决方案模式。 我们将简要讨论可以使用的一些适当的开放标准配置文件。
带有SAML即时置备的联合SSO身份验证
安全断言标记语言（1.x / 2.x）支持即时配置，从而允许他们在首次登录服务提供商网站时即时创建新的常规客户帐户。 无需预先创建或预先设置用户帐户。 这减少了注册帐户的时间和精力，因为在用户首次登录时，帐户创建过程会自动进行。
使用SAML需要企业站点与在线身份提供者之间的明确信任。 SAML为消息签名的安全性提供了对XML签名和XML加密的强大支持。 通常，它需要在交换身份验证和授权数据的各方之间建立高度的信任或预先配置。 具有SAML即时置备的BYO-ID身份验证是通过BYO-ID使用SAML实现联合SSO的行为。 如果您有兴趣使用SAML即时供应来实施解决方案，请参考参考资料 ，找到说明如何使用IBM产品实现此目的的文章。
使用OpenID进行BYO-ID身份验证
OpenID是一种流行的开放标准，可用于对企业网站进行BYO-ID身份验证。 它允许客户使用其现有帐户对多个目标网站（回复方）进行身份验证，而无需为每个端点创建新密码。
它通过具有单个OpenID并能够通过该单个实体连接到不同的网站，从而提供了一种巩固客户的数字身份的方法。 OpenID的一个关键方面是，在依赖方和身份提供者之间不需要预先配置的信任关系。 为了实现BYO-ID身份验证，客户只需选择其首选的OpenID身份提供商，即可向企业网站进行身份验证。
- SAML被公认为是一种行业开放标准，可为身份和服务提供商之间的客户跨域身份验证和授权提供服务。
- 对于客户来说，OpenID可能被认为更方便，更灵活，因为它使客户可以选择已经拥有的身份并向支持该标准的Web环境进行身份验证。
在参考资料中 ，您将找到一篇文章，可以帮助您研究如何利用OpenID实施解决方案，作为使用IBM产品对企业网站进行身份验证的替代方法。
使用OAuth的联合单点登录
可以用于对企业网站进行社交网络身份验证的另一个著名的开放标准是OAuth。 这是一个开放的授权标准，其中用户可以委派给应用程序，访问其资源而无需与应用程序共享其凭据。 诸如Facebook之类的流行社交提供程序基于OAuth协议实施身份验证工作流。 在本文中，我们将重点更多地放在如何将OAuth标准用于自注册引导方案而不是社会身份验证。 但是，使用OAuth的社交身份验证遵循图1所示的模式。
引导注册社交
除了使用BYO-ID进行身份验证外，BYO-ID可以提供的另一个好处是一种机制，可以为客户快速跟踪企业网站的注册过程，而无需手动通过Web表单进行注册。
使用BYO-ID，企业网站客户可以选择通过使用其现有社交网络帐户引导身份信息来建立其新的企业网站帐户。 通过允许社交网站信息预先填写注册所需的字段属性，可以快速跟踪自注册过程。
有各种各样的开放标准提供了用于实现企业网站自注册的BYO-ID自举的机制。 选择使用哪种开放标准取决于您希望支持的企业和社交网络供应商。 在本文中，我们将详细介绍使用OAuth开放标准的自我注册模式。
图2展示了一个使用IBM Security产品与流行的OAuth在线身份提供商Facebook进行的自我注册工作流的示例。
图2.使用Facebook OAuth提供程序的Security Access Manager自注册
图2展示了用户Eric John Smith的自注册过程，该用户使用他的Facebook帐户发起在企业网站上进行注册的请求。 对于基于OAuth的BYO-ID自注册实现，有许多关键的IBM Security Systems组件已经为他们所熟悉：
- Tivoli Federated Identity Manager USC：基于产品的框架，企业可以通过该框架行使USC工作流进行客户帐户访问和供应管理流程。
- 安全访问管理器Web网关设备： Tivoli Federated Identity Manager与安全访问管理器Web网关设备（WebSEAL）组件集成，以提供企业对消费者交易的认证和授权。
- 社交登录应用程序：这是一个OAuth客户端Servlet应用程序，负责与OAuth提供程序（如Facebook）进行交互。 它可以被视为Facebook和企业网站之间的集成点，以提供适当的重定向以让客户进行身份验证。 拥有OAuth令牌的应用程序可用于制作授权的RESTful API，以从Facebook检索身份信息。
- 登陆servlet：负责将客户重定向到USC工作流的适当位置的servlet。 它也用于将从其在线身份帐户中提取的可用用户身份信息预先填写到注册表单中。
- Facebook OAuth Provider： Facebook OAuth Provider，负责为Social Login App提供范围内的访问权限，以访问将用于自我注册的一组受保护的客户身份属性。 客户成功登录后，将向社交登录应用授予访问令牌。
当客户使用社交网络凭据登录到企业网站时，BYO-ID自注册过程开始（此示例中的代表图标是Facebook，图3）：
图3. Eric使用Facebook登录
使用Facebook登录的初始请求将转发到Social Login App。 社交登录应用程序通过将客户的浏览器重定向到Facebook进行授权进行响应。 向客户Eric提供Facebook登录表单，在其中输入他的用户名和密码凭据。
步骤4和5设置了OAuth令牌，该令牌可让Social Login App从Facebook访问用户信息。 在此示例中，社交登录应用程序使用Facebook Graph API从Eric的Facebook帐户中检索用户数据信息。
其他OAuth提供程序（例如Twitter和LinkedIn）也有自己的REST API，它们也支持此实现模式。
清单1中的代码片段显示了Social Login App如何启动授权工作流程以及如何使用OAuth与Facebook进行令牌交换。
清单1. Social Login App如何启动授权工作流程以及如何使用OAuth和Facebook进行令牌交换
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String appid = "xxxxxxxx"; //Set with obtained Facebook App ID when registering application
String appsecret = "xxxxxxxxxx"; //Set with obtained App secret when registering application
String redirectURL = "https://your-enterprise-application/jct/unprotected/fblogin";
String email = null;
String code = request.getParameter("code");
if (code == null) {
// initiate authorization flow
String authorizeURLStr = "https://graph.facebook.com/oauth/authorize?client_id="
+ appid + "&redirect_uri=" + redirectURL + "&scope=email";
response.sendRedirect(authorizeURLStr);
} else {
// we have an authorization code - first swap it for an access token
String accessTokenURLStr = https://graph.facebook.com/oauth/access_token?client_id=
+ appid
+ "&redirect_uri="
+ redirectURL
+ "&client_secret=" + appsecret + "&code=" + code
AccessTokenRetriever atr = new AccessTokenRetriever(accessTokenURLStr);
String accessToken = atr.getAccessToken();令牌交换完成后，使用Facebook Graph API，社交登录应用程序使用交换的访问令牌从Eric的帐户获取个人资料信息。 清单2中的代码片段提供了有关如何实现此目的的示例。
清单2.使用交换的访问令牌从帐户中获取个人资料信息
//construct the URL for where to retrieve the user information from
String resourceURLStr = "https://graph.facebook.com/me?access_token="accessToken;
try {
/*
* Facebook will return a JSON string like:
* {"id":"1234567890","name":"Eric Smith","first_name":"John",
* "last_name":"Smith","link":"http:\/\/www.facebook.com\/Eric.smith",
* "gender":"male","email":"eric@smith.com","timezone":10,
* "locale":"en_US","verified":true,
* "updated_time":"2013-06-25T22:50:14+0000"}
*/
_jObject = new JSONObject(this.getResult(resourceURLStr));
//Using the JSON object, one can retrieve user information such as
//firstname, lastname and email address
} catch (JSONException e) {
throw new ServletException(e);
}如何创建一个Facebook的OAuth客户端应用程序，并使用Facebook的在一个安全访问管理器环境认证的技术例子中可以找到相关主题 。
收到返回的填充有用户属性的响应后，将对内部用户注册表进行检查，以确定该用户是否已注册。 由于找不到Eric的注册帐户，因此下一阶段是将Eric设置为可以准备注册的状态。
使用Security Access Manager和Tivoli Federated Identity Manager，为Eric保留预注册状态的一种方法是在Web Gateway Appliance中采用特殊的中间用户会话。 在此的示例中间安全访问管理器帐户称为SocialUser。 SocialUser是一个没有密码的帐户，但是Web Gateway Appliance会话仅在注册事件期间使用该帐户名创建。 这些会话充满了代表Eric及其社会属性的属性，从而可以有效地完成注册过程。 请务必注意，SocialUser会话没有任何访问网站内容的权限。 图2的步骤6显示了将SocialUser用作Eric的临时预注册状态。
图4显示了在Web Gateway Appliance中登录的SocialUser凭据。
图4.使用SocialUser作为客户的预注册状态
呈现的Security Access Manager凭据中要注意的关键方面是定义为SocialUser凭据的一部分的扩展属性集。 以social_jk_开头的所有属性均设置有从Eric的Facebook个人资料用户信息提供的值。 该凭据是由社交登录应用程序利用安全访问管理器的外部身份验证界面（EAI）功能创建的，方法是将用户名设置为SocialUser，并将属性设置为前面提到的那些。
然后将请求转发到着陆servlet。 来自凭据的一组用户属性（例如， social_jk_firstname=Eric, social_jk_surname=Smith ）作为安全访问管理器标记值发送到此着陆小服务程序。 Landing servlet简单地获取这些标头，并提供一个预填充了这些属性的USC注册表单。 图5给出了将标签值属性发送到Landing servlet的示例。
图5.使用特殊的Security Access Manager属性预先填写的自我注册表单
图6显示了生成的自我注册表单，该表单预先填充了Eric的Facebook帐户中的字段。 注意，此页面的POST目标是用于创建帐户操作的预配置Tivoli Federated Identity Manager USC端点。 因此，从这一步骤开始，核心产品功能将获得控制。
图6.生成的自我注册表单预先填充了Eric的Facebook帐户中的字段
该登记表已预先填充有可用属性，但不一定是所有属性。 此示例表明，从他的Facebook个人资料帐户中检索了Eric的名字和姓氏和电子邮件地址。 可以获取更多属性，尽管这取决于RESTful服务端点是否可用信息以及用户同意共享多少数据。 可能仍然需要用户编辑填充的字段，以更新注册表单中的其他必填字段，例如机密问题，地址等。
注意，在图6所示的Web表单上，有一个用于输入新密码并确认密码的输入字段。 此密码字段用于强制客户注册其企业帐户，以便可以在企业网站上使用此备用身份验证机制。 通常，这是完成企业注册所必需的，并且在此示例中，如果要将注册表单提交给Tivoli Federated Identity Manager，则这是强制性的。
在提供了必填字段之后，用户可以继续提交注册表单（ 图2中的步骤9）。 Tivoli Federated Identity Manager接收提交的注册请求。 最后，它将向用户发送带有帐户验证URL的电子邮件。 Eric在浏览器中打开此URL后，这将完成验证过程。
完成此BYO-ID自注册后，Eric拥有企业网站的注册帐户。 现在已经注册了一个帐户，Eric可以使用其用户名作为电子邮件地址来认证企业网站。 由于Eric已使用企业站点BYO-ID用户自助注册向Tivoli Federated Identity Manager注册，因此Eric将具有两种认证机制：
- 一个是使用他的Facebook社交帐户
- 一种是使用他的企业用户名和密码
鉴于Tivoli Federated Identity Manager USC收集了用户的电子邮件地址和移动电话号码，企业还可以选择通过利用Tivoli Federated Identity Manager OTP进行高风险交易（例如，密码更改或高价值交易）来扩展其受支持的认证方案。 ）。
现在，图7说明了使用Eric的Facebook帐户的高级身份验证工作流。
图7.自我注册后使用Facebook OAuth提供程序进行身份验证
类似于图2中所示的工作流程，Eric使用企业网站的身份验证表单来发起身份验证请求。 社交登录应用程序通过将用户重定向到适当的在线身份提供者（在这种情况下为Facebook）进行响应。 从Facebook返回的带有授权码的响应是从社交登录应用程序收到的（ 图 4，步骤4），这导致进一步的访问令牌交换，以便社交登录应用程序可以访问用户的个人资料信息（步骤5）。
With the user profile information retrieved from Facebook, a registry check is performed to determine that Eric does have a registered account. The Social Login service creates the Security Access Manager user session for Eric (because it's configured as an external authentication interface). In addition, Eric's authentication mechanism reflects that of a social login. Figure 8 shows an example of Eric's Security Access Manager authenticated session credential using a social login.
Figure 8. Security Access Manager authenticated session using social login
Alternatively, Eric may choose to authenticate using his enterprise username and password credentials specified at registration time. This authentication is processed using standard IBM Security Access Manager Web Gateway Appliance capabilities. Figure 9 shows Eric's Security Access Manager authenticated session credential using his enterprise username and password credentials.
Figure 9. Security Access Manager authenticated session using enterprise login
Notice in Figure 9 that Eric's authentication level is higher than when he was employing his social login. In this example, the enterprise account is considered to be a higher trusted authentication mechanism than the social login.
The example above shows that Tivoli Federated Identity Manager USC can be used to complete a registration process for Enterprise scenarios. It takes advantage of social site integration by simplifying the registration process, while allowing registration of data that lets other authentication mechanisms be configured.
Risk in using BYO-ID
Adopting BYO-ID is convenient and flexible for users. However, it does come with certain risks. Using BYO-ID relies on the online provider to be highly available for authenticate delegation to grant access to the enterprise. Should the identity provider, for some reason, become unavailable this will lead to a single-point of failure.
Another major issue occurs should the online identity become compromised. The user may need to undergo certain measures to recover and reestablish their identity on enterprise websites where they have used BYO-ID. The potential time, cost, and effort to rectify the situation and rebuild a new identity can be high for both users and the enterprise.
结论
Regardless of the risks, BYO-ID is a growing consumer demand. Customers have become accustomed to the concept of using social credentials to register and authenticate to online services. The questions for enterprises now is one of security (how much access should be granted to these users) and policy implementation (which authentication and registration implementation suits the requirements, levels of access, and the users).
IBM Security Systems products provide a framework for applying standard deployment patterns across complex and evolving access management patterns. In this article, you have seen that BYO-ID use case aspects range from consideration of user registration processes and authentication considerations, as well as an ever-evolving set of open standards. In this article, we've provided a set of integration patterns that leverage the IBM Security Systems products to successfully implement a set of the customer requirements. It is a challenge for any access management product to handle such a large array of open standards, and to evolve and adapt as these standards mature, and IBM Security Access Manager has been successful in fulfilling this need.
翻译自: https://www.ibm.com/developerworks/security/library/se-selfarticle/index.html
mongodb启用身份验证
7022
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
