glennc commented 6 years ago

Discussion for the 2.2 Roadmap announcement: https://github.com/aspnet/Announcements/issues/307

iAmBipinPaul commented 6 years ago

What about EF Core 2.2 Roadmap?

benaadams commented 6 years ago

What about EF Core 2.2 Roadmap?

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

RehanSaeed commented 6 years ago

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!

tpeczek commented 6 years ago

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

arishlabroo commented 6 years ago

Regarding the dispatcher, will this be possible in the middleware then? 😱

public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)

^{[FromQuery]? 🤔}

imranbaloch commented 6 years ago

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

poke commented 6 years ago

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.

SIkebe commented 6 years ago

What about IIS in-process hosting?

stefan-schweiger commented 6 years ago

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)

RehanSaeed commented 6 years ago

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.

manigandham commented 6 years ago

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.

NickCraver commented 6 years ago

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!

RichiCoder1 commented 6 years ago

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.

kieronlanning commented 6 years ago

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.

willdean commented 6 years ago

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?

veikkoeeva commented 6 years ago

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. :)

JamesRandall commented 6 years ago

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.

CrispinH commented 6 years ago

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.

h0useRus commented 6 years ago

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

ThatRendle commented 6 years ago

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?

yaseralnajjar commented 6 years ago

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

alhardy commented 6 years ago

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?

poke commented 6 years ago

@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.

manigandham commented 6 years ago

@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.

yaseralnajjar commented 6 years ago

@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):

HATEOAS (self discoverable api)
Media Types (setting up custom media types)
Versioning (update mediatype version)
Mainpulated data metadata (pagination into X-Pagination header, filter metadata... etc).
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.

khellang commented 6 years ago

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

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

poke commented 6 years ago

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.

yaseralnajjar commented 6 years ago

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: ?

alhardy commented 6 years ago

@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?

joeaudette commented 6 years ago

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.

yaseralnajjar commented 6 years ago

@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/

khellang commented 6 years ago

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 😕

manigandham commented 6 years ago

@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.

edandersen commented 6 years ago

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.

khellang commented 6 years ago

@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.

edandersen commented 6 years ago

@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.

joaopgrassi commented 6 years ago

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?

kieronlanning commented 6 years ago

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.

yaseralnajjar commented 6 years ago

@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.

VictorioBerra commented 6 years ago

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.

khellang commented 6 years ago

"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:

NeelBhatt commented 6 years ago

Awesome features :)

Where can I get more information for Health check feature?

CrispinH commented 6 years ago

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

blowdart commented 6 years ago

@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.

CrispinH commented 6 years ago

@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.

poke commented 6 years ago

@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.

blowdart commented 6 years ago

@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

CrispinH commented 6 years ago

@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.

clairernovotny commented 6 years ago

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.

blowdart commented 6 years ago

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

dotnet / aspnetcore

2.2 Roadmap discussion #3265

Update