在一个真实的 SAP Fiori 项目里，权限设计经常会碰到一种很微妙的情况。一个 OData 服务背后的业务实现可能复用了已有的 ABAP 业务逻辑，而这些业务逻辑内部已经存在多个AUTHORITY-CHECK。从代码复用角度看，这完全合理，但从最终用户的业务职责来看，却可能产生一个很棘手的问题。某个 Fiori 应用实际上只需要其中一部分业务能力，可调用链上的 ABAP 程序却顺带检查了其他授权对象。为了让应用正常运行，权限管理员不得不给最终用户的 PFCG Role 增加这些授权。结果就是，用户虽然只是为了运行当前 OData 服务，却可能因此获得与其他业务功能相关的权限。SAP Gateway Foundation 提供的 Trusted Context，正是为这一类场景准备的。这里的 Trusted Context 不能理解成整个服务不再需要权限，也不能理解成 Gateway 从此信任所有来自客户端的请求。它处理的是一个更加精细的问题，在某个确定的应用上下文中，允许开发人员或者权限设计人员明确告诉 ABAP 授权框架，某一个特定的授权对象在当前应用入口下不需要执行检查。这个能力和SU24的 Check Indicator 紧密相关。从 ABAP 运行机制来看，很多开发人员第一次接触 Trusted Context 时，容易把它理解成 Gateway Runtime 自己实现了一套绕过AUTHORITY-CHECK的特殊代码。实际情况并不是这样。ABAP 自身的授权运行机制本来就支持根据当前应用上下文决定某个AUTHORITY-CHECK