2

I'm using Identity Server 4, Asp Identity, EF Core and one database. I have 3 projects at the moment

  • IdentityServer - Contains all data contexts and all migrations with my app tables
  • Api - no context, no migrations however I need to access database somehow from here
  • Clinet - javascript

The question: How do I access data context from IdentityServer project and still have all settings (db connection, etc) in one place. I understand I can reference IdentityServer from API and use data context but it seems not right to me. What is the preferred way to do this ?

ferdinand
  • 970
  • 1
  • 7
  • 14
  • 1
    IdentityServer is not the place for your app tables. These are seperate contexts and seperate migrations. The preferred way is to maintain the seperation of concerns. –  Jan 28 '18 at 22:12
  • @RuardvanElburg I need also ASP Identity tables and make relations from my app to users table from asp identity. And identity server also needs Asp Identity tables – ferdinand Jan 29 '18 at 08:40
  • Thank you. But if I have two databases AppUser needs to know that it belongs to IdentityUser. So when user registers using IdentityServer then IdentityServer need to insert new AppUser into another database table. – ferdinand Jan 29 '18 at 14:35
  • This doesn't have to change, you can register the user in your app db once the user logs in and doesn't exist. Call the UserInfo endpoint of Ids4 to request information about the user. –  Jan 29 '18 at 14:59
  • @RuardvanElburg thank you. It might work but it seems a little bit complicated. Don't you have an example where all together works (with IS users and app users) ? – ferdinand Jan 30 '18 at 14:46
  • @RuardvanElburg another question I would like allow external clients access to my api. So my app needs to talk somehow to the IS4 to add client. Because of this it seems that have it all in one database and one project is the simplest way how to do this. What do you think ? – ferdinand Jan 30 '18 at 14:58

1 Answers1

4

Since you are interested in this option, I've decided to move my comments to this answer.

First of all, IdentityServer is not the place for your app tables. These are seperate contexts and separate migrations. The preferred way is to maintain the separation of concerns.

As I explained in my answer here, you don't need a relation between the login user and your business context. Instead create a user in the business context. The login user has a different purpose than the business user.

I don't have code for you, but you can take one of the sample apps from IdentityServer. Adjust the API to use your business context. In that context add a user table (which links to the sub claim) and the fields you need for the business context. BTW it doesn't matter if the tables are in the same database, just don't mix the contexts.

In IdentityServer: if the user may register for one website then you can extend the registration form with a drop-down of available websites. Or a list if the user can register for multiple websites.

Now it depends on the chosen strategy. You can wait to register the user in the API, but I think it is far more easy to register the user straight away. There are other options, but here's one where it is part of the IdentityServer configuration (without adding business logic to IdentityServer):

Extend IdentityServer to call the API after registering the user. For this I would add a table in the IdentityServer context with URLs to register per website. When the login user is created, call the configured API(s) to register the business user.

In the API you need to add the method that IdentityServer can call to create the user, linked to the sub claim and including the required user information. This way you can suffice with the sub claim to identify the login user and link this to the business user.

You can use a similar strategy for client apps. Extend IdentityServer with an API method to allow client apps to register users.

If you want to withdraw access, you can delete the login user without having to delete the business user. Which you don't want if you don't want to destroy historical information. You can also use claims to specify if the user has access to the website without having to delete the login user.

Vy Do
  • 46,709
  • 59
  • 215
  • 313