IdentityServer4 Usermanagement with separate MVC Client (AspNetIdentity)

user_8045161 0
Viewed 555

After a lot of reading and trial and error I got my target design working:

  1. IdentityServer4 (standalone with AspNetIdentity) with IdentityUser database
  2. MVC Client (standalone), this is the frontend to the users, no database link at the moment
  3. 1-n WebAPIs which serve the functionality to the MVC Client and have their own databases

At the moment I use an already existing IdentityUser database and point the IS4 to this database, added roles and claims manually for testing purpose.

My question is about best practice to register new users.

As the MVC Client is the frontend to the user, a link to the user registration should appear here.

But where is the registration technically done?

  1. Should I do it in the MVC Client (with the default IdentityUser Registration) and point the database to the IS4 database or
  2. should I add a register function in the IS4 app to keep the MVC Client free of any database dependencies and point the MVC Client "register" link to this IS4 register function?
identityserver4 .net-core asp.net-mvc
2 Answers

Basically IdentityServer has two responsibilities:

  1. Authenticate the user
  2. Authorize the client

The 'problem' with IdentityServer is that the user is not restricted to one application. While the MVC website may be your front, IdentityServer does not relate users to a particular application. Once authenticated, the user can access all applications that use IdentityServer as an authentication server.

So does it make sense to register the user on the MVC website? Probably not, because the user can access the (future) 'mvc2' website as well.

The creators of IdentityServer acknowledged this, so they created the PolicyServer:

We think that tightly coupling "Identity and Access Management" in a single solution is the wrong approach. These two concerns should be clearly separated.

In other words: authentication is part of IdentityServer, authorization (of the user) is not.

Getting back to the question, registration of the user should be managed by IdentityServer. Because that is the only application that has access to the Identity store. Besides, users can also register without being redirected by an application.

The key is how to manage the authorization (of the user). This isn't actually part of IdentityServer. I won't go into detail as this is outside the scope of the question.

But to answer your question, what I would do (including email verification, but without automatic login):

Add registration functionality to the IdentityServer and implement a ReturnUrl (like is already the case for login).

Add a link on your mvc website to the register function on IdentityServer. Let the user register in IdentityServer, send an email verification link which sends the user to the login page (persisting the return url), allowing the user to redirect back to the mvc website once registered and logged in.

How to add authorization to the registered user is a different question.

Admin1

I would not use "User Management" and "User Registration" interchangeably. There is a lot more to user management than just registration. But to answer your question:

Should I do it in the MVC Client (with the default IdentityUser Registration) and point the database to the IS4 database or

You could, and there would not be anything terribly wrong with that. This will heavily depend on your business requirements, but most often I have seen "User Registration" built into the identity providers (your IdentityServer4 in this case).

user_90731300
Related