How to decouple Identity from Domain Layer?

[HybridSolutions]

Would love to hear some opinions on this subject. It's one of the most present topics in this architecture, but never properly explained. Found a project based on this architecture that uses automapper to "sync" a custom User class to IdentityUser user entity but is this the best approach?

https://github.com/mmacneil/CleanAspNetCoreWebApi

It would be nice to see how CleanArchitecture deals with:

1. having a custom User class in domain layer with custom properties not dependent of IdentityUser.
2. having the need to this custom user entity table be related to IdentityUser AspNetUser table.
3. sync both entities upon CRUD operations on users and prevent orphan data in case of db errors.

[Chris-Mingay]

Not at all claiming this is the right way to go but...

I've been going back and forward with this a lot myself recently and I came to the conclusion that I should use identity framework for two things only and then keep it as a completely separate entity in the system I am writing:

• User Authentication - Allowing a user to prove they are who they say they are
• User Authorization - Defining roles a specific user has and defining what they can and cannot do in the system (at a very basic level)

I have my own internal user class which is the only part of the system that references an Identity User ID (via a public string IdentityUserId { get; set; }). This is a property I set manually when creating my own User object. I make no attempt to formally link the user to an identityuser via Entity Framework. I have a Mediatr query that allows me to load a User from the provided IdentityUserId and that's it.

I felt comfortable doing things this way because in my mind, Identity Server is a separate thing outside the scope of my application, I wanted to keep it as separate as possible. I effectively don't care about any Identity based data for a user, it's none of my business, I just want to use it to allow a user to prove who they are.

I use Authorization to define some very simple roles which basically set the type of user each entity is and with it which pages in the system they can see, however for my project a lot of the access logic is business driven, so I keep that within the domain and nothing to do with Identity Server.

[ali-gol]

@HybridSolutions I have done the similar. I have the IdentityUserId in my seperated User class.
But if I do it as you did, I won't be able to create CreateUserCommand or those kind of things. I mean in your solution, you won't be able to use Mediatr for User Creation, because you can not call the Infra from Application layer.

[HybridSolutions]

@HybridSolutions I have done the similar. I have the IdentityUserId in my seperated User class. But if I do it as you did, I won't be able to create CreateUserCommand or those kind of things. I mean in your solution, you won't be able to use Mediatr for User Creation, because you can not call the Infra from Application layer.

Yes, but I gave up going strictly by the book, because I would go insane and there's little support on integrating identity in a Clean Architecture solution. Do you really need to implement Mediatr pattern? Would love to see that working.

[danielmackay]

Could you simply have the user entities in your domain project and encapsulate the IdentityService by having the interface in application and the implementation in your infrastructure (as you've done)

Then have a CreateUserCommand that creates both a business user and identity user.

Would that work for your situation?

[ali-gol]

Could you simply have the user entities in your domain project and encapsulate the IdentityService by having the interface in application and the implementation in your infrastructure (as you've done)

Then have a CreateUserCommand that creates both a business user and identity user.

Would that work for your situation?

Yes @danielmackay, that would solve the issue. But creating user in identity service is not the responsibility of Application Layer. If it is, what is the benefit of having the Seperate identity server? Simply disable it.

That's the problem of this solution. It forces you to use the identity service, since we don't need it, we just workaround our issues.
That's why I've totally disabled the Identity Server. I am basically returning my custom JWT from a login endpoint. This template solution ignores the fact that not everyone needs an identity server. For most of scenarios, it is over engineering.

On the other hand, I don't see any documentation about how we should structure out solution based on real life app. In the given examples and sample todo app; there is no user entity involved. It would be more realistic to have such a thing like that as we discussed here.
Thanks for your reply, and effort.

[danielmackay]

@ali-gol - I think the point of using IdentityServer is showing one way to do authentication. There are also many other options such as ASP.NET Identity, or an OIDC provider such as Azure AD, OAuth, or Okta. It's hard to build a template that works exactly right for everyone, and sometimes it will get you 90% of the way there, but you may need to remove some pieces and replace with your own (which it sounds like you've done). That is a very normal thing to do.

I do hear what you're saying about IdentityServer, and I believe @jasontaylordev has been thinking about how to add a more simplified Identity Service that devs can extend in a way that suits different needs.

If you have some ideas feel free to submit your own PR.