基于Cognito/ELB的AD组静态站授权方案咨询（无应用侧改动）

完全可以在不修改任何静态应用代码、不调整EC2上Apache服务配置的前提下落地需求，你现有ELB+Cognito的认证链路已经原生支持相关能力，复杂场景也可以结合Lambda灵活扩展，具体方案按实现成本从低到高列在下面：

零代码方案（优先推荐，适配绝大多数简单规则场景） #

你现在用的ALB authenticate-cognito动作本身就自带基于用户属性的组访问控制能力，不需要额外开发：

• 第一步先打通AD组到Cognito的属性映射
  • 进入Cognito用户池的SAML身份提供商配置页，编辑属性映射规则：把Azure AD SAML断言中返回的groups声明，映射到Cognito的自定义用户属性（比如新建custom:ad_groups多值字符串属性），确保用户登录时所属AD组列表会自动同步到Cognito。
  • 编辑Cognito对应应用客户端的配置，允许ID Token中携带custom:ad_groups属性，保证ALB完成认证后能拿到用户的组信息。
• 第二步拆分ALB监听器规则配置权限
  • 把原来统一转发到后端Apache的监听器规则按路径拆分：
    • 公开无权限的路径（比如/*下的静态公共资源）保持原有配置，直接转发到后端目标组即可
    • 针对需要权限控制的路径（比如/admin/*），单独创建优先级更高的监听器规则，认证动作选择Authenticate using Amazon Cognito，展开高级配置：
      • 组属性字段填你之前映射的custom:ad_groups
      • 允许的用户组列表填对应路径授权的组名，比如/admin/*就只填admin
  • 配置完成后ALB会在认证环节自动完成组校验：用户登录后如果所属AD组不在当前路径的允许列表里，ALB会直接返回403 Forbidden响应，根本不会把请求转发到后端Apache，完全不需要应用侧做任何适配。

灵活扩展方案（适配复杂权限规则场景） #

如果你的权限规则比较复杂（比如同个路径允许多个组访问、需要做临时权限加白、路径匹配逻辑复杂），可以在零代码方案的基础上结合Lambda实现更灵活的控制，同样不需要改应用：

• 保留之前的AD组到Cognito属性映射配置，确保ALB透传的JWT里带用户组信息
• 编写轻量Lambda函数，核心逻辑只有四步：
  1. 接收ALB转发的请求，从请求头中取出ALB透传的认证JWT（x-amzn-oidc-data头），用ALB公开的JWKS公钥验证JWT签名有效性，防止伪造请求
  2. 从验证通过的JWT payload中提取用户所属AD组列表
  3. 按你需要的规则匹配请求路径和用户组权限，支持正则匹配路径、多组权限判断、特殊用户白名单等任意逻辑
  4. 权限校验通过就返回ALB要求的固定响应格式，让ALB把请求转发给后端Apache；校验不通过直接返回403响应
• 调整ALB监听器规则：需要做复杂权限控制的路径，先转发到这个Lambda授权函数做判定，判定通过再转发到后端目标组即可。
• 如果你的ALB前置了CloudFront，也可以把这段逻辑部署成Lambda@Edge，绑定CloudFront的Viewer Request事件，在边缘节点直接完成鉴权，延迟更低。

落地注意事项 #

• 所有鉴权逻辑都在ALB/边缘层执行，后端Apache接收到的全是已经通过认证、权限校验的合法请求，不需要做任何代码或配置修改
• 不管用哪种方案，都不要跳过JWT签名校验步骤，避免攻击者伪造身份头绕过权限控制
• 用Lambda方案时可以把权限规则存在Lambda环境变量里，后续新增路径授权规则直接改环境变量即可，不需要调整代码

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