I have implemented IdentityServer4 in ASP.NET core with one application as Identity server and second one as client. I have couple of queries
1. I want to add roles to the profile information returned.
2. What are scopes there for ?
can someone provide a fair idea ?
To add roles, check out the IdentityServer4.AspNetIdentity nuget package. See Using ASP.NET Core Identity.
Scopes are used to create a relationship between ApiResources and Clients. Rather than say, associated the name of a client api (e.g. AccountingApi) to an ApiResource, we associated the client api to a scope (e.g. internalApis) and then associated the same scope to the ApiResource.
Related
Our current API leverages ASP.Net Identity and Policy Based permissions for Authorization. It uses User Roles as claims for this. These claims are intercepted by a ClaimsTransformer class and the user permissions are read from a database containing the user mappings (cached). This all works fine.
The problem I'm having is with the API's scope expanding to include different "Projects", such that for instance, a User can be a Creator in one project but a Consumer in another. Is there a way to reconcile these requirements with .NET Core's Role/Policy based Authorization? Or is the best approach here to query the Database for these permissions upon each request?
Authorization is hard and a good starting point is to watch this video:
Implementing authorization in web applications and APIs.
Then using the policies and requirements is how I would approach this and this resource is a good reference:
Custom authorisation policies and requirements in ASP.NET Core
The picture below shows how the concept of requirements work in ASP.Net Core where you can define a requirement and then have one or many handlers independently "vote" if the user is approved or not.
I am new to working with Blazor and Authorization. Background is desktop apps in Vb.Net, so I have been reading everything I can on it, but it still is very confusing when I only want a specific subset of the options out there.
I have a very simple intranet Razor Server based app that is getting the windows user name correctly with default authentication. (I use the name in calls to stored procedures for logging, so I know that is working correctly.)
What I need is to implement authorization (role based would be fine) based on information I have already in the database tied to the user name).
Where and how does one add roles to an existing authstatetask or other object instantiated by the default processes?
Everything I have seen deals with the EF version of Identity or wants to override the authorization task.
I have Simple DB calls being made in Dapper which will return an identifier from which I can set roles.
I just need pointers to the proper method and where in the app I should put it. I have just a single .razor page being loaded, Navbar is disabled.
You can either :
Implement Identity stores for Dapper following instruction in this blog : ASP.NET CORE IDENTITY WITHOUT ENTITY FRAMEWORK
Use Policy-based authorization and create authorization handlers meeting your requirements
I'm attempting to build an ASP.NET Core API with authentication/authorization handled by IdentityServer4. IdentityServer4 is being backed by both Identity and Entity Framework Core. My goal is a fairly standard and familiar set up, where users can login into a API developer portal where they can add "applications" (clients) and have a client id and client secret generated that they can then use to access the API, similar to how Facebook, Google, etc. handle API access.
My mental block is coming with the way IdentityServer handles Entity Framework integration. Their entities are attached to two different contexts, ConfigurationDbContext and PersistedGrantDbContext. I'm at a loss for a good way to associate one or more Client entities from IdentityServer4.EntityFramework with one or more ApplicationUser entities from my Identity context.
This seems like it would be a fairly common usage scenario, but the documentation is strangely silent on it. I've also been unable to find anything online after various and sundry searches. I'm hoping someone else has needed this same setup and can give me some advice on how to proceed.
There is no association between users and clients. IdentityServer authenticates users regardless of which client they are trying to access.
If you want to implement something like "which user is allowed to use which client" semantics, that is beyond authentication. This is typically implemented in the application itself since this is application specific logic.
https://leastprivilege.com/2017/07/10/authorization-is-hard-slides-and-video-from-ndc-oslo-2017/
we plan on using IdentityServer for our single sign on. we have multiple applications with users having different roles per application. it's not clear to me. how do we set this up?
Do emit application specific claims you currently need to implement a claims provider.
https://identityserver.github.io/Documentation/docs/configuration/serviceFactory.html
In v2 this will be even easier since the user service will know more client details.
I'm using Thinktecture Identity Server for SSO with some apps. The idea is that account information will be stored on the server in the claims information. So groups user membership and other hierarchies can exist on the SSO server. Then when some one authenticates they would get their membership and rights passed down through claims.
My question is how can my authentication subscriber perform a user.memberOf(x) kind of lookup? I can't imagine that the whole permission hierarchy gets passed down in a users claims. I imagine that additional queries would be performed against the sign on server like LDAP. How does this work for Thinktecture? Would it be the same generally for other SSO servers? If so what's the patterns name?
A general pattern is that, yes, you pass all roles in claims. This causes issues if there is too many groups but if this is so then it could be that the role model should be revisited.
Switching to oauth2-style authorization solves the issue: you don't pass claims in roles but then the relying party queries roles with an extra call. The drawback is that if the STS is further feredated with yet another STS, such extra calls become tricky as the call would require another internal call which would possibly require yet another call etc. Passing roles in claims means that there is no need for this extra call.
Yet another idea is switching to a custom STS that would issue claim roles filtered depending on the relying party or other user attributes. This could work as usually a single RP is not interested in all roles but rather a subset that makes sense there. Your filter is then implemented at the custom STS side.
Well - IdSrv is a custom STS. You can issue claims per RP - check this article (especially the part about IClaimsRepository):
http://leastprivilege.com/2013/05/17/customizing-identityserver/