What is the recommended approach for user management with IdentityServer4 and Active Directory?
I have started with the IdentityServer4 ASP.NET Core interactive quick start and all is working well. However, the sample code uses the TestUserStore, TestUserProfileService etc., and it seems prudent to replace usage of these.
The 'real-world' alternative seems to be using ASP.NET Core Identity, however this persists user details to the IdentityServer database. Given that IdentityServer isn't the source of truth for this data, this is an odd fit.
Apart from the "test" nature of the quick start classes, these are serving our needs well. Our IdentityServer instance is for internal staff in a small organisation, so the in-memory nature of these stores isn't a problem.
This seems to be a fairly common use-case, so I must be missing something. Can one just delegate all user profile calls to Active Directory? Is there any out of the box code for this?
Identity Server is an implementation of OAuth 2.0 and OpenIDConnect(Built upon OAuth2.0). The key point of OAuth 2.0 is to pretect resource such as WebApi based on Access Token. So what does OAuth 2.0 provided is Authorization.
Identity Server can provide Authenticate service provided by ASP.NET Core Identity, as specified in This Document
In your case, you'd like to delegate the authenticate part to AD, and authorization part to Identity Server. You can refer to This document to enable windows authenticate in your asp.net core application
I resolved this by implementing and registering an IProfileService for Active Directory. It still seems oddly hand-rolled, but seems to do the trick.
Related
I have a working implementation of IdentityServer4 with custom user stores, etc.
I have an asp.net core web app that I want to require user login for certain pages through the IdentityServer4 instance with my site having full ASP.Net Core Identity functionality e.g. my razor pages accessing User etc.
I have been searching for 3 days and while the internet seems to have lots of resources available on very similar topics, they all do things a little differently. I feel like I just don't know the right keywords to search for.
I have been following many online tutorials such as JWT Authentication on .Net Core and all of the quickstarts on identityserver4.io but they all leave out crucial steps.
IdentityServer is an implementation of oidc, which means that it serves as an independent, central authentication point. Client apps should be unaware of users credentials. That's part of the responsibility of IdentityServer.
So the reason you won't find answers and you think steps are missing, is because you are not implementing oidc.
It is not possible to 'hide' IdentityServer when a user has to login there.
That leaves you with three options:
implement Resource owner password flow. In that case you can collect the credentials and send it to IdentityServer. Please note that there may be security issues when you use this.
Do not use IdentityServer but instead implement Asp.Net Core Identity.
Send information to IdentityServer to identify the client and use custom presentation for that client. In that case the url may be different but the look and feel remains the same.
I am "learning" about the development of ASP.NET Web APIs with security provided by OAUTH2 and OpenId. So I have started with the Web API Template. The Web API Template has its own "Individual Account" user management mechanism which can issue tokens via /Token. However getting Refresh Tokens with this mechanism is a little trickier.
This got me thinking, should I be really looking to provide this functionality by using IdentityServer instead. If so, as I understand it, as I am using ASP.NET 4.7/MVC5, and not ASP.Core, then I should use IdentityServer3 and not version 4.
Also there is all of the login functionality required when the Access Tokens and Refresh Tokens are expired.
It's unlikely that anyone will be able to definitively tell you whether to use Identity Server or not. You will need to make that decision yourself as you understand the problem domain the most.
If you do decide to offload authentication to a central authority provider (like Identity Server) then I can tell you that there is no hard dependencies that would force you to use Identity Server 3 or 4 as they both ultimately conform to oauth2/oidc protocol. If you have ability to host .Net Core apps then I can recommend you to use Identity Server 4 as that implementation is significantly more extensible and offers extreme flexibility.
The question: Should I use .Net Core Identity or IdentityServer 4 with Identity
I need to build app with login/register functionality and allow users to use APIs to import/export data from my software. I also want to have external logins like google, twitter, etc.
And I'm not able to understand why would I need Identity Server when all things can be done using only Identity.
Why would I need or want IdentityServer ? I just need to get work done right and as simple as possible.
You really can't compare the two.
ASP.NET Identity is a database API to manage users, roles, claims, email confirmation tokens etc. Something you can use for implementing signup, login, change password etc.
IdentityServer is an OpenID Connect and OAuth 2.0 implementation. It gives you features like single sign-on and API access control. This is useful if you want to share users between multiple client applications.
You can combine both though - use IdentityServer for the protocol work, and ASP.NET Identity for the user management on your central login page.
It depends.
IdentityServer will provide you with OAuth 2.0 and OpenID Connect implementation, and it will handle all details for you (providing you endpoints, token management, scopes, grants and so on). It runs independently so you can use it for multiple clients (SPA, mobile, web apps) and it is nicely isolated from rest of your app. If you wish so, you can use it together with ASP.NET Core Identity.
If you don't use IdentityServer, you will have to write some of these things yourself because ASP.NET Core Identity is a membership system and it does not provide any ready to use endpoints and neither token management or support for different ways how to authorize.
You need to evaluate whether it is better for you to write these things yourself but have a more straightforward setup because you probably don't need everything IdentityServer provides although it might limit you in future.
You can also have a look at OpenIddict that is less complicated than IdentityServer.
TL;DR - Headline :)
Background story:
I'm building a set of applications (including RESTful APIs, and several clients - pure web apps, and mobile apps).
All the core APIs are going to be written in ASP.NET Core.
I want to tackle the authentication-authorization issue.
I don't want to use a cloud or an external service since keeping all the user related data close is in top priority for me (including passwords).
From what I read, it seems like that ASP.NET Core Identity provide all the functionality and processes related to authentication and authorization needed. I can manage a whole user base, including hashed passwords, and all the data-related to a user by myself. It's a collection of abstractions and concretes (which I can extend if needed).
I also read that I can integrate with IdentityServer 4. From what I understand, it grants me an extra layer of security, in a way that I can use it as a security token service (STS) and provides me with the implementation of OAuth 2.0 authorization and OpenID authentication which is great, BUT... is that it? I just want to understand what's my benefit of using it.
My question has 2 parts :
What's in between ASP.NET core Identity and IdentityServer 4?
Does IdentityServer 4 supply some (different) concretes of the abstractions that ASP.NET Identity's provide?
I want to know the relation between ASP.NET Identity and IdentityServer 4.
What's the cost of developing with IdentityServer 4? Is it straight-forward, or it's not the trivial to implement?
A bonus question :) - Are there any alternatives out there? What would you choose? And why?
the following question has an EXCELLENT answer, which answered a lot of my questions, but I still want an answer specific to my questions.
Thanks in advance!
Well, if it's not obvious by now: You can't create jwt/bearer tokens with ASP.NET Core Identity.
ASP.NET Core Identity uses cookie middleware, which has a few downsides. With the Authorization middlewares available you can consume bearer/jwt tokens, but you can't create your own ones. That's where ASOS & Identity4 close the gap.
Using cookies has several downsides, including the fact that it's generally long lived whereas JWT tokens usually have a short lifetime (5 to 10 minutes) and get refreshed via identity token.
So in case someone obtains a bearer token by eavesdropping the traffic, the token is only valid for a short period and the attacker can't refresh it without the id token.
Second, cookies are more vulnerable to XSS, whereas bearer token are sent per request and are only vulnerable to XSRF, which can be more easily be protected via AntiForgery tokens. See also this answer on security stack exchange.
In ASP.NET Core Startup in Configure method when you are configuring piplelines you can use UseIdentity from ASP.NET Core Identity or you can use UseCookieAuthentication. Both of them provide cookie based authentication.
I want to know what is their difference. Is UseIdentity uses UseCookieAuthentication internally? What are advantages and disadvantages of one over another?
Thanks for your explanations.
From the docs which can be found here and here.
Cookie Authentication Middleware:
ASP.NET Core provides cookie middleware which serializes a user principal into an encrypted cookie and then, on subsequent requests, validates the cookie, recreates the principal and assigns it to the User property on HttpContext. If you want to provide your own login screens and user databases you can use the cookie middleware as a standalone feature.
Identity:
ASP.NET Core Identity is a membership system which allows you to add login functionality to your application. Users can create an account and login with a user name and password or they can use an external login providers such as Facebook, Google, Microsoft Account, Twitter and more.
In short Identity builds on just local authentication and provides the ability to perform external authentication as well as baked in solutions for provisioning user accounts.
The pros and cons of each differ depending on your business and both have their own place which I find is usually determine on a case by case basis.
The inner workings for Identity can be found on the github page here.
Is UseIdentity uses UseCookieAuthentication internally?
Yes.
However, both UseIdentity and UseCookieAuthentication will be deprecated in Auth 2.0.
UseIdentity
UseCookieAuthentication
services.AddCookieAuthentication() and app.UseAuthentication() will be used instead.
Important note: Don't use UseCookieAuthentication, if you have UseIdentity. I mixed them together in a project. Claim-based authorization redirected user to LoginPage instead of AccessDenied page.