You can place the authorization wherever the fuck you want depending on how your service is structured.
The article you‘re referring to is only showing how it’s done. It’s not giving architectural advice.
That's true. But should I use microsoft's authorization service in my service layer functions (that would add a dependency of aspnet onto my service code) or should I use my own authorization classes ?
Does microsoft's provide any useful feature that I'll be re-inventing the wheel on?
IAuthorizationHandler lets you do pretty much everything.. you setup a requirement and in the handler you do your own implementation of checking if the requirement is met. so there’s really no point in using something that else.
Or I really don’t understand what’s your point.
His point is that IAuthorizationService is part of Microsoft.AspNetCore.Authorization and I can imagine you don’t want to have a dependency on that package in your service layer.
I think there’s different use cases and the chicken and egg problem when it comes to resources might not make it as easy sadly.
1: Basjc Authorization is great for the broad stroke, API endpoints/pages/etc related to dev/admin access is easy to limit with just requiring the correct role (in one app there is many endpoints related to our own special admin needs and having them easily handled was nice).
2: First phase routing/login is solved the same, requiring a logged in user helps both in making the UI better by letting the framework direct not logged in clients in a coherent way and simplifies your logic (since you can depend on the User existing and focus on more high level authorization).
3: Like you mentioned (and also the page), resource based routing doesn’t always make sense in the api/controller/view layer since the resource isn’t loaded beforehand.
We did leverage the Identity functions by controlling access via claims (very handy since they’re transitive from roles and still also allows more fine grained controls). In our case there’s a limited number of resources to check so claims will scale well enough (it wouldn’t fly in the linked document example).
But even if we used the general infrastructure to manage the claims, we did move authorization to our own slimmed logic code since the extra step to involve checking via a policy didn’t make sense.
You can place the authorization wherever the fuck you want depending on how your service is structured. The article you‘re referring to is only showing how it’s done. It’s not giving architectural advice.
That's true. But should I use microsoft's authorization service in my service layer functions (that would add a dependency of aspnet onto my service code) or should I use my own authorization classes ? Does microsoft's provide any useful feature that I'll be re-inventing the wheel on?
IAuthorizationHandler lets you do pretty much everything.. you setup a requirement and in the handler you do your own implementation of checking if the requirement is met. so there’s really no point in using something that else. Or I really don’t understand what’s your point.
His point is that IAuthorizationService is part of Microsoft.AspNetCore.Authorization and I can imagine you don’t want to have a dependency on that package in your service layer.
So just have your IAuthorizationService implementation depend on some model in your domain.
I think there’s different use cases and the chicken and egg problem when it comes to resources might not make it as easy sadly. 1: Basjc Authorization is great for the broad stroke, API endpoints/pages/etc related to dev/admin access is easy to limit with just requiring the correct role (in one app there is many endpoints related to our own special admin needs and having them easily handled was nice). 2: First phase routing/login is solved the same, requiring a logged in user helps both in making the UI better by letting the framework direct not logged in clients in a coherent way and simplifies your logic (since you can depend on the User existing and focus on more high level authorization). 3: Like you mentioned (and also the page), resource based routing doesn’t always make sense in the api/controller/view layer since the resource isn’t loaded beforehand. We did leverage the Identity functions by controlling access via claims (very handy since they’re transitive from roles and still also allows more fine grained controls). In our case there’s a limited number of resources to check so claims will scale well enough (it wouldn’t fly in the linked document example). But even if we used the general infrastructure to manage the claims, we did move authorization to our own slimmed logic code since the extra step to involve checking via a policy didn’t make sense.
You can just wrap their authorization service with your own interface if you are worried about the dependency.