Replies: 2 comments
-
Hi @sidmore, thanks for the suggestion. What would you expect the output/result of an Some initial thoughts: while this works for authentication, where an identical policy can be run for multiple endpoints, it is less common to have identical authorization decisions across multiple endpoints. Authorization decisions must be parameterised with some additional understanding of the target endpoint (eg - the roles who can call this endpoint, or the name of the endpoint again, or similar). So you're more likely to have an instance of each policy specific to each endpoint, at which point it may as well be in the endpoint handler. The tradeoff here is that all of our endpoint-decorator properties could also be expressed by some common code within the endpoint, and we only want to support declarative properties in the framework API where we can use this declaration for something else (eg - authentication can be described in OpenAPI, and to do this at the framework level we need the policy described declaratively). Where these properties need to be parameterised, its harder to find the right balance of expressiveness vs an extractable declaration. To be more concrete, where we currently have:
We could get most of the same functionality from the old-style:
Its potentially more boiler-plate in every endpoint*, and it won't be inserted into the generated OpenAPI, but it gives you full expressive freedom (customise the error message, handle odd combinations of Authn properties, anything you want). So we could do a similar transformation for authorization, but its only worth supporting if it enables some other functionality (like describing this policy in OpenAPI). * Actually it doesn't need to be in every endpoint. If you don't want to type |
Beta Was this translation helpful? Give feedback.
-
Thanks much @eddyashton, actually why not have authorization policy per end_pt? If CCF provides an AuthorizePolicy->evaluate() method, application code can extend that with the specific evaluation method. This way instead of applicaiton having to write some processor which then reprocesses the ctx to figure out the identity and then check access. Hoping that framework provided attribute or construct similar to what C# provides will be easier for developers to write Authz policy then having to implement entire Authz processors. Example in C# on a controller we can do this:
|
Beta Was this translation helpful? Give feedback.
-
Currently CCF provide AuthnPolicy which can be extended for custom authentication mechanism, to do authorization I had to implement custom processors for AAD and CERT. If CCF framework provided a AuthzPolicy which can be appended to an end_pt will make developer experience building CCF applications better.
Beta Was this translation helpful? Give feedback.
All reactions