启用IAM数据库授权的Neptune执行ES集成全文检索查询报错

你遇到的签名不匹配报错，本质是生成SigV4签名时用到的请求要素，和最终实际发出去的请求要素不一致。
已知连通性检查接口能靠同一套SigV4签名正常访问，说明你使用的AK/SK权限基础是正常的，SigV4签名算法的基础逻辑也没有错；而禁用IAM授权时同样的ES查询能正常执行，是因为关闭IAM授权后Neptune不会对请求做签名校验，只要网络通路正常就允许响应。问题只出在ES全文检索类请求的签名计算环节，没有覆盖这类请求的全部特征，开启严格IAM校验后就会被直接拦截。 #

• 第一优先级：对齐签名计算使用的路径、查询参数
  SigV4签名的校验规则要求：请求路径、所有URL查询参数（包括参数大小写、编码格式、排列顺序）必须100%纳入签名计算的范围。
  常见踩坑点：签名生成时复用了连通性检查的简化逻辑，只用/status这类固定无参数的路径计算签名；但实际ES全文检索请求走的是带业务参数的接口，往往是在签名生成完成之后，才给URL拼上ES检索相关的query参数（比如?searchBackend=es、?q=检索关键词），这部分参数完全没纳入签名计算，两边算出的规范请求串必然不匹配。另外如果请求经过网关、代理转发后路径被重写，和签名时使用的原始路径不一致，也会触发校验失败。
• 第二优先级：对齐签名计算使用的请求头范围
  所有参与请求的HTTP头（包括Host、Content-Type、X-Amz-Date、自定义业务头）必须一字不差的纳入签名计算的“待签名头列表”。
  常见踩坑点：连通性检查是无自定义头的GET请求，签名时只算了Host、X-Amz-Date两个核心头；但ES全文检索请求一般会带Content-Type: application/json这类头，如果签名时没把这个头加进待签名列表，校验直接不通过。此外部分HTTP客户端会自动追加默认请求头（比如自动加Accept-Encoding: gzip），这类自动追加的头如果没有纳入签名计算，也会导致签名不匹配。还要注意Host头的一致性：如果请求经过端口映射、域名转发，实际请求带的Host值（比如端口号从8182变成443）和签名时填写的Host值不一致，哪怕域名一样，也会触发校验失败。
• 第三优先级：对齐请求体的哈希计算
  连通性检查类接口一般是无请求体的GET请求，签名时对请求体的校验比较宽松；但ES全文检索请求多为带JSON查询体的POST请求，如果你是先生成空请求体的签名，之后再把ES检索的查询内容填充到请求体里，没有把最终的请求体哈希值算进SigV4签名的计算流程，AWS侧拿到请求后会重新计算请求体哈希，和你提交的签名里的哈希值比对不一致，就会直接抛签名不匹配的AccessDenied错误。
• 第四优先级：核对签名的服务维度、区域信息
  Neptune启用IAM授权后，所有接口（包括对接ES的全文检索接口、连通性检查接口）的签名服务维度必须统一使用neptune-db，不能混用其他服务名；同时签名使用的AWS区域必须和Neptune集群实际部署的区域完全一致，错填区域也会触发校验失败。

快速定位方法：你可以把最终要发出去的完整请求（包括全量URL、所有query参数、所有实际携带的请求头、完整请求体）一字不差的提取出来，基于这份完整的请求信息重新生成一次SigV4签名，替换原请求头里的签名信息后再发送。如果这样操作后请求能正常执行，就说明你之前的签名流程是在请求还没完全组装完成时就提前生成了签名，后续追加的请求要素没有纳入计算范围，逐一对齐即可。

内容的提问来源于stack exchange，提问作者santosh nahak