Secure Your Application on SAP Cloud Platform Cloud Foundry
本文概要
- 如何设置和配置 App Router 组件作为微服务环境的地方入口点来解决身份验证和受权
- 如何爱护您的 Java 微服务,使其仅承受基于从利用路由器收到的无效 JSON Web 令牌 (JWT) 的申请
- 为您的应用程序用户调配角色和范畴,并让您的后端解决受权信息
基本概念
在深刻理解架构的理论设置之前,让咱们疾速回顾一下本教程打算采纳的架构。
下图是 SAP Business Technology Platform 上运行时的用户认证流。首先咱们曾经有一个创立好并且失常工作的 Java 微服务。然而,您将应用所谓的利用路由器(App Router),而不是让客户间接拜访这个应用程序,它有两个目标。
一方面,App Router 是进入微服务世界的通用入口点。次要思维是您能够将应用程序拆分为多个具备独立可部署性、多语言运行时和持久性以及独立团队的微服务。因而,须要一个地方入口组件来向最终客户暗藏微服务环境的复杂性。
另一方面,App Router 次要负责管理认证流程。利用路由器接管来自用户的未经身份验证的传入申请,并应用用户帐户和身份验证扩大服务 (XSUAA) 启动 OAuth2 流。 XSUAA 服务是 CloudFoundry 的 UAA 服务的 SAP 特定扩大,用于解决身份验证和受权(它可能再次将此方面委托给其余提供者,例如内部身份提供者)。如果用户在 XSUAA 进行身份验证,它将应用蕴含通过身份验证的用户以及他或她已被授予的所有范畴的 JSON Web 令牌 (JWT) 进行响应。
JWT 由利用路由器传递给底层微服务,以便它们从这个工作中解放出来。 同时,这些微服务只能通过无效的 JWT 拜访,因而能够避免未经身份验证的流量。
JWT 蕴含一个签名,每个微服务都须要验证该签名能力建设信赖。 因而,每个服务都须要一个密钥(客户端秘密或公钥)来验证此签名并回绝任何带有有效 JWT 的申请。 因而,每个服务都必须保护与 XSUAA 的服务绑定,该服务绑定为运行时验证提供此信息, 如下图。 为了实现这一点,每个微服务都绑定到一个专用的 XSUAA 实例,该实例将此信息写入 VCAP_SERVICES 环境变量中,微服务能够应用该变量来验证任何令牌的有效性。
Set up the App Router
您将让 Cloud Foundry 在部署时自动检索利用路由器。 为此,您将首先设置必要的构造。
在我的项目文件夹上面新建一个 approuter 文件夹,进入该文件夹。
新建一个 package.json 文件:
{ "name": "approuter", "dependencies": { "@sap/approuter": "*" }, "scripts": { "start": "node node_modules/@sap/approuter/approuter.js" }}
在 approuter 文件夹内,新建一个 xs-app.json:
{ "welcomeFile": "index.html", "routes": [{ "source": "/", "target": "/", "destination": "app-destination" }]}
在我的项目根目录下,新建 manifest.yml:
---applications:- name: approuter routes: - route: approuter-<subdomain>.cfapps.<region_id>.hana.ondemand.com path: approuter memory: 128M buildpacks: - nodejs_buildpack env: TENANT_HOST_PATTERN: 'approuter-(.*).cfapps.<region_id>.hana.ondemand.com' destinations: '[{"name":"app-destination", "url" :"<APPLICATION_URL>", "forwardAuthToken": true}]' services: - my-xsuaa
将上述文件里的占位符,subdomain 替换成理论值。
通过返回子账户的概览页面,您将在 CF 主控室中找到您的子域:
Understanding the AppRouter’s manifest.yml
在 Cloud Foundry 上,每个子帐户都被调配了一个与一个租户相关联的子域。在多租户场景中,利用路由器须要晓得将哪个租户(tenant)转发到 XSUAA 服务。这是通过在主机(host)中蕴含子域来实现的,利用路由器将从中提取它。这就是 TENANT_HOST_PATTERN 发挥作用的中央。它是一个变量,用于申明如何辨认和解决 URL 中的租户的模式。咱们心愿主机合乎 approuter-<subdomain>。如果您须要不同的 URL 模式,则须要相应地更改路由和 TENANT_HOST_PATTERN。
请留神,TENANT_HOST_PATTERN 变量仅在真正的多租户应用程序中才须要,即物理部署为同一部署中的多个客户端提供服务的应用程序。假如您要构建多租户应用程序,因为它的指标是云原生开发。然而,如果您有单租户应用程序,则不须要此变量。为了实现这一点,xs-security.json 平安描述符能够申明 "tenant-mode": "dedicated"(参见上面的步骤 5)。
转到目的地条目。它是一个变量,用于申明从利用路由器到底层后端微服务的外部路由。因为您只有一个微服务,因而您能够在这里只定义一个名为 app-destination 的目的地。此 app-destination 由先前创立的 xs-app.json 文件援用。
最初但并非最不重要的服务局部申明将您本人的 XSUAA 服务实例绑定到利用路由器。此绑定将确保相应的 VCAP_SERVICES 条目蕴含验证来自 XSUAA 服务的任何传入 OAuth 令牌/JWT 所需的客户端 ID、客户端密钥和公钥:
Bind the XSUAA Service
当初您须要创立一个到 XSUAA 服务的服务绑定。 作为先决条件,您须要一个 xs-security.json(平安描述符)文件,其中蕴含无关您打算在应用程序中应用的受权范畴的申明。 例如,只需申明一个 DISPLAY 范畴,稍后将用于受权您的用户。 此外,还申明了一个名为 Viewer 的角色模板,它援用了咱们的 DISPLAY 范畴。
将此文件放入 <destLocation>/xs-security.json。能够在此处找到无关 xs-security.json 语法的更多详细信息。
xs-security.json:
{ "xsappname": "firstapp-<subdomain>", "tenant-mode": "shared", "scopes": [ { "name": "$XSAPPNAME.Display", "description": "display" } ], "role-templates": [ { "name": "Viewer", "description": "Required to view things in our solution", "scope-references" : [ "$XSAPPNAME.Display" ] } ]}
应用命令行创立一个新的 xsuaa 服务实例:
cf create-service xsuaa application my-xsuaa -c xs-security.json
应用 cf push 将 approuter 部署到 SAP BTP CloudFoundry 环境。
之后,您应该可能应用部署的主机名从浏览器中找到利用路由器。 在我的状况下,这是 https://approuter-p1942765239... ,您应该看到以下登录页面,您能够在其中应用您的用户电子邮件和明码:
输出用户名和明码之后,就看到了 hello world 这个 Java 微服务的输入:
更多Jerry的原创文章,尽在:"汪子熙":