前阵子我在梳理一条典型的联邦访问链路，本地 SAP HANA 负责建模和发起查询，远端 SAP HANA 负责提供真实数据。表面上看，大家最关心的是 remote source 该怎么建，virtual table 该怎么用。可一旦要把共享技术用户换成按人传递身份的访问方式，真正难啃的地方就落到了 JWT SSO 这块。这里牵涉的不是单独一条 SQL，而是一整套信任关系，本地库负责签发 token，远端库负责验证 token，再把 token 里的外部身份映射到远端数据库用户，最后才谈得上授权检查。SAP 官方对这套机制的描述非常清楚，JWT 在 SAP HANA 里本来就是一个标准的单点登录能力，外部身份映射到内部数据库用户之后，真正参与权限判断的仍然是远端的数据库用户。
如果把这条链路拆开看，参与者其实只有四个。本地 SAP HANA，远端 SAP HANA，本地保存私钥和证书的 PSE，以及远端用来验证签名的 PSE。很多项目一上来就急着写CREATE REMOTE SOURCE，结果后面发现远端根本不认本地签出来的 JWT，或者认得 token 却找不到用户映射，最后看到的就是一连串认证失败。原因很简单，JWT 不是凭空可信的，远端必须先信任本地的签名证书，还要知道 token 里的哪一个字段应该拿来对应远端用户的 external identity。SAP 的安全文档也反复强调，JWT 认证里真正用于授权的，是那个已经在 SAP HANA 中存在并完成映射的内部数据库用户。
把这件事讲得更接地气一点，我今天最常见到的企业场景，是总部分析库通过 Smart Data Access 去查工厂侧或者区域侧的 SAP HANA。业务部门不想再用一个 everyone 都共用的远端技术账号，因为一旦出了审计问
