如何在 MobileFirst 8 中实现服务器会话验证场景？

Posted 2023-02-25

【中文标题】如何在 MobileFirst 8 中实现服务器会话验证场景？

【英文标题】：How to implement server session validation scenario in MobileFirst 8?

【发布时间】：2016-08-24 14:27:49

【问题描述】：

我对以下使用 MobileFirst HTTP javascript 适配器的场景有疑问：

假设适配器调用 2 个方法，

login，调用后端服务对用户进行身份验证并返回 customer_id（输入：用户名和密码）。 retrieveData（受安全检查保护）通过调用后端服务检索有关客户的敏感数据（输入：customer_id）。

我们如何确保某些具有身份验证凭据并有权访问retrieveData 的客户端将仅请求与他有关的数据，并且无法发送与他自己的customer_id 不同的retrieveData 请求？ （我们假设这个客户端已经对应用程序进行了调整，并使其发送了不同的 customer_id。）

使用 MobileFirst 7，登录成功后，我们会调用 setActiveUser 将返回的 customer_id 设置为活动用户的属性，或者我们会调用 WL.Server.getClientRequest().getSession().setAttribute 并再次设置 customer_id。因此，当用户调用retrieveData 时，我们将获取他的customer_id 输入并将其与他会话中的customer_id 进行比较。如果它不同，那么他们会收到错误，因为他们请求的数据不属于他们。

由于 MobileFirst 8 没有会话，我们如何防止这种情况发生？

【问题讨论】：

用户名和客户ID有什么关系？这种关系是如何存储的？

客户使用用户名和密码登录，登录后端程序返回一个唯一的 customerId（每个客户都有一个，在注册时创建，永不更改）。出于安全原因，此 customerId 永远不会到达客户端应用程序。

您的意思是他们每次登录时都会获得不同的客户 ID？还是您将其存储在一些持久性存储中，例如数据库？我的意思是，您的“retrieveData”使用客户 ID 作为其输入，它如何知道使用此 ID 检索哪些数据？

不，正如我在上面的评论中所说，customerId 永远不会改变。它在客户注册期间创建一次，并存储在数据库中。 （登录后端服务在验证客户凭据后从数据库中检索它）。所以每个客户都有一个customerId。这就是retrieveData 知道要返回谁的客户数据的方式。

那么在retrieveData 中你不能检查customerid 是否与你数据库中的用户名匹配吗？

【参考方案1】：

在 8.0 中，“客户端注册数据”是最接近会话的内容。

关于您的用例有很多未知数，但我将尝试描述大多数情况下的预期行为：

假设您的安全检查扩展UserAuthenticationSecurityCheck，一旦用户成功登录，他的用户ID将被注册在服务器上的客户端注册数据中。这会将客户端映射到数据库中的用户。

从那时起，在任何适配器上，您都可以使用 securityContext.getAuthenticatedUser() 安全地检查谁是当前登录的用户。

如果您想确保客户端只访问允许访问的数据，请使用此getAuthenticatedUser 来检查您的数据库是否属于它所请求的数据。

如果您确实需要在注册上下文（最接近会话对象）中存储额外的自定义数据，安全检查中有 API 可以执行此操作。见RegistrationContext。

【讨论】：

我还在您发送给我的页面中看到上面的 void setActiveUser(AuthenticatedUser user) 仍然存在？不是停产了吗？如果不是，那也可以工作..

安全检查中仍然存在是的。但是如果你实现了UserAuthenticationSecurityCheck，就像我上面提到和链接的那样，这部分会自动为你完成。我强烈推荐使用UserAuthenticationSecurityCheck。

会试一试。非常感谢@Nathan

【参考方案2】：

在 v8.0 中，客户端能够从后端系统检索信息，因为它传递了提供给它的质询，并作为回报收到一个访问令牌，使其能够访问受范围保护的资源，您定义。这就是 OAuth 或多或少的工作方式。

您是否阅读过身份验证概念教程？ https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/

【讨论】：

是的，我有。我的场景是关于一个恶意用户，他已经拥有密码和用户名（因此他通过了挑战），但将经过调整的 customerId 发送到受保护的过程并检索另一个客户的数据。为了阻止这种情况，我们将使用服务器会话。我们现在怎样才能阻止这种情况？