3

For now I have a mobile app (M), a single web api (A), and an Identity 4 server (I).

I am aiming for a microservices DDD approach.

Should my Identity server own the user profiles (for signup/signin) in its own database, or should my API have them in its database?

Let scenario 1 be that Identity owns them, and scenario 2 be that the API owns them.

It seems to me scenario 1 makes sense, but my assumptions on the issue are the following:

Scenario 1, signup:

I have one round trip to Identity.

M -> I -> M

Scenario 1, signin:

I have one round trip to Identity. 

M -> I -> M

Scenario 2, signup:

I have a trip like 

M -> A -> M

Scenario 2, signin:

The mobile app talks to Identity, which asks the API to check the user, and on success sends the tokens back to the mobile app.

M -> I -> A -> I -> M

or the mobile app talks to the API which upon success gets the tokens from Identity and then sends them back to the mobile app.

M -> A -> I -> A -> M
Pointo Senshi
  • 541
  • 5
  • 17
  • 1
    Normally, you wouldn't copy profiles with user info (name, email, etc.) into the API's database. And your flow is more like `M tries to access protected resource -> A returns 401 since user not authorized -> M redirects to identity provider -> I user logs in / signs up and idp issues token -> M uses token to access protected resource -> A returns protected resource -> M receives protected resource`. – Vidmantas Blazevicius Aug 16 '19 at 11:27

2 Answers2

2

I tend to have my Identity & Access Control BC own the user and related permissions and there are APIs (rest, assembly) that would surface the relevant functionality and I follow this version of your patterns:

M -> A -> I -> A -> M

If I have a web-site (S) it would then be:

S -> A -> I -> A -> S

When I perform a logon a new session is created and the user's permissions are registered against the session since it may be an expensive exercise to get them.

All authorization is then performed against this cached version of the permissions. Should permissions change then the user would still be authorized against the existing session permissions. If this is unwanted behviour then the session may be expired after the permissions have been altered.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
1

The user would exist in both places, the main identity being in the identity server, and any relevant application scope claims living in the api.

You could set coarse claims in the issue token, but this would result in claims being valid for the duration of the issued token, or worse checking the identity server for revoked tokens on each call.

What you would typically do is with ASP .net at least, is use claims transformation, which can be used to take the provided user id (or claims) and add to them - also known as claims enrichment.

This way any changes made to a users access rights would then be picked up during the transformation process which runs on each call.

Since this happens local with the process no external systems are needed and will be fast and is (should be) loosely coupled from any other system, with only claims enriched for the security roles that make sense to the local app.

Excuse the C# example as not sure what code you are running (possible .net given Identity Server?) either way this post provides the general process of transforming claims within a local application Add claims with Owin Middleware.

morleyc
  • 2,169
  • 10
  • 48
  • 108