CODEWITHSUNDEEP
c#asp.net-coreidentityserver4asp.net-core-identity
alaa_sayegh
alaa_sayegh

Reputation: 2211

Identity server 4 and user permissions

we are using identity server to grant access to apis. All what we used (or needed) so far was ClientCredentials (machine to machine) where the user is not involved.

Now we got the requirement that users should be involved and we must deliver user permissions.

I have read a lot about Granttypes: Implicit, Authorization code, Hybrid etc... but still didn't find a clear answer about the best practises.

Is there any way to integrate user permissions in access_token (is this also a good idea?). The AspNetIdentity is already integrated and the tables are existing in identityserver database.

services.AddIdentity<User, IdentityRole>()
.AddEntityFrameworkStores<IdentityContext>()
.AddDefaultTokenProviders();

How to send client credentials and user credentials so our identity server can also collect user information (permission, claims, role, etc...)?

Any help is highly appreciated.

Thanks

Upvotes: 4

Views: 3341

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239290

You're confusing concepts here. Identity Server deals only in user principals (basically just a set of claims belonging to a "user"). The actual user management is out-sourced, most normally to Identity. Identity itself is claims-based, as well, with roles actually just being a type of claim.

Authorization is a whole other beast and doesn't technically explicitly involve either Identity or Identity Server, although they often act as the gateway to said authorization. Authorization can be role-based, claim-based, or policy-based in ASP.NET Core, and then there's the technically framework-agnostic resource-level authorization option. However, that's still going to ultimately rely on one of the big three: roles, claims, or policies. It will simply have an added component of being specific to a particular resource. Which way you want to authorize is entirely up to you and of course you can mix and match as well.

Ultimately, you're just going to set roles and/or claims on your user via the tools Identity provides, which of course, will be persisted to you user/role store. Then, when authentication occurs via Identity Server or directly, a ClaimsPrincipal will be created and added to HttpContext. When authorization is required, the claims on this principal will be utilized in some way to determine whether access should be allowed or not. Simple as that.

Identity Server simply acts as a centralized authentication provider. Since communication is happening over HTTP, it's actually going to be returning JSON, specifically a JWT. Then, ASP.NET Core's authentication middleware, which would have been set up to use Identity Server as its provider, would simply decipher the JWT and create the actual ClaimsPrincipal instance from that. You don't need to worry about any of that, though, past the initial implementation. Once everything is integrated, the fact that Identity Server was used is virtually inconsequential.

Upvotes: 8

Related Questions