ASP.NET Core Identity as a service #1187
Comments
|
When the title here says "service", do you mean an HTTP-based API on ASP.NET Identity, or is this issue just a general feature list for the already developed Azure on-prem STS as mentioned here: https://twitter.com/PinpointTownes/status/857772475400290306 and several times on the ASP.NET Community standup? If it's an HTTP-based API on ASP.NET Identity, then I think this is a great feature! So many apps need decoupling from the in-memory only programming model of ASP.NET Identity. If it's the on-prem STS, then in the past I've heard this positioned as "a STS where your client app can just change a URL and use any STS you want", but these two things:
will make it product specific, and thus the client application code is also then tied to the Microsoft STS product(s). If this is publicized as the goal (and also the constraint), then fine. But if it's positioned as compatible with any other OIDC token service, then it will be misleading. If the client apps (I guess in the templates) use client libraries that were OIDC RP certified (https://openid.net/certification/#RPs), then you'd have a more believable story for compatibility. So can we get official clarification on some of these questions? I think it would help the community in evaluating their options. |
|
This is only about adding limited OpenID Connect support to ASP.NET Core Identity that aligns with Azure AD B2C, not adding a broader HTTP API over all of ASP.NET Core Identity. Client apps use the standard OpenID Connect and OAuth 2.0 flows for interacting with ASP.NET Core Identity. |
|
So in short, this "service" is a package that implements OIDC and uses ASP.NET Identity internally to manage the identities, and this OIDC server will behave exactly as Azure B2C? Is that a fair one-liner summary? |
|
Yup, the goal here is to build an aligned identity story across in-app, on premise and cloud scenarios. We want to make it easy to migrate from ASP.NET Core Identity to using Azure AD B2C as a cloud identity service. That said, Azure AD B2C itself produces OIDC compliant messages and we will too, so you can just as easily decide to use any OIDC provider you want (like IdentityServer4, or OpenIdDict). |
While technically correct (and this also includes any other OIDC implementation), each has their own programming model, assumptions, and features. So just because they all do OIDC, it doesn't mean they all do the same thing or provide the same features for you or your security architecture.
So yes, thanks -- I think this clarification is helpful so people can make an informed decision. |
|
Personally, the main concern I have is that the project names you've chosen are way too generic for what appears to be basically a limited "B2C emulator" (credits go to @leastprivilege for the name!) or an "on-premise B2C server". Why not adding the Azure(AD) moniker in the packages name if that's really what it is?
Another (cool) option to consider would be to decouple the OIDC handling part from the abstractions/core components (like the token primitives or the applications/tokens stores), that wouldn't be tied to any OIDC implementation and could be reused and plugged into existing stacks like IdSrv or ASOS. |
|
Yeah, we've considered putting B2C in the name to make this clearer, but then folks might think you're actually using B2C, when you're not using B2C at all. We've definitely open to refactoring things so that they are more generally usable. Can you share more details on what factoring you'd like to see? |
|
Then call it B2C on-prem, or non-cloud B2C, or non-cloud Azure on-prem B2C or some such. If you give it a generic name, we'd not want people getting confused about what they were really getting. As we know, confusion on this platform is already at an all time high. |
|
We're open to this. We just need to come up with a name that signals alignment with B2C, but not usage of B2C. Will discuss more after BUILD is over. |
|
B2C Emulator - isn't that what it is? |
|
Refactoring doesnt make sense to me. We certainly wouldn't use it - and you are not building a framework. In spirit this is a closed source product. I mean - it needs to mirror the exact feature set of a closed source product. So why even open sourcing it? |
There is still value in making the code open source. By making the code open source you can read the code, debug it, build it yourself, incorporate it in your own projects, contribute bug fixes, fill in feature gaps, etc. Not all open source projects will have or need to have an open ended community driven scope. Some projects may have a fixed scope, even a scope tied to a particular business strategy or commercial product, and that should be ok. |
when you say much simpler you meant this?
|
|
That's the identity code, which certainly isn't simple, but I was referring to the actual app code. The app code for most of our templates consists of a single HomeController with Index, About and Contact views. If you enable authentication today then a good chunk of the identity code gets intermingled with your app dwarfing the actual app logic. By separating out the app code into an area and wrapping it in a standard service interface your app and the identity code are decoupled to the point that you can delete the entire identity folder and replace it with an out of process identity provider of your choice. We plan to simplify the identity code as well. All the code in the Extensions folders we plan to move into framework packages. We want to revisit how email confirmation and two factor auth get setup to make it simpler and purely additive (no more dummy IEmailSender and ISmsSender interfaces). We are also looking at ways to package the controllers and views so they don't have to live in the template. |
|
@danroth27 thanks for the reply and eager to see the improvements coming. Btw, speaking of "We are also looking at ways to package the controllers and views so they don't have to live in the template." This is something that would be useful for a lot of scenarios! Whatever option you enable or recommend that we developers can use is very welcome. I was waiting for something to do exactly that for a looong looong time already. |
|
We might do something targeted for the identity controllers and views (still under discussion), but if you're looking for a more general purpose solution you should check out the sweet modules framework the Orchard folks built on top of ASP.NET Core for Orchard Core: https://channel9.msdn.com/Shows/On-NET/Sbastien-Ros-Modular-ASPNET-apps |
There's even a built-in OpenID Connect module designed by @jersiovic (that uses OpenIddict under the hood) @danroth27 any idea when the IdentityService repo will go public? |
|
@danroth27 I started playing with the new VS templates and it looks like there's now no way to create a Web API/APP using Identity (aka "individual authentication") without the B2C emulator, which is of course a real PITA. Is there a plan to fix that? |
|
What issues specifically are you running into? We want the app decoupled from its identity concerns by default so that you can easily swap to a different identity provider. |
please don't and keep the discussion going. With all the respect to Orchad and what they have implemented which indeed looks awesome. The need to reference two different packages, inject services, have a middleware running to get the concept of modules on an application may be fine but not to package a library with controller(s) and view(s). (As clearly is your scenario and many others). I strongly believe this is something missing from asp.net framework, and I would love to see First Class Citizen support for this, the fact that you need this also kinda proves my beliefs. |
That's also what I want. I don't want to have an embedded B2C emulator when I have actually no plan to use OIDC at all in my Identity-based app. There should be a new option the individual authentication dropdown list offering you to create a "local B2C server". |
|
@PinpointTownes We only plan to offer two options for authentication with individual user accounts: in-app or cloud. Having a third option would leave the user with a confusing choice. The use of OIDC for the in-app case has the benefit of allowing the user to easily swap out their identity provider and it is largely transparent to the user. |
|
@Bartmax Whatever we do for identity for the controllers and views we will make sure it's something that anyone can do. |
In-app means the same as we have today in VS2017, right? Or if this only means you only allow the B2C emulator, then what about those projects that want to build their own STS using ASP.NET Identity? |
Meh. It makes absolutely no sense to use a local OIDC server when you know you don't want to use a remote identity provider. What I want is a template similar to the existing Identity template (in VS 2017). |
Nope. When you select individual authentication with in app users store, the B2C emulator is automatically added and you have no way to avoid that. |
Well, then, that's wrong. This is like saying you'd force the MVC template to only run in Azure App Fabric. |
Not at all! The only thing the app is tied to is OpenID Connect (and a limited amount of OIDC at that). There is nothing in the template that is tied to B2C or any other Azure specific service. This means that you can easily switch to any OpenID Connect provider (like IdentityServer4 or OpenIdIDict). This setup allows for more choice, not less. |
|
Your calculations comes to one half cent per user, per month. If it's a totally free app with several million users, I can see the case for rolling your own auth. But that seems pretty reasonable to me for a paid app. |
|
Yep. If they drop the price they could gain more adoption and become a defacto for Identity. And make it far easier on the dev community by having one place to turn for Identity. Just look at the costs for Azure Functions. An execution is next to nothing by comparison. Why is Identity so expensive? A stored user cannot take that much disk space and an authorization should be on par time and resource wise as an Azure Function call. You can get 10 million Azure function executions (assuming under 1 sec and less than 128kb) for $13.60/month. Azure AD B2C just seems way over priced to me as compared to other Azure cloud services. |
|
You will always have considerably more Azure B2C authentications than 1 per user per month, even if a proportion of your users are using a third party such as Facebook, with long-lived access tokens. Refresh tokens could kill you if you are not careful. Not requiring people to periodically re-authenticate is fraught with problems. When going B2C, you have to allow for cost to rapidly increase, and switching identity providers means downtime / risk. Iv'e contracted for several startups that went under because they were popular, but they hadn't planned the cash flow / cash burn, while building a potential customer base. Compare the above cost estimated by @chassq - $4,005.00/month. (thanks for that) which assumes the very low active authentication rate of 1 per month. Hosting my own IdentityServer on an auto-scaled App Service, Standard Level, even with 3 permanently running S1 instances that never auto-scale down during quiet periods, will cost me an initial $223 per month (database costs added below), and can easily handle the same load and scale to peak demand. In practice it would be less due to auto scale down. Combining that with Cosmos DB (DocumentDB) using: $320.57 So, total cost $543.57. And capable of dealing with 10s of millions of user profiles, and 100s of millions of authentications each month. Double that price if you want Geographic Region Failover. Still considerably more performance for a quarter of the cost. With the spare $3000 per month you can add as many regions, load balancers, traffic managers as you want. Or load it into a Redis cluster with the CosmosDB for permanent storage. Azure B2C for 1 million user accounts (which is not much for B2C), and only 5 authentications (and don't forget those refresh tokens - each is another chargeable 'authentication') per user, per month, is $12,105.00. $145,000 a year for logging in might be lost amongst all the other costs. For me its not acceptable. And you still wouldn't be able to login at your own domain name. If users choose login with username and password as they want to use their password managers... oh dear! eCommerce - start adding up those multi-factor authentications ... boom. Seriously, feel free to spend more than you need to if you wish; perhaps you have a high margin product, and no investors wanting to minimise your spending of their money. Every cost adds up and eats into profitability; especially during the growth phase of a startup. |
|
Just to be clear, Auth0 is kind-of the same stupid 💸 pricing model. I wish I could use xxxx (insert name Azure, Auth0, whatever) for identity. |
|
@chassq multi-factor is sms based; which has a 3rd party cost per auth. You are better using the authenticator app version for 2fa that's in 2.0 (also advised to use it instead of sms based 2fa as per current security advice) so that shouldn't be a cost worth worrying about? |
|
@danroth27 , any idea on when Identity as a Service will come up now that it is removed from 2.0? |
|
It's being actively developed, but when it will ship is still TBD. |
|
@danroth27 Can I beta test it for you? |
|
There's no beta to test yet. It's still very much a work in progress. |
Turns out that building a token service is a lot of work :) |
|
That's why I admire the people that open-source theirs... |
Well, OSS is not free and not typically a charity. You have to evaluate the motivations of those that do. Ours is to sell consulting and services. Microsoft's is to sell Azure. |
|
The difference being I can use your OSS without paying for the optional consultancy... and assess the quality of it's implementation, compare it to OpenIddict for example. I can also submit fixes. You put it all out there for everyone to look at, if you pardon the expression... |
|
Sure, but Microsoft will (if not already) OSS theirs. The most important thing, which you've somewhat gotten at, is what's the right token server for you. If you plan to use and move to Azure B2C, then I suspect the Microsoft one will be the right choice. But if you're not sure, or you need more features or flexibility than Azure B2C, then the Microsoft token server will probably not be the right choice for you. I hope Microsoft has the courage and honesty to be very clear on this point as they move forward promoting their token server. They have a huge amount of power and influence in what developers hear and think (regardless if the info is correct or not) in their marketing and in things like the File->NewProject experience. |
|
@brockallen , in what do you want MS to be clear on and how can you know what they are doing in the details? I know there are lots of discussions on this topic and surely they are not the most glorifying ones, but my point is that if you are concerned about their implementation then why not explaining what are those limitations of their future OSS. Otherwise it is perceived as a negative critic for free not mentioning a biased one. |
|
@Ponant I thought I was clear... the Microsoft token service (from their own words if you piece enough of it together) is designed for eventually moving your users and token service to be hosted in Azure B2C. It's not a more general purpose or flexible token server. That's all. What I'm trying to protect against if when people are told half-truths and manipulated in order to sell a product that's not appropriate for their needs. I'm not saying Microsoft has done this in regard to their new token service, but I have seen it done elsewhere for other products in other scenarios. So I'm just trying to keep Microsoft honest about what they are building and what it does. |
|
While I considered using AB2C, I decided not to do it (priced too high and lack of customization and unclear data sovereignty rules). You may be right but I understood their answers differently, quoting parts from @danroth27 and @Eilon ,
I think what they are doing is an invariant OIDC-compliant protocol, I recall Dan made this demo |
|
I think what you are referring to is the MVC/ASP.NET Identity templates that consume an OIDC token service, which is separate from the token service itself that is being provided as the migration path to Azure B2C. And I think, in a sense, your slight confusion has illustrated the exact concern I'm trying to raise. By blurring the distinction between the consuming app and the token service itself (or another way to look at it is by failing to explain with extreme clarity the distinction between the two), it's easy to fall into the situation where File->New Project has led you into being spoon fed a token service whose design is to funnel you into Azure B2C, unbeknownst to the developer. That's the power of owning VS and the File->New Project message that is delivered to developers. Most folks don't know any better that this is not the right choice for them or their companies or projects. For many it is, but again, if it's the only choice how would a developer differentiate? IMO, those should be two different project templates. But that doesn't demo well on stage at conferences and during keynotes. |
|
@Ponant : bonus: my opinion shouldn't feel biased. |
|
IMHO,
I guess my point is that if identity is going to be made so hard to deal with that many developers will simply not use it and opt for a "home grown" path of least resistance solution which could have major security problems. I personally have seen this time and again in code for which I have had to take responsibility. If we can make identity streamlined and simple more people will use it and hopefully more applications will be safer for it. Don't just think big tech company with tons of resources to field a dedicated dev security team. Think startup/small/medium/big business that is not led by technical people and do not know how to run their company as a tech company but want a technology based product. I know that sounds crazy but I see it all the time. They don't give devs the time and resources to do the right thing. So making identity one thing they can count on not to be a time/maintenance suck really helps!
I am not trying to advocate for MS but they are in a unique position to make this happen for a great number of people and make our eco-system safer. Just want them to do the right thing. Hope that input makes some sense.... Sorry, I rambled.... Sorry so long.... |
The problem is that identity is just as much a business feature as anything else, while also concerning security. The reason IdentityServer is so popular is that because identity is not something you can productize as a cloud hosted SaaS offering and control and customize. IdentityServer does take care of the security stuff, while designed to allow the developer to do the customization they need. So it's an option for you instead of doing a "home grown" solution. |
|
Hey @brockallen , I guess its perspective. I think I was more talking about implementation than security in general. Agreed security is part of requirements. But I see ASP NET Identity/IDS4 today as a frameworks a dev can employ, not quite like custom business specific logic to meet a set of consumer feature requirements. Much like we put custom logic in using frameworks (e.g. EF Core is to data access as Identity is to auth/auth). Trying to be pragmatic I find most decision makers do not think like I do when it comes to this stuff. They just assign value to consumer features that they can see and take for granted the ones they cannot (e.g. security) until its too late. So making the identity implementation more straightforward without a bunch of ceremony makes for a far better story to your boss and dev team. For example, app security will take us 4 hrs vs. 4 days of coding and testing. My thoughts are not necessarily about one implementation vs another I guess just more about the need for more straight forward identity implementations that are easy to follow, put in place and transfer to other devs on a team. |
|
From the client app perspective, I think you're right and that can be achieved in the templates or just by adding the |
|
Well, then it is maybe a good time to sell IdentityServer to MS :) Cheers |
|
@Ponant it's free... |
|
@Bartmax , their expertise is not for free and valuable. Anyway, that was a (half) joke to stop turning in circles until MS clarifies or outputs a "template". |
Uh oh!
There was an error while loading. Please reload this page.
Add a layer to ASP.NET Core Identity that exposes identity as a service.
This service should provide an opinionated and turn-key identity solution that enables customers to easily migrate to Azure AD B2C. The service should support flows for Web Apps and Web APIs as supported today by Azure AD B2C. Apps interact with the service using standardized protocols (OpenID Connect, OAuth 2.0, JSON Web Tokens) while abstracting the user from protocol details. Client token acquisition will be supported through the Microsoft Authentication Library (MSAL). The goal is to provide a consistent identity offering for in-app, on premise, and cloud scenarios.
Benefits of exposing ASP.NET Core Identity as a service:
Out of scope:
The text was updated successfully, but these errors were encountered: