I'm looking at implementing user management into my .net core api that use cqrs+eventstore.
My thought:
Since i'll be using mongo for most of my domain models i thought why not use to store my users as well.
i.e. have a CreateUser command and query service that subscribe to UserCreated event and store user in mongo.
I was hoping to use ASP.NET Core Identity for my user management but everywhere i see identity, e.g. https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity, it goes with asp.net mvc app. Which makes me think if do i even need Identity. I'll be exposing my api to various clients, mobile, web, etc.
Reading along there is also an IdentityServer4 which i don't quite get how it fits in.
Anyone to point me in the right direction?
You don't need MVC in order to use Identity. I would recommend Identity Server (there is a good tutorial by its creator on Pluralsight).
You can very well have a Web API in .Net Core and use Identity Server to create tokens, etc. which is the recommended authentication mechanism when you want to expose to different clients (platforms).
Does it make sense?
Related
I've a situation where I'm creating a Blazor Server front end for an API, and that API may also be used directly by some other systems. Essentially some smaller customers might use the UI, others (perhaps larger with their own dev team) build their own UI and use the API. We control both sets of code (for the Blazor and the API).
Auth in the api is done (at the moment) by sending a userid and a password and getting a JWT Bearer token that is added to all subsequent requests.
Auth on the BS app is (at the moment) done using Azure AD B2C; the templating in VS makes it an easy setup and then no really specialist knowledge is needed to maintain and add new users
There isn't any special link between the two for now; both are in dev and the BS app just has a hard coded u/p for a single dev user inthe API side. At some point that needs to change so the API serves more than one customer via the UI
It seems I have a couple of routes I could go down:
Make the BS app use the API for auth; in my mind this looks like setting up something similar to what you get when you make a new BS app with "Individual Accounts" auth, except it doesn't use EF on a database with tables for tracking identity - it would probably use a custom store and usermanager that asks the API for auth instead of some DB, and then some (hopefully simple) mechanism of getting the returned token from the API into every httpclient that ends up being used to poke the API (they're abstracted away into proxies built by NSwag but it's easy enough to address because NSwag code calls a particular overridable method to setup the headers.. finding a way to have the httpclientfactory do it might be even easier)
Make the BS app and the API use AD B2C for auth. As a workflow I genuinely have no idea how that's done or what it looks like.
Of the two I'd prefer the latter because it hands off some additional responsibility to AD, such as maybe in future we want to have UI customers also do 2FA but I'm not really sure how to go about researching it. How do we go about sharing auth between the two systems?
I'm not looking for code; some rudimentary instructions on how to share the authenticated identity between the BS app and the API is really what I need. If it's not an achievable goal, what alternative mechanism for Blazor Server do I have that would allow easy sharing of a retrieved bearer across a everything the user might do in a "session" (I don't mind if they lose SignalR connection and have to log in again)?
If either of the approaches above look like I'm just making life hard work, and it should be done another way, an outline of the steps required to make it go would be ideal
I have used quick start tutorial 5 sample to use IS4 with Asp.Net Core Identity. It works perfectly. But, as per business need, I need to extend the core identity to a large extent and add more APIs on top (will have its own DB). I thought it is a better idea to keep the user management using Asp.Net core identity and IS4 as two separate microservices, so that they can be independently scaled up and down. How can I achieve this? Any samples/references would be really helpful.
I would aim for just using Identity Server and not both ASP.NET Identity. In my understanding ASP.NET Identity is only meant to be used by one application.
I want to add Google calendar integration to my asp.net core web application. Once authorised for a user, the app will send updates to the user's calendar in the future.
The google api docs show how to use a FlowMetaData and a custom IDataStore in an asp.net MVC app to simplify the oauth dance and subsequent storage of tokens for a user, which looks spot on for what I need, but it's not core-compatible.
Is there a similar way to do this using asp.net core?
Unfortunately there's currently no fully supported way to do this.
The following PRs show two different approaches that may be useful:
https://github.com/google/google-api-dotnet-client/pull/1163
https://github.com/google/google-api-dotnet-client/pull/1109
Note that neither are merged, and I know that #1163 is currently unfinished.
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/
I am building an ASP.NET MVC 3 app that has both a www front-end (www.example.com) and a developer API (api.example.com). I'd like to make a simple service available to developers where they sign up for a key and make REST calls with it. I'm unclear on a few things:
1) How should I generate and store keys? Is it acceptable to store them in plain text in the database or should I hash and salt them?
2) How do I authorize API calls? I'm guessing I don't want to do this via ASP.NET Membership for this.
Things like rate-limiting seems straight-forward once I understand those two issues.
1) That's really up to you. I've seen it done completely differently in different API's I've worked with. Some keys closely resemble GUID's, others are clearly just random strings, but the important thing is that they're unique and not easily guessable. As far as how you store it in the database, how much effort you put into protecting your data really depends on the level of sensitivity of users' accounts. If the nature of the service you're providing is highly confidential and/or you may end up being audited, then you should take whatever means are necessary to protect the data (using a 1-way hash and salting). My personal philosophy is to keep things as simple as possible until there's a reason to introduce added complexity, but I've worked on sites that used 1-way hashing with salts for authentication.
2) That depends on who's going to be using your service. You could use the built-in ASP.NET Forms Authentication Membership Provider, and even integrate it with your public website, but that will limit the usage of your API to developers using a platform that supports cookies on HttpProxies, and will make your API harder to follow. Most REST-ful services I've had experience with have used a combination of basic authentication and SSL, which will provide the broadest range of developer support, but will be more complicated to implement on your side. On the server side you'll have to capture the user credentials out of the HTTP headers and authenticate them against your user database.