Consider a website like: Confused.com, which is a price comparison website that has millions of registered users who use it for price comparison purposes. These users register their details for price comparison purposes?

How do you deal with administration i.e. people who work for the company in question? For example, lets say that admin user x wants to see all the quotes that were generated in the last 24 hours.

Would you use ASP.NET Identity for authentication and Role Based authorisation was used for authorisation. This would mean:

1) All users whether they are admin or non-admin (price comparison searches) would be contained in the same ASP.NET Identity table.

2) After the user has logged in, the app will figure out if they are admin. If they are admin then additional options appear on the screen or they are redirected to an admin webpage.

Does this sound right? Alternatively a separate app for admin could be developed.

How is this usually done?

  • What does this have to do with domain-driven-design?
    – kayess
    Aug 30, 2017 at 13:35
  • @kayess, I am trying to figure out if ASP.NET Identity and MVC Roles are relevant to a large DDD app. I am at the planning phase.
    – w0051977
    Aug 30, 2017 at 14:03
  • You could argue that it is a cross-cutting concern that is orthogonal to your app. Aug 30, 2017 at 15:07

2 Answers 2


That's the general idea. Identity Management handles both the Identification and Authentication side of things. In other words, it provides you facts about a user and makes sure we know the user is who they say they are.

Your application then makes explicit decisions to allow access to certain features. That process is called Authorization. Asp.Net MVC does have additional features to help you such as the authorization related attributes:


Explicitly allow anyone to this action, overrides class level authorization


Authorize any authenticated user

[Authorize(Roles = "Administrators, Content Editor")]

Authorizes users with the role Administrators or Content Editor

What those do is prevent access to people who know the URL but don't have the proper authority to access the part of the application you want protected. The server responds with a 401 error which means "Unauthorized".

It's good practice to simply remove buttons or links that take you to protected areas of the application if the user doesn't have access. Once they log in, and are properly authenticated, we can grant them access.

  • Thanks. Does it makes sense to use your strategy for a large DDD app.
    – w0051977
    Aug 30, 2017 at 14:04
  • It's the framework's strategy. The alternative is to handle the authorization in the business objects themselves, as long as you have a mechanism to preserve the HTTP response codes. Aug 30, 2017 at 15:05
  • Thanks. Can you have a look at my other question here: softwareengineering.stackexchange.com/questions/356660/…
    – w0051977
    Sep 1, 2017 at 18:23
  • 5 years late to the party, but I'll throw in my question anyways: if such application had a domain model for users, how would this relate to the asp.net identity user? Would you have to reference asp.net identity in the domain layer?
    – Kappacake
    Apr 1, 2022 at 17:50
  • That side of things is a bit different. I did build something like that 5 years ago, but the way you extend identity management has changed significantly since then. You'll have to check the current extension mechanisms. Apr 2, 2022 at 14:32

You would normally segment or 'modularize' your application. With MVC you could use areas and apply different authorization to an 'admin' (and other) area/s.

The differentiation here is:

  • Authentication, determining if the user is allowed to login
  • Authorization, determining what the user is allowed to access

If you modularize your application into numerous areas, you can apply authorisation against those areas and also security trim any menu's or visualizations per authorization role using some built in mechanisms.

Walkthrough: Organizing an Application using Areas

Depending on your adherence to DDD, you could also potentially use an area per domain and taking it a step further have each area as an independent entity so different teams could code and test each area in isolation of the other areas before bringing it together for e2e testing of the superset of areas/domains.

  • Is this approach documented anywhere? Thanks. If you can post a link, then I will upvote.
    – w0051977
    Jan 15, 2018 at 0:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.