砥砺奋进谱新篇,且看旧貌换新颜。欢迎访问新的 IBM Developer 中文网站! 了解详情

通过忠诚度移动应用的后端来关注数据隐私

摘要

本 Code Pattern 展示了如何通过 Red Hat® OpenShift® on IBM Cloud™ 中的示例在 OpenShift 4.3 中部署基于微服务的后端。为了模拟一系列的移动视图,这些示例展示了如何部署基于 Node.js 的服务。

概览

随着人们逐渐意识到数据的重要性并关注其在线隐私,世界各地的法规已经开始要求软件项目思考如何处理客户数据。此 Code Pattern 会部署一组微服务作为忠诚度移动应用程序的后端,例如,希望通过收集数据来更好地了解用户如何使用其服务的企业经常使用的微服务。尽管受到诸如 GDPR(欧洲通用数据保护条例)等法规的启发,但由于这不是一个真正面向公众的应用程序,因此我们只实现了几个数据隐私功能,目的在于演示如何在 OpenShift 4 中构建以隐私为中心的后端。

GDPR 标准围绕用户(“主体”)需要使用的操作来定义需求。但是,GDPR 与技术无关,因此最终要由实现者负责构建可满足需求的架构。

流程

下图显示了用于用户认证的架构流程。

货币兑换微服务架构流程图

  1. 用户使用移动应用程序模拟器创建一个帐户。这需要使用 nodejs 服务器中的一个 API。随后,nodejs 服务器使用 App ID 服务中的一个 API,在用户自己的云目录中创建用户帐户。
  2. 移动应用程序模拟器在创建帐户后让该用户登录。然后,AppID 服务为该用户创建有效的访问令牌和 id 令牌。移动应用程序会存储这些令牌,以供以后在认证时使用。
  3. 使用上一步中的访问令牌,移动应用程序现在可以成功地调用 Liberty 微服务中受保护的 API。移动应用程序使用 Authorization 标头中的访问令牌来调用 API,以在数据库中创建用户概要文件。
  4. Liberty 服务已与 App ID 实例集成。这将验证来自请求的 Authorization 标头中的访问令牌。
  5. 如果该令牌有效,那么将在数据库中创建用户概要文件。访问令牌包含发送请求的用户的用户 ID。

包含 App ID 的 Auth 令牌流是身份提供程序,Liberty 使用该令牌对用户进行认证。

Liberty 微服务是需要 Authorization 标头的受保护 API。如果请求不含该标头,那么不允许处理该请求,因此会发送响应 401“未经授权”。微服务使用托管的身份提供程序(即 App ID)来进行此认证。这样便可以更轻松地保护 API 和管理用户身份信息。

移动应用程序模拟器已与 App ID 实例集成,每当用户登录时,应用程序都会收到访问令牌,并存储访问令牌以供以后在请求中用于受保护的 API。默认情况下,这类令牌会在一小时内到期,而在到期后需要再次对用户进行认证。

每当发送在 Authorization 标头中包含令牌的请求时,Liberty 微服务都会使用 App ID 集成来确保令牌有效。然后继续处理请求。Liberty 微服务还使用令牌中的主体 ID 或用户 ID 来识别发出请求的用户。例如,当用户询问其获得的积分数时,需要从数据库中提取适当的概要文件。此时便可以利用令牌有效负载中的用户 ID。

操作说明

参阅 GitHub 代码存储库中的 README.md 文件中的详细技术步骤来试用本 Code Pattern。

  1. 设置 OpenShift 4.3 集群。
  2. 设置 App Id 实例。
  3. 部署 PostgreSQL 实例和模式。
  4. 创建微服务使用的 Kubernetes 密钥。
  5. 部署其余的服务。

本文翻译自:Focus on data privacy with a back end for a mobile loyalty app(2020-04-24)