What about EF Core 2.2 Roadmap?

What about EF Core 2.2 Roadmap?

https://github.com/aspnet/Announcements/issues/308

Roadmap looks good, particularly health checks and HTTP 2.0. However, in the kindest possible way, I disagree with the need to build a simple first party Microsoft authorization server. IdentityServer4 fills this gap nicely and the time spent re-implementing a simpler version of it could be better spent elsewhere. I understand the goal is to provide a simple solution but auth is hard and IdentityServer provides an API that is about as simple as it gets. If there are ideas for a simpler abstraction, it could be built on top of IdentityServer so people can use the simple abstraction but have the power if they need it.

Update

In the ASP.NET Community standup, it was mentioned that the ASP.NET Core team is talking to the Identity Server team about the options, including building something on top of Identity Server. I think that's what we all want, well done!

What are the current plans around ASP.NET Core WebHooks?

Regarding the dispatcher, will this be possible in the middleware then? 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^{[FromQuery]? 🤔}

Simple Auth Server but also remember what happened with Katana simple Auth Server

I want to echo @RehanSaeed’s concerns and would like to ask for some clarifications on what exact use cases this new server is supposed to fill. If this is primarly so web APIs have a way to get their bearer token that is valid within the existing authentication of the app, then that would be fine. But everything on top of that is probably better left to the existing solutions which already offer many options of different complexity and flexibility with products like IdentityServer, OpenIddict, and AspNet.Security.OpenIdConnect.Server.

What about IIS in-process hosting?

Could you elaborate more on the TypeScript part of "API client generation (C# & TypeScript)"?

This would be really something I would look forward to. Currently I'm using NSwag for auto-generating my Angular Client API Services. But there are just so many different combinations possible for client configurations that I think this could be problematic to please everyone.

Just off the top of my head, some thing that should be considered (and if possible should be configurable):

• Just a TypeScript client with fetch or an Angular Service with HttpClient?
• If it's Angular, which versions do you support (also important for RxJS)?
• null/undefined handling
• enum handling
• JS date or momentjs for date types?
• Exception handling, Validation error handling
• How to extend the generated code in the client?
• Possibility to influence name generation (e.g. dropping the DTO part from xxxDTO for the generated client classes or already at the OpenAPI definition)

If it was possible to vote for features, these improvements/fixes to existing middlware would be on my wishlist:

• Lets Encrypt support https://github.com/aspnet/Home/issues/1190.
• The Response Cache middleware is basically not usable as it is today. Adding a Redis response cache store and extensibility for user operations of cached responses should solve https://github.com/aspnet/Home/issues/2606.
• Support serving of pre-GZIP and pre-BR encoded files.
• Add a Brotli Compression Provider as well as fixing several issues with the response compression middleware.

I also vote to skip the Authorization Server product. Security is complicated and there has been a big push to move to cloud services to remove maintenance, and anyone who wants more control can already use IdentityServer4 which is well-built, tested, documented, and supported. A simple setup takes 5 minutes and they have plenty of starter samples, videos, and tutorials.

I fail to see how you can make security work as "zero config" any more than they can. It seems like this will just add more confusion (in naming and usage), while becoming yet another thing to support and maintain for years, taking effort away from other features continuously. Please rethink this.

I'm also curious why IIS in-process hosting isn't on this 2.2 roadmap. This is a major feature and is a major factor in our release strategy and schedules here at Stack Overflow and it was already removed very last minute before the 2.1 release, promising a 2.2 timeframe instead. Please tell me this is just an oversight and not another plan change.

Edit: @DamianEdwards replied on Twitter that this was indeed an oversight (meaning it's planned for 2.2). Phew!

I'll echo other comments. If you're going to invest in Authorization/Policy, specifically making it simpler, I'd personally much rather see a partnership with the likes of OpenIddict and IdentityServer on docs and investments in scaffolding. I can't help but feel that any work, no matter how simple, is just going to end up duplicating terrific third-party efforts and incurring an unnecessary maintenance cost on the aspnet team.

It maybe an unpopular view, but I'd like to see a Microsoft Auth Server, one that's built in the public eye, with our input and support.

The current ones - Id4, OpenIddict - are obviously excellent OSS projects, and I can't help feeling that one with the support of MS behind it could ever be a bad thing...?

There's a limit on just how much support is available from a small group of people, and these are mission critical products afterall.

I think it's a pity that the MS OSS Code of Conduct doesn't include a line which says "Don't promote features that duplicate something that can be brought-in with a Nuget request and which will casually crush a two-man business that contributes to our ecosystem".

The cynic in me can't help wondering if, for some insiders, giving Brock and Dominick a bloody nose was a feature of this suggestion rather than than a bug. Is this what happens to small businesses that ever have the temerity to criticise anything the ASP team does?

I also wonder that about duplicating auth functionality other than building something on top, such as UIs and documentation.

Addtionally, a well tested JSON-LD 1.1 library would be a nice, specific addition to the roadmap. :)

Repeating what others have said - I'd much rather see authorization work being brought in from something like IdentityServer4 than implemented afresh by yourselves. If there are gaps then surely bridging those through contributions, samples, and refining integration points would be a better way to go. Perhaps also pay some attention to your cloud offering in this space (B2C) which is in an appalling state.

Beyond that while you state the aim is not to replicate the functionality in existing open source offerings and to keep things simple this is somewhat equivalent to the classic rewrite trap: "this solution is over-complex, and a bit messy, lets rewrite it!". It's naive and in n versions time I would put money on you having dealt with the many edge cases that real world solutions require and that something like IdentityServer is already dealing with.

More broadly, with the acquisition of GitHub, there's been a lot of discussion recently around Microsoft's attitude towards open source. It's great that Microsoft are doing so much work in the open but part of being a good open source citizen is leveraging existing open source when it exists.

This is particularly important for platform holders such as yourselves - a platform holder duplicating functionality in existing open source offerings _discourages_ contributions while engaging with those offerings _encourages_ contributions.

I too can't see the point of effort being expended on authorisation, but would like to see the _management_ of ASP.NET Core Identity improved. Damian Edwards was quite clear on live.asp.net that we shouldn't roll-our-own security but - unless I've missed it - ASP.NET Core Identity does not contain any user management tools and so we do have to roll our own. This I find a bit terrifying as I'm not a security expert and am mortally afraid of leaving a security hole of my own making.

How about moving content Formatters from MVC level to AspNetCore.Http abstractions in 2.2?

Maybe the PM responsible could write up a more detailed description of this Identity Server Lite to make clear exactly what shortcomings in the existing third party open source solutions the ASP.NET team are looking to address. Because as it stands, you're talking about reinventing a wheel but maybe removing some spokes, and that doesn't make much sense. As somebody else has said, fixing up AAD B2C and providing first-class integration with that would be great, and make business sense for MS.

Also, have you even considered how difficult it's going to be to get a new, ground-up Auth server product past @blowdart?

Any plans to have a built-in RESTful API support like the one django has ?
Cuz it's something that all developers tend to write every time !

I built recently something that could be written as a Generic RESTful API controller:

https://github.com/0xRumple/dorm-portal/blob/master/DormPortal.Web/Controllers/StudentsController.cs

Also agree with "I fail to see how you can make security work as "zero config" any more than they can" and "you're talking about reinventing a wheel but maybe removing some spokes", identity server is an awesome product, very simple to get started with and provides extensibilty for more complicated scenarios, not sure why we require a "simplified" version.

On a much much smaller scale, why do we need another health check implementation. There are already several open source solutions e.g.

• https://github.com/Xabaril/BeatPulse, includes a bunch of pre-written checks and even comes with a UI
• https://www.app-metrics.io/web-monitoring/aspnet-core/health/

What will be the feature difference with these and what's provided in 2.2?

@0xRumple The improvements to the ApiController should help make this less verbose in general. But no, you probably won’t see something that just gives you a CRUD API for your entities by default. Such a thing would have to make far too many assumptions about your DAL and authorization.

If you follow certain patterns in your application, there’s nothing wrong with creating your own base types or conventions in 2.2 that will generalize the work for you.

@kieronlanning

The current ones - Id4, OpenIddict - are obviously excellent OSS projects, and I can't help feeling that one with the support of MS behind it could ever be a bad thing...? There's a limit on just how much support is available from a small group of people, and these are mission critical products afterall.

Since you asked about whether it could be a bad thing:

The ASP.NET team is relatively small too, serving millions of developers with limited capacity, so any new project will take away time and effort from other things. It means we all have to wait longer to get any brand new features that would probably deliver more value.

Much worse is that it hurts the 3rd-party ecosystem and discourages new products because of Microsoft releasing an "official" package, which many companies get stuck choosing just because it's from Microsoft even if it's technically (and in this case supposed to be) less capable. ASP.NET already integrates Json.NET, Polly, AutoMapper, and many other libraries so it seems like a misstep to rebuild such a complex security product (which will need 80% of the same base code) when great options already exist, and with so many more interesting things on the roadmap to work on.

@poke
You're right, writing base classes of my apps is a good idea.

Actually I believe those aren't within the framework responsibilities:

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

But there are many things I thought the AspNetCore could've done better (by having a AspNetCore.RestFramework package):

1. HATEOAS (self discoverable api)
2. Media Types (setting up custom media types)
3. Versioning (update mediatype version)
4. Mainpulated data metadata (pagination into X-Pagination header, filter metadata... etc).
5. Rate limiting & throttling.

I know there are tons of libraries out there, I found some here: https://github.com/thangchung/awesome-dotnet-core... But, 3rd party libraries aren't really a good option for the enterprise apps !

Same goes to the sieve, if there is an OFFICIAL package for pagination, filtering... etc, developers won't tend to write buggy or non-maintained libraries, I used this sieve in my app I mentioned above: https://github.com/Biarity/Sieve, but this library can go non-maintained any second the author got busy.

I think AspNetCore is mature enough to start thinking about out-of-the-box solutions as in django, this way we can have the luxury of asp performance and the agility of django.

But, 3rd party libraries aren't really a good option for the enterprise apps !

^ This is why we can't have nice things 😞

But, 3rd party libraries aren't really a good option for the enterprise apps !

Yes, that’s exactly the mind set that needs to change here. ASP.NET Core and .NET Core are open source and their ecosystem _is_ embracing the open source community and it should continue to do so. Not only with open source solutions that are part of the .NET Foundation, but any solutions really.

but this library can go non-maintained any second the author got busy

And in the same way, an “official” package can become unmaintained any second the company shifts its interest. This has happened with Microsoft specific things before, including multiple open source packages they published, but is really natural to any company.

If you decide to take a dependency on another ones library, it is your responsibility that you can live with that. Regardless of who is the author of that. The nice thing about open source is that even if the author ends up not responding, you are fully entitled to change it yourself.

I’m strongly against expecting official Microsoft solutions for everything you might be able to come up. Not just because there is never a one-fits-all solution, making this very difficult and at the same time likely to get out of hand, but especially also because this takes away resources from parts of the framework that really need the attention. And at the same time it hurts the open source idea really really bad.

If you are building enterprise applications and still struggle with this NIH syndrome (or “not invented at <large-company>”), you should really wake up because it’s 2018 and you should likely embrace open source now.

You're right Microsoft can stop maintaining any package but at least they have a specific LTS: https://www.microsoft.com/net/support/policy

For example, .NET Core 1.1 support ends on June 27 2019... this way I can be sure if I use this version I won't get crippled in the middle.

I once used a 3rd-party pagination tag-helper, and it wasn't pleasant, the author basically told me he won't fix it for .NET Core 1.1, and I should update the project, it was a university system, into 2.0 (and he has all the right to do so because he wrote that package for FREE).

Here is the problem, in the enterprise, this doesn't work... you can't convince the whole team that you should move into 2.0 while the app is up-and-running just because the pagination-tag-helper doesn't work!
So you just use start hacking the source like I did by using a decorator: https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

And yeah, who said I'm not a big fan of the open-source :confused: ?

@0xRumple isn't the idea of open source to contribute and collaborate?

If that 3rd-party pagination tag-helper didn't exist you'd have to write it yourself and maintain it anyway, "in the enterprise".

Here is the problem, in the enterprise, this doesn't work... you can't convince the whole team that you should move into 2.0 while the app is up-and-running just because the pagination-tag-helper doesn't work!

Rather than trying to "convince the whole team that you should move into 2.0", contribute an update back and help out rather than relying on someone else to do the work or wait for Microsoft to provide an equivelant. If the owner doesn't want to accept your contribution move ahead with a fork for your needs.

I guess your type of thinking (no offense at all intended) is a big part of why there is a discussion around "Microsoft authorization server" vs identityserver. How will open source ever work if developers don't want to participate. Should we wait for Microsoft to provide all the code we need?

I agree with many here that Microsoft should be careful they don't kill off good open source projects in the ecosystem by making their own replacements for everything.

I'm actually the author of the pagination taghelper library mentioned by @0xRumple , his issue was really with a pagedlist component not with the taghelper which in fact does have an older nuget that supports 1.x aspnet core. The paged list was really something that was part of a previous open source pager library that informed the design of my library and was used in the demo pages at one time but the pager taghelper did not depend on the paged list implementation and there are other paged list implementations out there he could have used while still using the pager taghelper. In fact I've since removed the paged list entirely from that library as it isn't even part of the taghelper and never was.

It really is no different for using nuget packages from OSS developers than Microsoft in that if you are stuck on aspnet core 1.1 then you can't get fixes and improvements from aspnet core 2.x unless you update to the new framework.

@joeaudette
I just mentioned that example to illustrate my point on built-in vs. third-party solutions, I'm still thankful for your work on that pagination taghelper... the university uses your pagination package and they're happy :heart:

@alhardy

Should we wait for Microsoft to provide all the code we need?

This is the main problem, we think that when Microsoft brings an official solution, they will fight any other open-source solution or they will write every single line of code by themselves :smile:

Of course not, we can the best of both worlds, an official solution and community-based solution if Microsoft adopts the right solutions and create the missing solutions, so that developers can focus to contribute on those.

The django community got it right, they provide/adopt officially the initial simple solution for a specific problem, e.g. RESTful framework, and the community build on top of that... have a look here at their initial stage of building django-rest-framework: https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

They started the initial project, and the community is improving/building on top of that, this is their repo: https://github.com/encode/django-rest-framework... around 800 contributors !
And the community is driven to build packages that solve problem on top of that package like django-rest-auth or django-rest-framework-jwt.

At least they provide such "official solutions" that most developers need, like django-admin-site or django-debug-toolbar. This also comes from the Python philosophy of "batteries included", at first, I thought it's bad as it strives for least-common-denominator solutions, and I realized later the breeze it brings.

*P.S: Dapper (by StackExchange) and EFCore (by Microsoft) are both ORMs, but they aim to solve the same problem in different approaches. Dapper was initially created in 2011 while EFCore 2014... did EFCore affect the open-source projects badly ? of course not, and it's an official solution though !
People already building on top of that amazing stuff, like this: https://github.com/crhairr/EntityFrameworkCore.MongoDb/

did EFCore affect the open-source projects badly ?

Uuuh, anyone remember NHibernate (which is closest to EF in functionality)? No, probably not, cause it's as good as dead after EF was released 😕

@0xRumple

Of course not, we can the best of both worlds, an official solution and community-based solution if Microsoft adopts the right solutions and create the missing solutions,

In this case, it's neither because it's recreating an existing solution, but with purposely less functionality.

Entity Framework and Dapper are very different. EF was always designed to be a full-featured ORM, and both came years after the original Linq-To-SQL in 2007.

However, I don't think you're wrong either and it seems we're all talking past each other. The thread is mostly comments about the auth server product while you're talking about REST related libraries, which seem small and focused enough to include in a web framework. I agree that standardized search/paging/filter parameters would be helpful to have built-in for Web API code.

This discussion is not acknowledging the awkward truth that in some organisations, developers have to account for every single open source package introduced into their solution. In some cases this is an automatic scan which will produce "Risk" reports that frequently a non technical risk manager will need to review. These tools will flag up anything that is not actively maintained and anything with anything that looks like a copyleft license.

You can also imagine that in these organisations contributing back to open source is seen as crazy talk.

Yes, Identity Server 4 is amazing. But to a non technical risk manager it is something that we don't have a warranty for, something supported by a handful of people and even worse - something with the source code available for everyone to see. This person is misguided but the average developer on the ground is not going to win this fight.

An "Identity Server Lite" as @markrendle aptly puts it, primarily written by Microsoft staffers could be the difference in being allowed to use .NET Core at all or not, especially if there is an enterprise architect in the organisation insisting that some $$$$$ Enterprise junk from HP or IBM is used instead for auth.

@edandersen

But to a non technical risk manager it is something that we don't have a warranty for, something supported by a handful of people and even worse - something with the source code available for everyone to see.

I'm pretty sure the IdentityServer folks would provide some support if you paid them for it - just like you'd pay Microsoft. OSS doesn't equate to free.

What makes you think the ASP.NET Core team at Microsoft isn't "a handful of people"? Spoiler... they are like 20-30 people in total. Only a couple would work on a product like that.

I'm really curious why "the source code available for everyone to see" is a bad thing? And what makes you think this product at Microsoft won't be open source? It's the new default.

@khellang "the source code available for everyone to see" to be clear this is a good thing! But you would be surprised at the arguments some developers need to have at work. The "Microsoft wrote it" point unfortunately is the only acceptable argument sometimes. Note I am playing devil's advocate for a hypothetical but typical disfunctional company.

And of course the same developers could advocate that their employer pays for support for Identity Server, but the procurement process will probably rob them of the will to live.

Well, if we start to use these non-tech managers arguments, things will start to get crazy. IMHO, people that are non tech, shouldn't dictate what should be used or not. If they want to have a saying, at least they should know what they are talking about, and saying that a well know package like IdentityServer is less quality than a MS one, for me, it's plain wrong. I would run from a company like that!

But the point here is that pretty much everyone agrees that spending time on something that's already there, it's solid and a LOT of people are using it it's a bit strange. I wonder what is the real reason behind this.. I don't think it was just like: Oh, let's build our own thing, just because we can. Do customers actually ask for this that we are not aware of maybe?

Personally, I don't see another contender in the OAuth-Server space as a problem, but a good thing.

It may help drive development in this area, or just serve as a quick and dirty solution for people who need nothing more than that - a quick and dirty solution.

If you want or need more from an OAuth server, then there's nothing stopping any one of us from using the existing solutions. Or, if you want a one-click template to do basic OAuth _and nothing more_, then this seems like a worthy goal, at least to me.

I think this thread has turned into a tit-for-tat on what OSS is, what MS is good at doing and what MS is not good at, rather than focusing on what's on the roadmap for .NET Core 2.2, which is what really matters here.

@khellang
"NHibernate is dead", said who ? I see the project is still alive, and even has a better momentum than Dapper
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

Ah, I didn't mention IdentityServer till now to stick on my point on having RESTful framework within the official aspcore pacakges... here are my thoughts about IdentityServer, it is really solid and great, BUT it is a 2-guys project, have a look at the metrics:
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

About 85% of the work is done by 2 guys and it's okay for a security related project, but in the enterprise many companies think about the maintainability of such projects in the future. Recently a company told me they want me to use React instead of Vus.Js in their project just because they said "vue.js is pretty much Evan You"... and I think they are right. And this is what I'm trying to say since the beginning of the discussion about having RESTful package within the official packages, any big company won't accept you using on a "potential" non-maintained package on their projects.

Same goes to data manipulation / sieving (paging, shaping, sorting... etc) because almost every project contains those requirements, and yeah as @manigandham said, they are standardized and straightforward.

@manigandham
Exactly that's what I think is right... adapting and supporting the solutions officially, whether financially or contributing via github or at least mentioning them in their docs or courses (I've already seen Hanselman mentioning SwashBuckle in one of his courses at Microsoft Virtual Academy which is really great, and it would be greater to see more adaption to such projects!).

@kieronlanning
You're right, we've gone too far from the main topic... but as I mentioned before, asp core just got very mature (performant and reliable), and I think it's time to start with the out-of-the-box solutions.

I think discounting a project because it has two main contributors is pretty darn silly. IS4 is very well maintained and those two guys spend a lot of time answering questions and helping people. It's also widely regarded as one of the best FOSS solutions for an OAuth2 sever on the market.

"NHibernate is dead", said who ? I see the project is still alive, and even has a better momentum than Dapper

@0xRumple I said "as good as dead" 😉 You seem to have some very weird metrics on the health and usage of OSS projects. Is it fair to compare the number of commits on a project from 2003 against one that has been going since 2011? They're also _very_ different beasts (as noted earlier in the thread); Dapper has been "complete" (that doesn't mean unmaintained, abandoned, etc.) for some time, while NHibernate (and its feature set) has been lagging behind.
I know the project is still ticking along, but I can't remember the last time, in my last 7 years consulting in the .NET space, where I've encountered NHibernate in the wild (where it wasn't in the process of being migrated over to Entity Framework). Everyone that's been following this space the last couple of years knows very well that NHibernate has been lagging behind and losing market share to Entity Framework. Just look at the NuGet download numbers alone: Entity Framework has 45.8M vs. NHibernate with 3.4M.

Anyway, the point isn't Entity Framework vs NHibernate. It was just _one_ example. We've had this discussion over and over; most recently when Microsoft rolled their own lightweight IoC container implementation in ASP.NET Core or when Microsoft was contemplating rolling their own object mapper. Any time Microsoft enters a space in the OSS community, it sucks a lot (most?) of the air out of the room. Often enough for the smaller, community-driven projects to suffocate over time. I, and most of the community, know it all too well; it's impossible to compete with Microsoft in Microsoft's own (.NET) world. I fully understand that they have paying customers that they need to satisfy, so I'm not expecting this feedback to change their minds :smile:

Awesome features :)

Where can I get more information for Health check feature?

Improve self-signed certificate management

When developing web apps that call associated web APIs, there comes a point when it’s useful to test them with in-house users over the local network. You may have passed all the unit, functional and integration tests, but there’s nothing quite like a human to really break things.

In the spirit of decoupling concerns, my web apps call multiple web APIs. In the first instance I develop these web APIs using https://localhost:. Once a web API is ready (enough), I then publish it to IIS on my local machine. Each site has an appropriate host name that I've set up on my internal DNS server. At this point I use Barry Dorrans' - @blowdart - gist https://gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c to create a server certificate. ProvidingI import the certificates into all the right stores everything works on my machine with no alarms.

This changes when other people on the network access the web apps (the API calls are all within my development box). Dire warnings are received by the user. I tell them to ignore these warnings and, where possible and sufficiently straightforward, import the certificates. Because these self-signed certificates have the same issuer name and common name, each new web app triggers an warning page

I can't help thinking that asking users in one's organisation to go through warning pages is a bad idea.

As a non-specialist in security, there's a couple of things I'd like to see:

• the ability to have a local root certificate for all the development certificates that I create and then be told an authorised way of importing that into PCs, Macs, Android, iPad and iPhone devices, so that these alarming pages no longer occur

• an easier method of generating certificates for APIs that can be used with IIS and Kestrel that populates all the correct certificate stores correctly

@CrispinH To be honest supporting a root CA would be, well, a concern of spinning up a root CA. If you're at that point then it's time to consider spinning up a root CA yourself and managing it. The self signed support, either though the global tool or my script is just for that, development. Once you start letting people attach to it you're outside of the scope for that feature. If you're in an organization and want people to access services then the organization needs to figure out their certificate strategy, running an internal CA via Windows or OpenSSL and pushing the root out via AD policy or other means.

@blowdart One of the reasons for my bleat was that I'd spent a couple of days trying to spin up a root CA and failed to get it right though lack of competence in this area. I even tried to work out how to modify your gist to accept a local Root CA.
All the documentation I found was far too general - all I wanted was a process for creating certificates (ideally based on a Root CA) solely for protecting APIs and web apps with a server certificate. Perhaps specific-case documentation is all that's needed.

@CrispinH Window Server comes with a Certificate Authority that you can set up, if you want to go the full way.

Certificates in general are not an easy topic and you will have to learn quite a bit to do it right.

For dev purposes, self-signed certificates are totally fine and easy to use. Everything beyond that, including setting up and managing a CA, is no longer for development purposes and definitely out of scope and far too complex for a web application framework.

@CrispinH As @poke said it's hard to get it right. Once you have machines trusting a root CA then any certs issued will be trusted, And devs run untrusted code on their dev boxes, that's what nuget packages are after all. So consider something that steals your root CA. In real life Root CAs tend to be kept offline, they sign a second certificate, which is constrained in what it can do, Server and Client certs usually, and then certificates are issued by that, by contrust lots of dev CAs are constrained, so compromise would mean the ability to issue trusted code signing certs. Without meaning to be horribly insulting a CA is not something a dev should be running, it's best left to those that understand the consequences, and the consequences can be dire. Then there's certificate rotation, revocation, OCSP and more to consider. I have to have a test CA for my certificate auth middleware, and it's in a VM that's turned off. I get very nervous when I turn it on to get more test certs.

If you truly, really, want to go down this root (pun intended) then https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ might get you started in powershell, but that gives you no CRL or OCSP or revocation support. https://gist.github.com/Soarez/9688998 appears to cover OpenSSL. And if you need CRLs then there's the CA built into windows, setting this up is documented here https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/

_Note that I haven't used any of the links above (although I trust the author of the last one), and in no way is this any type of official MSFT recommendation. The official recommendation of the ASP.NET security team is let someone who understands infrastructure and risks set up a corporate CA for you. Talk to your IT department_

@blowdart No I really _don't_ want to go down that 'root'. It's nice to know why now.

It looks like my humanoid testing will have to be done on the public internet on a test host using Let's Encrypt certificates, but with an authentication wall in place to keep away prying eyes.

Depending on what you need and your budget, some companies like DigiCert offer managed PKI services. That can use a private root or their public one. I don't know the costs.

And if it's only HTTPS remember you get a cert for every azurewebsites.net subdomain.

Weighing in on the new OpenID implementation, instead of yet another implementation to learn, embrace and engage with the community efforts of IdentityServer4 and contribute to create an opinionated IdentityServer "Lite" version that could be included from nuget and setup with minimal efforts.

You are all overreacting.
The ASP.NET team is already thinking like all of you. @DamianEdwards talked about it in the most recent Community Standup.

Here is the most relevant part (but I encourage you to listen to all of it):

"We are actually talking to the IdentityServer folks about that now."
https://youtu.be/Tzh2EXwgEk8?t=25m15s

Really interesting to see how passionate the discussion around the "MSFT authorization server" project is :smile:

Incidentally, Vittorio Bertocci contacted me exactly 2 years ago to chat about this project as they were considering using OpenIddict (the OIDC server I develop and maintain) as a base for this project.
Last year, I was told they preferred going with their own implementation instead of leveraging third-party OSS as it was considered "too strategic" from a business perspective (which is something I could understand).

I'm glad to see they changed their mind and are finally considering using an existing OSS solution like IdentityServer4 instead of creating another thing from scratch: it's a very good signal sent to the .NET community :clap:

This goes a bit off the thread, but @CrispinH, it looks like you're looking a bit of https://stackoverflow.com/questions/51123289/how-to-generate-a-response-to-a-csr-in-net-core-i-e-to-write-a-csr-signing-se. .NET Core 2.0 includes other facilities to create and work with certificates too. See the comments about running a CA too. The library tooling is almost there and depending of your organization, you might be able to use certificates in some controlled fashion in some server without setting a lot of intrastructure. On that token, reading (DER encoded) certificate signing requests (CSRs) out-of-the-box would be a nice addition -- along with a JSON-LD library. And more crypto in general. :)

I’d love to see some middleware like support for LetsEncrypt - working with App Services in Windows, Linux and Docker in Azure.

@kieronlanning I agree, in addition to the DER encoding with regards to CSR signing mentioned earlier (albeit adding support without edge cases doesn't look like that difficult). There's a few libraries for .NET (also listed on Let's Encrypt pages), but also a bit of trouble. For instance, the most actively maintained .NET with regards to Let's Encryptc one looks like being Certes, but it takes a dependecy on BouncyCastle. It would be nice if someone helped it to to be .NET Standard 2.0 only. One reason for me is that it BouncyCastle doesn't work nicely with Orleans TaskScheduler. :)

About the crypto mentioning, though not strictly a ASP.NET Core issue, MS seemingly is pushing heavily on blockchains, but .NET lacks on crypto ability. _On the surface_ a lot of this has to do with ASP.NET core too (like, for instance, the various blockchain explorer implementations, such as https://etherscan.io/) and it'd be nice to have more support to libraries like like Inferno and just more abilities baked into the platform. One outstanding issue is at https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment-395778931 (lending some eyes here if someone has the chops to help).

This from @kieronlanning would be my number one feature request:

"I’d love to see some middleware like support for LetsEncrypt."

Here is the open issue: https://github.com/aspnet/Home/issues/1190. Please do go and upvote it.

Is it being considered messagepack to be available on asp.net core to all frameworks and not only on SignalR ? Since Http2 framming is binary are you considering messagepack for that ?

authorization server released on preview3?

It already exists. Https://IdentityServer.io

@leastprivilege
I like and use IdentityServer
But I'm very curious to see the Microsoft implementation and and understand why (microsoft) did not incorporate the identityserver in your core

@danroth27 - can you share the latest?

Microsoft is using IdentityServer.

So how is this working? Microsoft uses IDS4 code directly? Microsoft trims down IDS4 features? What's the model here? What should be our expectations? Is there a possible migration path between them?

Microsoft will use our standard nuget package and use our configuration API to give you some default settings to play nice with the template and ASP.NET Identity. That's all.

You can achieve the exactly same thing today already.

It's probably me, but I'm surprised to read that the gap of Microsoft authorization server is filled by IdentityServer4. As per my understanding the main concern of IdentityServer is authentication, not authorization.

For me IdentityServer is fine as authentication server, but doesn't work as authorization server. I assumed that that was the reason that PolicyServer was created.

@leastprivilege Will IdentityServer be extended with something like PolicyServer?

@Ruard So its confusing (and Dominick will probably cringe or pick on my explanation).

OAuth is authentication, but it has authorization as it's first step, and then issues a grant based on scopes etc. So, in our wrapping, Identity Server will perform the login, validate it, validate the scopes required (which in the initial case will always succeed because we're using the default scope), then pass a token back to the caller, which is then sent to the API which will validate it, and then, optionally, you can go further with authorization rules within the API. OIDC provides OIDC confused it further by being a way to acquire a user's identity information, including authorization that the app is allowed to have it ...

So, basically, Identity Server will give us an identity, authorizing that the app is allowed to have it, and then you can use ASP.NET's authorization pieces to further control access.

@MichelZ there will be a grow up story. We'll configure for simple scenarios, and once you go outside those you can explore the full power of the IdentityServer configuration model.

@blowdart We already use IdentityServer (and are impressed with the capabilities!), however getting the benefit from Microsoft's "long-term-support" policies is also a big plus for us. So whichever synergies you can provide here are very much welcome.
We love both products, ASP.NET Core and IdentityServer (4) the same way. It's definitely a step into the right direction IMHO.
However, we also recognize that all these protocols are not exactly "straight forward". They arent't rocket science one you understand them, but still, they aren't straight forward either.

I wish someone would invent a REALLY simple protocol, leaving behind ALL legacy implementations and focus on the future.

If you're already using it, then your use won't really change, you have it working :)

We're aiming at File New > Web API with Individual Authentication, and then adding other APIs, and everything is convention based. That's not going to work for existing apps, because the conventions will be new. I wouldn't plan to replace your config with ours :)

I wish someone would invent a REALLY simple protocol, leaving behind ALL legacy implementations and focus on the future.

This is the problem -- apps are getting more complicated not less. To secure them, the security is also complicated. I've always pushed back when I hear people say that IdentityServer is complicated -- it's not. It's your application's security requirements that are complicated. Often people don't have the perspective to recognize that.

Yes, it's working - and it's working well - but still, that additional assurance it (may) give you, when Microsoft officially "endorses" and ultimately "supports" a technology is pure gold.... !
You have been lifted onto a whole new level!

@brockallen Yes, applications probably complicate things a LOT. However, the OIDC protocol undeniably inherited some stuff from OAuth 2.0 that it would better have shook off. Some of your teammembers (I think it was @leastprivilege) said that if OIDC would be developed from the ground up, it would probably look fairly different from what we have now.

I'm not saying what we have now is "bad", I really appreciate what we have, and it's really functional for our purposes, and I hope everyone involved in the creation of it is proud of the work they did!

@Team;
For preview 3, could you please provide some detail docs on the "Authorization Server" and how it will function using with Web API and client side JS, like Vue?
We need to make a decision and this preview on the Authorization Server is a critical preview and any detail docs will give us info on our decision.

Thanks!

As discussed before

https://identityserver.io

Just noticed also U.S. open data APIs are in JSON-LD: https://project-open-data.cio.gov/v1.1/schema/ . This seems to be a rapidly growing trend, so a well resourced JSON-LD .NET library used with ASP.NET would be nice. :)

@veikkoeeva So are (at least part of) the NuGet APIs. They're using json-ld.net, no need for another library.

@khellang And there are other libraries too, this particular library could use maintainers (https://github.com/linked-data-dotnet/json-ld.net/issues/26). I realize it's open source and in theory I could step in to contribute, but for the time being at least I'm spread too thin to help with this. Put otherwise, perhaps, I'd like to bring this into attention that a lot of data sets seem to be moving towards semantic formats and it's not clear how to efficiently work with that using .NET.

IMHO, add IdentityServer4 to the core of ASP.Net Core is a bad idea.
Please don't make the .NetCore as a monolithic framework.
.NetCore is there and IdentityServer4 is there , people make the architecture base on own's authentication and authorization needs.

@mikeandersun The plan is only to have an easy default configuration that you can add to your project to make it work out of the box.

You can still not use it, and it won't affect you. You can still use IdSrv and fully configure it yourself. You can still choose what components to include in your project. None of this is making ASP.NET Core monolithic.

ASP.NET Core != .NET Core btw.

Will 2.2 be an LTS release? (Asking if it's already been announced, not asking you to make a new announcement.)

@yzorg no that has not been announced. That determination is often made after release based on quality/stability.

@blowdart , would this template provide identity server with an Web app MVC client instead of an API?

@Ponant No. It's aimed at APIs only. We'll reevaluate that in the 3.x timeline.

Interesting... This question came up in a meeting yesterday. If we build a full "MVC" project without the use of Web API, can we use the new ASP.Net 2.2 IS4 template that is integrated in 2.2?
Looks the big boss (Barry) just answered the question.

@blowdart allias big boss: why isn't that done in one shot? It seems trivial at first sight to use an mvc client or a web api talking to a asp.net core identity IS4 server.

@Ponant Because we don't have infinite resources. What features would you have liked us to drop in order to put everyone on changing a major part of MVC flow which wouldn't give any new features, just change how an existing one works? An individual authenticated API has been a gap between full framework and ASP.NET Core. The focus of work was on filling that gap. Identity Server already has working templates for MVC with Identity Server as the "core".

@CrispinH @blowdart I agree with you whole heatedly, User Administration, Roles, Tenancy and User-Groups is needed desperately. Look at this - there are 7 Uservoice tickets all complaining about this hundres of developers and companies. Sadly many other tech like Java blueRay portal JSR 182 or 173 such a beautiful job here!

--> So many requests for user/groups/tenant management

--> AGAIN here people complaining ... it goes on, even on twitter and facebook.. this is the reason - why other platforms like WP and PHP are easier!

While @manigandham believes identity server is a great fit, they charge A LOT for the GUI administration tool and its not cheap for many countries and developers, it also goes against the low TCO developer. How many people can really afford this. It has been a HUGE obstacle and step back, a basic vanilla functionality and GUI to manage the Users/roles/Roles-User_groups/Tenants is needed, which can then be enhanced by the developer

@papyr Why don’t you just start an open source project for this? A full GUI for everything does not need to be built into the framework (templates). And just seeing how difficult it already is for the team to keep the templates updates e.g. with changes to Bootstrap, I don’t really want them to waste more effort on that. But on the other side, I totally get that this would be a useful thing to exist, so why don’t you just make this a community effort?

@papyr @poke no need for a new open source project, there are excellent existing projects.

If you want something open source from MS designed to compete with WordPress then look at Orchard:
https://github.com/OrchardCMS/OrchardCore

If you want more of a library approach instead of a framework check out cloudscribe, which has nugets for multi-tenancy and user and role and claim management ui pre-built with an optional identityserver4 integration and optional cms (cloudscribe.Simple/content) as additional nugets.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

If you want something open source from MS designed to compete with WordPress then look at Orchard:
https://github.com/OrchardCMS/OrchardCore

I second this recommendation.

And Orchard Core is designed to be extremely modular. For example, it is possible to extract just its multi-tenancy module and use it in your own projects. It also already has modules to manage users & roles, and I'm sure they would appreciate your contribution to make it even better.

You can watch a lot of demos of its various features on their channel.

@papyr Why don’t you just start an open source project for this?

https://github.com/IdentityManager/IdentityManager2

This UI thing can be tricky, albeit helpful to get basic things quickly. It seem recently I've come across cases building the UI isn't the biggest task, but figuring out how to fullfil the "process needs" such as pre-approving some emails (that do something application specific), calling APIs that call APIs, some of which might mean joins in the database or calls to somewhere else etc. and then adding them to tokens and UI logic.

So having good tutorials such as https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html or those at https://mcguirev10.com/page2/ feels more important than UI (especially if one can't or doesn't want to use EF). Then maybe search for UI for one's chosen tech (Aurelia/Angular/Razor/React/Vue etc.) and how they implement some data handling.

On naming projects and names, besides @scottbrady91, I've found it very educating to check @LindaLawton, https://github.com/abergs/fido2-net-lib (@abergs, @aseigler), @TomCJones, @mackie1001 (Gitter) etc. to provide additional explanations and code to peek into when stepping even a bit outside of the basic need. I've forgot to add some names and projects. :)

Why cant .net core have normal razor web pages? When I do complex reports I like doing all from a single razor (c#) page. Or at least the ability to use just a view at times only with no model or controller.

In other words the basic ability to connect to sql in the view and receive GET and POST request, sanitized of course, I currently use a class called Striptag.cs.

Why cant .net core have normal razor web pages?

You can use Razor pages for this https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio

Having a backing page model class is optional; you can just have a single page

benaadams thanks for the answer, how would I use GET and POST request directly in a razor page, and make a basic connection to sql server. The connection for regular queries, not ado entities, or linq, or ORM. I always prefer normal queries.

Like:

var msql = "SELECT * FROM customerss WHERE lastname LIKE @0 ORDER BY lastname OFFSET " + thisoffset + " ROWS FETCH NEXT 5 ROWS ONLY";

I know the connection string is in a json file now, but don't know how to use it in view. Some things aren't deeply documented.

Well, it has a learning curve. If you want to fetch data _before_ loading the view, you do it in the corresponding action. So, for HomeController.ViewReports action and Views/Home/ViewReports.cshtml page you write:

public class HomeController
{
  public ActionResult ViewReports()
  {
    // fetch data from the SQL using...something...
    return View(data);
  }
}

If you want to fetch data _after_ page load, you typically use AJAX requests to some pure GET/POST endpoint that returns JSON formatted data.

Can still do it on a page without any controller or action; something like

@page
@using System.Data.SqlClient
@using Microsoft.AspNetCore.Http
@using Microsoft.Extensions.Configuration
@inject IConfiguration Configuration

@{
    var lastname = Request.Query["lastname"];
    if (!string.IsNullOrEmpty(lastname))
    {
        var offset = 0;
        var count = 5;
        if (Request.Method == HttpMethods.Post)
        {
            int.TryParse(Request.Form["offset"], out offset);
            int.TryParse(Request.Form["count"], out count);
            count = Math.Min(count, 50);
        }

        var connectionString = Configuration.GetConnectionString("MyConnectionString");
        using (var conn = new SqlConnection(connectionString))
        {
            using (var cmd = new SqlCommand(@"
            SELECT * FROM customers
            WHERE lastname LIKE @lastname
            ORDER BY lastname
                OFFSET (@offset) ROWS
                FETCH NEXT (@count) ROWS ONLY"))
            {
                cmd.Parameters.AddWithValue("@lastname", lastname);
                cmd.Parameters.AddWithValue("@offset", offset);
                cmd.Parameters.AddWithValue("@count", count);

                await conn.OpenAsync();
                using (var reader = await cmd.ExecuteReaderAsync())
                {
                    while (await reader.ReadAsync())
                    {
                        <div>@reader["lastname"]</div>
                    }
                }
            }
        }
    }
    else
    {
        <div>Nothing chosen</div>
    }
}

I have used mvc asp.net and webforms and old razor pages, so I am not new to this. I have spent 3 hours and still cannot get a simple test razor page to work, I have:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title></title>
</head>
<body>
    <form id="petform" method="post" action="pets/razdb3">
        <input type="text" name="psearch" id="psearch" />
        <input type="submit" />
    </form>

</body>
</html>

Just an html page and loads.

Model

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace petnewtry.Pages.pets
{
    public class razdb3Model : PageModel
    {
        public string myvar { get; set; }

        public void OnGet()
        {

        }

        public void OnPost()
        {
            myvar = Request.Form["psearch"];
        }
    }
}

View:

@page
@model petnewtry.Pages.pets.razdb3Model
@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>razdb3</title>
</head>
<body>
    <div>@Model.myvar</div>
    <div>hello</div>
</body>
</html>

3 hours and all I get is a blank page. I tried a return statement, etc

If I just type in http://localhost:51307/pets/razdb3 I get the second divisions "hello", but
the @Model.myvar I get nothing.

I am new to .net core, and would have never imagined it would or could be so hard to simple display a razor page.

In VS community 2017

the @Model.myvar I get nothing.

You set the myvar value on a post request (OnPost) with from the form value psearch; so you'd need to make a POST request with that value to set it?

In the GET request (OnGet) which you get from just navigating to the url from the browser; rather than a form postback isn't not being set to anything.

Try setting it to a default value so it shows up when you don't set it to confirm the model is flowing through:

public string myvar { get; set; } = "Not Set";

Changed to

public string myvar { get; set; } = "Not Set";

And still a blank page. Is @Model.myvar correct?

even changed to

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace petnewtry.Pages.pets
{
    public class razdb3Model : PageModel
    {
        [BindProperty]
        public string psearch { get; set; }

        public void OnGet()
        {

        }

        public void OnPost(string psearch)
        {
            psearch = Request.Form["psearch"];
        }
    }
}

@page
@model petnewtry.Pages.pets.razdb3Model
@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>razdb3</title>
</head>
<body>
    <div>@Model.psearch</div >
        <div>hello</div>
</body>
</html>

It builds fine no error, but a blank page no matter what I try.

Polite commentary/thoughts: feels like this discussion on "normal razor pages" is starting to get a bit off topic with respect to the subject of this thread.

😊 😊

Sorry, I realize I should have used the forum. Thank you @benaadams your code got me on the right track and I found this:

https://www.c-sharpcorner.com/article/razor-page-web-application-with-asp-net-core-using-ado-net/

This is how I normally did stuff anyway, using the "new" key word, like

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

It was reassuring to see you could still use custom classes in .net core.

You have to admit, .net core has a steeper learning curve than some prior asp.net frameworks. Thanks so much.

The release notes talk about an "Authorization Server" feature to be expected as add-on in the upcoming months. Is there more information available about this feature? I'm trying to decide whether we should wait for it. Or build our own solution.

The release notes talk about an "Authorization Server" feature to be expected as add-on in the upcoming months. Is there more information available about this feature? I'm trying to decide whether we should wait for it. Or build our own solution.

I think the current plan is to use https://github.com/IdentityServer/IdentityServer4 in a "pre-packaged" way.

Following the notes from IS4 team and MS security team, it seemed like MS was simply trying to do a quick & dirty packaging of IS4 and call it the day. But looks like someone with more wisdom, decided to hold back and do it the right way, as security can create ripple effects when it is not done right.

I hope a full integration between IS4 and ASP is made to support BOTH Web API and MVC.

In these days and industrial strength authentication/authorization is required as a bare minimum. Open Source (OSS) is fine for most things but there have been serious misgivings in some OSS security products that are not acceptable in any enterprise website. 85% of projects use outdated libraries that are unacceptable security risk. For example, 45% web servers use Apache (https://www.cvedetails.com/vendor/45/Apache.html) which has far more vulnerabilities than IIS (https://www.cvedetails.com/product/3436/Microsoft-IIS.html?vendor_id=26). Products such as Identity Server may be fine but developer tweaks may render them completely insecure. We need a solution built into Net Core that is always safe...

In these days and industrial strength authentication/authorization is required as a bare minimum. Open Source (OSS) is fine for most things but there have been serious misgivings in some OSS security products that are not acceptable in any enterprise website. 85% of projects use outdated libraries that are unacceptable security risk. For example, 45% web servers use Apache (https://www.cvedetails.com/vendor/45/Apache.html) which has far more vulnerabilities than IIS (https://www.cvedetails.com/product/3436/Microsoft-IIS.html?vendor_id=26). Products such as Identity Server may be fine but developer tweaks may render them completely insecure. We need a solution built into Net Core that is always safe...

Your point is absolutely correct. But in some videos, MS staff had said, that they're not going to reinvent the [security] wheels and use a third party [IS4] system. So I'm hoping this will be a win/win situation for all of us.

In these days and industrial strength authentication/authorization is required as a bare minimum. Open Source (OSS) is fine for most things but there have been serious misgivings in some OSS security products that are not acceptable in any enterprise website. 85% of projects use outdated libraries that are unacceptable security risk. For example, 45% web servers use Apache (https://www.cvedetails.com/vendor/45/Apache.html) which has far more vulnerabilities than IIS (https://www.cvedetails.com/product/3436/Microsoft-IIS.html?vendor_id=26). Products such as Identity Server may be fine but developer tweaks may render them completely insecure. We need a solution built into Net Core that is always safe...

Nothing is "always safe", especially not something from Microsoft ;)
It's always in the hands of the user of these things to make it and keep it safe.

IdentityServer will be included in new templates shipping post 2.2. The initial focus will be API access control - but there are plans to expand that in the future.

ASP.NET Core will ship with a simplified config API that covers the template scenarios only - but will be very easy to get started. You can at any point transition to the IS native config system which gives you advanced scenarios.

IdentityServer will be included in new templates shipping post 2.2. The initial focus will be API access control - but there are plans to expand that in the future.

ASP.NET Core will ship with a simplified config API that covers the template scenarios only - but will be very easy to get started. You can at any point transition to the IS native config system which gives you advanced scenarios.

Thanks for the information Dominick;
I thing this "Stepping stone" will help many to get started and then transition to full IS. Good move.

IdentityServer will be included in new templates shipping post 2.2. The initial focus will be API access control - but there are plans to expand that in the future.

ASP.NET Core will ship with a simplified config API that covers the template scenarios only - but will be very easy to get started. You can at any point transition to the IS native config system which gives you advanced scenarios.

Good to know! Thank you.

I guess this API access control will be based on OAuth scopes?
No direct support for more volatile user permissions like described at policyserver.io?

IdentityServer will be included in new templates shipping post 2.2. The initial focus will be API access control - but there are plans to expand that in the future.
ASP.NET Core will ship with a simplified config API that covers the template scenarios only - but will be very easy to get started. You can at any point transition to the IS native config system which gives you advanced scenarios.

Good to know! Thank you.

I guess this API access control will be based on OAuth scopes?
No direct support for more volatile user permissions like described at policyserver.io?

PolicyServer is commercial solution

I guess this API access control will be based on OAuth scopes?
No direct support for more volatile user permissions like described at policyserver.io?

"Only" IdentityServer. ASP.NET Core has a built-in API for user authorization - and if PolicyServer (the product) looks interesting to you, let me know.

Closing this issue because ASP.NET Core 2.2 has shipped.

should this not be updated to ASP 3.0

Any update on when the Authorization Server enhancements will ship?