-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Allow specifying authz policies on endpoints #41153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- The user can specify additional requirements or policies on the endpoint and they will be combined with existing IAuthorizeData.
// REVIEW: should we check if there already is any authorize attributes first? | ||
builder.Add(endpointBuilder => | ||
{ | ||
endpointBuilder.Metadata.Add(new AuthorizeAttribute()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we check if any IAuthorizeData is already in the metadata so we don't add extra empty [Authorize]
s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I'm not sure where. Can we do it in this callback? We need an "only add metadata if not already added"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just added a Any query inline here to prevent dupes, does that work?
Can you update the code in SignalR as well? |
Sure what's the equivalent way to get endpoint metadata in SignalR? Looks like we just need to get the metadata policies and add that to the HubMethodDescriptor to flow it to the authZ logic, somewhere like here after we get the Authorize attributes on the method:
|
Sounds about right, and then update
|
So for SignalR, what's the best way for me to get access to the new endpoint metadata, I see the tests are using EndpointDataSource, should I be doing this as well to find the new auth policy metadata in DefaultHubDispatcher? |
Test for Hub method auth is at
|
@@ -549,21 +551,26 @@ private void InitializeHub(THub hub, HubConnectionContext connection) | |||
|
|||
private static Task<bool> IsHubMethodAuthorized(IServiceProvider provider, HubConnectionContext hubConnectionContext, HubMethodDescriptor descriptor, object?[] hubMethodArguments, Hub hub) | |||
{ | |||
var endpoint = hubConnectionContext.Features.Get<IEndpointFeature>()?.Endpoint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move this to where HubMethodDescriptor gets its AuthorizeData, we don't want the cost of these calls per Hub method invoke since it's static information.
@@ -549,21 +551,26 @@ private void InitializeHub(THub hub, HubConnectionContext connection) | |||
|
|||
private static Task<bool> IsHubMethodAuthorized(IServiceProvider provider, HubConnectionContext hubConnectionContext, HubMethodDescriptor descriptor, object?[] hubMethodArguments, Hub hub) | |||
{ | |||
var endpoint = hubConnectionContext.Features.Get<IEndpointFeature>()?.Endpoint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here was what I was asking about, how do I get the endpoint metadata out, this doesn't look correct because looking at the current auth tests, I don't think it even exposes anything like an HttpContext in the TestClient that the tests use, or at least other than stuffing in my own IEndpointFeature into the test client, it feels like I'm doing something wrong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so there is no endpoint for a Hub method. The endpoint is already running at this point in the code and has run AuthN/AuthZ for the endpoint.
We grab the metadata off the Hub method and use that. So if you look at DiscoverHubMethods(...)
we grab the AuthorizeAttribute off of the methodInfo and will do the same for policies now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how does that work for these new policies, since they only exist as metadata off an Endpoint, there is no authorize attribute equivalent I can look at without the endpoint metadata?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it doesn't apply until we do the [RequireClaims]
change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davidfowl what do we want to do exactly for signalR here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok confirmed in standup that we don't have to do anything here since it won't work, so I will remove these changes in the dispatcher for now
Continuation of #39892