Open bistok opened 8 months ago
From my knowledge:
I believe we should keep it simple. Use ASP.NET Identity with Duende IdentityServer to create a simple example because there are too many prerequisites to even consider both solutions as valid for most.
I believe we should keep it simple. Use ASP.NET Identity with Duende IdentityServer to create a simple example because there are too many prerequisites to even consider both solutions as valid for most.
Yesterday I found this: https://docs.duendesoftware.com/identityserver/v7/aspnet_identity
and like you say we can have both Identities a simple solution using ASP.NET Identity and for the people that likes the advances features from Duende IdentityServer, that can be plug-in with that.
I have mixed feelings about ASP.NET 8 Identity because I am old enough to remember the Membership Provider from the old MVC, and it was not well-designed. :) However, we can give it a chance and see how it turns out.
As for Duende IdentityServer, since it is a paid solution, I would prefer using the most well-known open-source solution for that purpose - https://www.keycloak.org/. But Duende has advantage that is known in community.
In general, we don't have to choose any solution and can create three new separate versions of the UserAccess module (ASP.NET Identity, Keycloak, Duende IdentityServer). That's why we have modules :) The choice of the module will be at the configuration level.
The question is, who would like to do what? :)
I have mixed feelings about ASP.NET 8 Identity because I am old enough to remember the Membership Provider from the old MVC, and it was not well-designed. :) However, we can give it a chance and see how it turns out.
I know what do you feel but this version is a worked one like all .net core.
As for Duende IdentityServer, since it is a paid solution, I would prefer using the most well-known open-source solution for that purpose - https://www.keycloak.org/. But Duende has advantage that is known in community. I agree with you in this, if the default implementation for the template is a payed one there will be less people wiling to use this as starting point. In general, we don't have to choose any solution and can create three new separate versions of the UserAccess module (ASP.NET Identity, Keycloak, Duende IdentityServer). That's why we have modules :) The choice of the module will be at the configuration level.
This is great, and will make the template better for everyone, not only the people will benefit for having a modular system, but can see how it's implemented the modular part with a swappable module.
The question is, who would like to do what? :)
I can do the Asp.net Identity one (when I get some free time), the thing is that we replace the user tables for use Microsoft tables? for that we need to use migrations on entity framework or generate the tables scripts.
@kgrzybek you would like to implement the Keycloak one?
It would take some major refactoring as Identity Server is baked into the API, and is referenced in every application module.
This is one of the things that stopped us using this as a jumping in point, there's no way we'd get sign off on the duende cost and IDS4 would not get past our EOL requirements.
the thing is that we replace the user tables for use Microsoft tables?
@bistok I think you do not need replace user tables - you can try implement using different database schema because it will be a totally different module.
I agree with @carlsixsmith - right now IS is referenced by API module and after last changes was referenced by all application libraries (via building blocks). I reverted this in https://github.com/kgrzybek/modular-monolith-with-ddd/commit/0d18452b8422cf08ffe63fe3fd1dcba644bfe9e6 and right now it is referenced only by API and UserAccess module.
So we need to get rid of reference from the API. This is the general problem with .NET framework that they want to setup everything in the "API" and API is coupled to everything. But we do not want do this. API should be responsible only for initialization and HTTP requests and other stuff should be delegated to specialized modules.
@kgrzybek you would like to implement the Keycloak one?
I can try to do PoC.
@kgrzybek I have done an implementation that removed Identity Server from the API and the Application project and put it directly on the UserModule Infrastructure project, can you cherry pick that change from my PR??
API should be responsible only for initialization and HTTP requests and other stuff should be delegated to specialized modules.
I can rewrite the API to add one extra project for every module and bootstrap them in the main API which will be almost empty after change. Easy to setup and tested on production.
I have done an implementation that removed Identity Server from the API and the Application project and put it directly on the UserModule Infrastructure project, can you cherry pick that change from my PR??
@bistok Create separate PR for that, please :)
I can rewrite the API to add one extra project for every module and bootstrap them in the main API which will be almost empty after change. Easy to setup and tested on production.
@Xeinaemm
I do not think we need one extra project for every module. What we can do is to create a separate "host" module and extract existing "api" to separate library because now they are connected. It is not a big thing in my opinion, though.
@kgrzybek created PR #296
I can rewrite the API to add one extra project for every module and bootstrap them in the main API which will be almost empty after change. Easy to setup and tested on production.
@Xeinaemm I think this can live on the Infrastructure project
It would take some major refactoring as Identity Server is baked into the API, and is referenced in every application module.
@carlsixsmith There was not that mayor refactoring because was spread with no reason and can be contained on only one project like I do on PR #296
With this I think we do not have to implement a complete user module, for using other Identity framework/product.
I open this issue to discuss about changing the Identity implementation, like we the mention on https://github.com/kgrzybek/modular-monolith-with-ddd/pull/288#issuecomment-1849017176
We currently are using Identity server 4 and there are 2 problems with that:
For that I would like to explore if we can change the authentication to use ASP.NET 8 Identity with tokens, because it's something that is supported and will be functional over time.
But first would like to know what others options or alternatives we can use.
@kgrzybek I think we can maybe design the authentication to be an abstraction and implement asp net and duende to be the concrete implementations