Interview question
Protect an endpoint with a capability policy
Maps a named capability to an ASP.NET Core policy and enforces it at the endpoint boundary.
TL;DR
Maps a named capability to an ASP.NET Core policy and enforces it at the endpoint boundary.
Policy registration, capability claims, endpoint authorization, 401 versus 403, and direct-request security.
Practice the problem like a real interview: restate, reason, implement, and test.
Only authenticated users carrying content.publish may publish a content item. Editors without that capability receive 403 even if they can update drafts.
An admin token publishes successfully; an editor token reaches authentication but is denied by authorization.
I register the capability requirement once and attach the policy declaratively. Authentication builds the identity; authorization evaluates the specific command permission before the handler executes.
builder.Services.AddAuthorization(options =>
{
options.AddPolicy("content.publish", policy =>
policy.RequireAuthenticatedUser()
.RequireClaim("capability", "content.publish"));
});
app.MapPost("/admin/content/{id:guid}/publish", async (
Guid id, ContentService content, ClaimsPrincipal user, CancellationToken ct) =>
{
var result = await content.PublishAsync(id, user.RequireUserId(), ct);
return result switch {
PublishResult.Published item => Results.Ok(ContentResponse.From(item.Value)),
PublishResult.NotFound => Results.NotFound(),
PublishResult.Conflict conflict => Results.Conflict(new ProblemDetails {
Title = conflict.Reason,
Status = StatusCodes.Status409Conflict
}),
_ => Results.StatusCode(StatusCodes.Status500InternalServerError)
};
}).RequireAuthorization("content.publish");
The endpoint states its permission requirement without coupling the domain operation to today’s role model. The service still enforces lifecycle rules such as already-published or invalid content.
IsInRole("Admin") inside every handler.Next in API Implementation Labs: Resource Ownership