27.GTMS&ITMS与gateway的关系

## 1.应用系统与GTMS&GTMS-I系统的数据流向
![](/media/202409/2024-09-21_095046_468109.png)
## 2.GTMS&GTMS-I系统与应用系统的数据流向
![](/media/202409/2024-09-21_095240_520623.png)
### 2.1 网关认证
由于GTMS系统是SAAS系统，不具备满足网关验签的条件，但是铁骑要求所有请求网关的系统都必须要满足验签，因此网关可以给GTMS系统开简单的验签(Basic Auth)，GTMS不需要开发，只需要在header中传参就行。
![](/media/202409/2024-09-21_102257_998973.png)
如上图所示，按照正常来说，只需要GTMS在header中传入 SSystem=GTMSI，就可以走Basic Auth插件，但是GTMS系统不支持在header中自定义参数，因此，我们想了个折中的方案，在请求路径上带上SSystem=GTMSI，那么这样的话，网关的认证插件要配置成如下这样
![](/media/202409/2024-09-21_102722_659022.png)
一旦过了这个认证，那就会跳过网关原本的Sign认证。
### 2.2 目标系统认证
![](/media/202409/2024-09-21_110717_726698.png)
### 2.3 目标系统转发
![](/media/202409/2024-09-21_111042_491544.png)
### 2.4 总结
如上一套流程按照正常来说，没得问题的，前提是GTMS系统的query参数中传了SSystem与DSystem。
且SSystem起到了网关验签的作用，DSystem起到了匹配目标系统的作用。那如果GTMS系统不传System呢？那它是不是可以路过 Basic Auth认证，直接访问进来了？
## 3.反思
由如上2.4小结，我们很容易联想到GTMS系统不传SSystem时，请求依然可以进来的，而且还略过了验签，那如何堵住这个漏洞呢？
思路：既然路过了网关特定的认证，那么就得走网关默认的认证，详见如下图
![](/media/202409/2024-09-21_111724_417402.png)
即在默认认证的目标系统这里加上Query参数，这样就可以堵住这个漏洞。
接着我们延续2.4的总结，既然SSystem起到了认证，DSystem起到了转发，那是不是说明只要前面的认证通过了，就可以访问目标系统所有的接口，因为SSystem的basic账号/密码并未与被访问的资源挂钩。这又是一个漏洞，如何堵住呢？
思路1：在网关中开发新功能，分配的Basic账号/密码与可访问的资源关联。弊端是需要开发工作。能不能仅仅在配置层面解决这个问题呢？
思路2：不改变原有在header中传输SSystem与DSystem的逻辑，我们新增一套在Query中传输SSystem与DSystem的逻辑，两套逻辑互补干扰；header中本身就支持访问资源控制，我们只需要在Query中做好控制就得行。
这里假设SSystem=GTMS；DSystem=EMS。
### 3.1 网关认证
1>走Basic Auth，配置如下
![](/media/202409/2024-09-21_113031_224519.png)
rule中控制GTMSI可以访问哪些系统的哪些资源
![](/media/202409/2024-09-21_113135_102822.png)
2>走Sign插件认证，配置如下
![](/media/202409/2024-09-21_113318_509329.png)
很明显GTMS系统的Query中必须传DSystem。如果没有传SSystem，那么就会进入到这里，走Sign验签，很明显通不过。
自此，验签问题解决了，且SSystem可以访问哪些资源也控制了。
### 3.2 目标系统认证
只需要Query中的DSystem满足就行
![](/media/202409/2024-09-21_114153_940918.png)
### 3.3 目标系统转发
只需要Query中的DSystem满足就行
![](/media/202409/2024-09-21_114349_331176.png)
### 3.4 结束
自此，解决了GTMS通过网关访问其他系统的安全问题。