Closed jonmsherman closed 2 years ago
@GFoley83 this helped a lot thanks! Any chance there's also more of an explanation on where to do JWT authentication? I want to check if the JWT is valid first and then I want to authorized based on roles, would this be a separate behavior?
For the soltuions in https://github.com/jasontaylordev/CleanArchitecture/issues/56, the authentication and authorisation checks all happen inside a behavior pipeline that get run on every request. So for example, if you look at Jason's solution from https://github.com/jasontaylordev/CleanArchitecture/issues/56 https://github.com/jasontaylordev/CleanArchitecture/commit/573f3061e2b3b50ef5e2515b03e1a118602a1630, you can see he checks for the authorize attribute, if the user is authenticated (JWT is valid) and finally, if they're in the correct role(s).
@GFoley83 thanks for this, I'm not seeing exactly where he's checking if the JWT. However I'm trying to implement authentication/authorization using auth0, do you have any ideas for this?
You don't write code manually to check the JWTs, that happens as part of the identity middleware; e.g. services.AddOpenIdConnect( . . . )
that you configure in the Startup.cs
.
https://auth0.com/docs/quickstart/webapp/aspnet-core/01-login
After that, look the very first file in the commit: https://github.com/jasontaylordev/CleanArchitecture/commit/573f3061e2b3b50ef5e2515b03e1a118602a1630 AuthorizationBehaviour.cs
For ex. on how to check roles. This hasn't been pulled into the master
branch yet. So if you'd like to use that new logic for role
checking, then you'll need to checkout that commit directly and make your own changes on that.
If you're using Auth0 then you'll need to update the Startup.cs
inside the WebUI
project and get everything configured correctly in there first though, before you even bother with roles. This will be completely up to you to figure out, but I'd be keen to hear if you get it working.
You'll need to either update IdentitySever4 to work with Auth0 or replace IdentitySever4 completely with Auth0 as your OIDC provider.
https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/netcore2.1/Quickstart/01-Login
@GFoley83 I guess I'm not super familiar with IdentityServer, but it looks like it's just checking for roles in that file and I don't see anything about a JWT? As for the auth0, I'm really just trying to make a new project using clean architecture principles, here is my JWT implementation I was looking at using auth0: https://auth0.com/docs/quickstart/backend/aspnet-core-webapi/01-authorization, to me it looks like they have to use the service extension methods to get it working correctly and I was wondering if I would have to put this in my application project? I basically just want to make sure I have the correct logic in the right place, rather than copy this template exactly by using identity server.
I've updated my question above so take another look.
to me it looks like they have to use the service extension methods to get it working correctly and I was wondering if I would have to put this in my application project? I
Yes exactly.
Given you're looking to use Auth0 as the OIDC provider, you will need to figure out the correct configuration yourself e.g what goes in the service extension, as this solution is configured to use IdentityServer4 for that purpose.
https://stackoverflow.com/questions/47058697/identityserver4-vs-auth0
So it's ok to leverage the ASP.NET middleware instead of putting this inside of the mediatR pipeline ( I thought we didn't want dependencies on the framework)? That is the part I'm confused on because I'm not sure how to do put uath0 related code inside the of the behaviors.
So it's ok to leverage the ASP.NET middleware instead of putting this inside of the mediatR pipeline ( I thought we didn't want dependencies on the framework)?
Not really no. That's what you get out of the box with most solutions but with CleanArchitecture, the best place to do this is in the Application layer as a MediatR pipeline, in my opinion.
There are two separate parts to this which I think you should be clear on:
WebUI/Startup.cs
and Infrastructure/DependencyInjection.cs
to boothstrap authentication and authorization into your entire application. This is not just a middleware but it does add a middleware so that you can use things like the Authorize
attribute inside controllers. Also this is why the concrete implementation CurrentUserService
is inside the WebUI
project as we need to be able to access the HttpContext
to get the claims and roles etc. set by the middleware. Startup
so that we can check roles, claims etc. inside the Application layer.That is the part I'm confused on because I'm not sure how to do put uath0 related code inside the of the behaviors.
If you took Jason's solution above with the role checking behavior; the only changes you should need to make to get Auth0 working would most likely only take place inside:
It feels a little like you've jumped into the deep-end here before having a firm understanding of the differences between ASP.NET Core Identity, IdentityServer and Auth0. I highly suggest you read the authentication and authorization sections in the Microsoft docs:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity
If anyone interests to see a working prototype of IdentityServer4 integrated into a Clean Architecture project, check out the repo at https://github.com/workcontrolgit/Self-Order-System. The repo contains the sample code to construct a Policy to secure access to the WebAPI endpoints based on role claim. I hope it helps those who need to have a robust Identity and Access Management solution.
Hi everyone,
It's been a while since this question has been asked, but what I was about to ask might be closely related to this topic. I've got two questions related to authorization.
First, it would honestly feel odd to me to authorize at multiple (Controllers and Application Layer), but I was still looking for opinions on that subject. In AspNet Core, Authorization are done within controllers, but with Clean Architecture (from my understanding) we're trying to move that logic to the Application Layer.
Regarding the roles/policies/claims, going with the Application Authorization means that the token or cookie doesn't need any of this information 🤔 The validation implemented by @jasontaylordev query the identity to validate the role and claims, therefore no need to keep them, am I correct?
Another thing related to the current AuthorizationBehaviour is that it generates lots of traffics on the database to validate the claims. It gets the user information, generate the claims, validate them, etc. Is there any solution to mitigate this?
This has been a good discussion, I'll close of this issue. But first some feedback.
@YannickRondeau at some point I'll likely rebuild the authorisation behaviour to be based on CurrentUserService: ICurrentUserService rather than querying the database for roles. I will populate ICurrentUserService with other information such as roles and permissions that would be sourced from claims.
Hi, I want to implement role-based permissions and I was wondering if these handlers would go in the application layer because they're sort of business logic?