ASP.NET Core Spa Angular Template combined with IdentityServer4 for Authentication / Authorization
Can someone please give me a short explanation of how I can use ASP.NET Core Identity with ASP.NET Core Angular 4 app using AspNetCore Angular spam template.
I am completely configuring IdentityServer4 as my own project and it uses ASP.NET ID. I used the IdentityServer4 frontend to create multiple users. I can now see these users in AspNet tables in the database.
I added an ASP.NET Core Angular 4 app as a client for IdentityServer4. This way he can talk to him. I added an [Authorize] attribute to the HomeController to prevent Angular 4 pages from being accessed unless they are logged in. The user automatically switches to IdentityServer4 to login. Once logged in, they go back to the Angular interface.
Now I want to go one step further and say that this user can only access this (authorization). Let's say I add a bunch of claims to one of the users in the database. A service in Angular 4 makes an Api call to fetch data. I added an attribute like this to one of the methods in the api:
[Authorize(Policy = "Employees")]
When Angular 4 service calls this method from http.get, I cannot access it. I believe this is because Angular 4 knows absolutely nothing about what this user is claiming at the moment. Is there a way to put it all together to make it work, or am I stuck doing all the authentication / authorization on the frontend with an oidc client.
Should I use Role Based Permissions ? Claims based approval ? What works best with Api and Angular frontend?
source to share
Let me quote from two articles that I found very helpful:
Design for clean separation of credentials and permissions (just re-authentication and authorization). Acquiring authorization data as close as possible to the code that it needs - only there you can make an informed decision about what you really need.
and
Role checks are deprecated - they only exist in Microsoft (Microsoft) approve world due to backward compatibility with IPrincipal. Theres no longer needed for them - and you don't have to do role checks. If you want to check for specific requirements - just request a collection of claims for what you are looking for.
Suppose we forget about roles and use statements instead. In my opinion, it is best to view claims not as an equal substitution of roles. Claims can be very useful when used in politics, for example if EmployeeId is not null then user is Employee
. Or when you want to keep remote database access to show static information like display name, something you can show on every page.
Not everyone should be forced to make claims. If we keep the authorization close to the resource, then consider getting information from the server directly. This way you can request the actual permissions from the user. You can store information (in memory) on the client and invalidate it if necessary. Make it more flexible than requirements. You can get profile information or user preferences in the same way.
Something I used to authorize is a server call that returns "tags". These tags are used at the front to show or hide options. This should also ensure that the code cannot call methods that are not accessible to the user. You can base these "tags" on policies to keep the front and back in line with eachother.
source to share