Conversation
github-actions
bot
added
the
📚 documentation
There was a problem hiding this comment.
Pull request overview
Updates the Fusion v16 “Authentication and Authorization” documentation to focus on gateway-side authentication and header propagation, while delegating subgraph authorization guidance to framework-specific documentation.
Changes:
- Reframes the page to emphasize gateway authentication, header propagation, and gateway-to-subgraph trust.
- Replaces detailed HotChocolate subgraph authorization examples with a brief “Subgraph Authorization” section linking to HotChocolate docs.
- Removes the “Known Issues” section and simplifies “Next Steps”.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 3. **JWT authentication.** Standard ASP.NET Core JWT Bearer setup. Configure `Authority` and `Audience` for your identity provider (Keycloak, Auth0, Azure AD, etc.). | ||
| 4. **Authorization.** Registers the authorization services. | ||
| 5. **Fusion gateway.** Registers the gateway with its configuration source. | ||
| 6. **Middleware order.** `UseHeaderPropagation()` must come before `UseAuthentication()` so that the `Authorization` header is captured for propagation before the auth middleware consumes it. Then `UseAuthentication()` must come before `UseAuthorization()`. | ||
|
|
There was a problem hiding this comment.
The middleware-order guidance here is internally inconsistent with the later “Custom Header Injection” example that derives propagated headers from HttpContext.User (which is populated by UseAuthentication()). Authentication middleware does not consume/remove the Authorization header, so UseHeaderPropagation() does not need to run before UseAuthentication() to forward it; if anything, when propagating derived headers from claims it should run after authentication (and before MapGraphQL()). Please adjust the wording (and/or the pipeline snippet) to reflect the correct ordering rationale.
| By default, ASP.NET Core does not require authentication unless you configure a fallback policy. If you want some queries to be accessible without a token (while still validating tokens when present), do not set a restrictive fallback: | ||
|
|
||
| ```csharp | ||
| builder.Services.AddAuthorization(options => | ||
| { | ||
| options.FallbackPolicy = null; // Allow anonymous by default | ||
| }); |
There was a problem hiding this comment.
The main JWT setup snippet already calls builder.Services.AddAuthorization(); and this section later shows builder.Services.AddAuthorization(options => ...). If readers copy/paste both, they’ll register authorization twice. Consider folding the fallback-policy configuration into the primary setup snippet (or explicitly framing this snippet as a replacement for the earlier AddAuthorization() call) to avoid confusion.
| - **"Something is broken"** -- Check the middleware order section above and ensure `UseHeaderPropagation()` appears before `UseAuthentication()` in the pipeline. | ||
| - **"I need to set up subgraph authorization."** The [HotChocolate Authorization docs](/docs/hotchocolate/v16/securing-your-api/authorization) cover field-level authorization, policies, and claims-based access control for HotChocolate subgraphs. | ||
| - **"I need to deploy this securely."** [Deployment & CI/CD](/docs/fusion/v16/deployment-and-ci-cd) covers production deployment patterns including network isolation and CI pipeline setup. | ||
| - **"Something is broken."** Check the middleware order section above and ensure `UseHeaderPropagation()` appears before `UseAuthentication()` in the pipeline. |
There was a problem hiding this comment.
This “Something is broken” troubleshooting bullet repeats the earlier (and potentially incorrect) requirement that UseHeaderPropagation() must appear before UseAuthentication(). Since derived propagated headers (e.g., X-User-Id) require HttpContext.User to be populated, the recommended order should be updated/nuanced (e.g., UseAuthentication() before UseHeaderPropagation() when deriving headers from claims, while raw Authorization forwarding does not require a strict order).
| - **"Something is broken."** Check the middleware order section above and ensure `UseHeaderPropagation()` appears before `UseAuthentication()` in the pipeline. | |
| - **"Something is broken."** Check the middleware order section above and verify the order matches your propagation strategy: for raw header forwarding such as `Authorization`, there is no strict requirement that `UseHeaderPropagation()` run before `UseAuthentication()`, but for propagated headers derived from authenticated user claims, `UseAuthentication()` must run before `UseHeaderPropagation()` so `HttpContext.User` is populated. |
No description provided.