クレームデータを使用してCreatedByユーザーデータをカスタムテーブルに挿入できますか？

Question

私はわずかなアーキテクチャ上の問題があります。 アイデンティティユーザーストア（データベースのユーザー）を持つユーザーを認証するためのIdentityServerソリューションがあります。私はここにログイン機能を持っているので、ここでDbContextを使う必要があります。 IDテーブルではないカスタムテーブルを保持する別のソリューションAPIがあります。すべてのテーブルは同じデータベースにあります。

私はAPIを使って新しいレコードを追加するとき、何とかCreadetByをIDユーザーに接続したいと思っています。私はクレームからユーザーについての情報を得て、新しい行を作成している間に挿入することができますが、それは良い方法ですか？

もう1つの質問は、IdentityServerプロジェクトから登録操作を外してそこのIDユーザーストアにログイン機能を使用し、APIに登録するだけなので、2つの場所でApplicationUserの追加フィールドを複製しませんか？

Answer 1

私が理解するところでは、懸念の分離を維持する必要があります。同じコンテキストを共有していないテーブル間には、決して関係を持たないようにしてください。つまり、Carsは決してAspNetUsersにリンクできません。

これは、オブジェクトとフィールドの意味についてです。たとえば、IdentityUserとCustomUserは等しいと思われますが、そうではありません。 IdentityUserには、CustomUserがカスタムモデルに必要なすべての情報を持つ場所としてユーザーを識別するために必要なすべての情報があります。実際、ログインアカウントを持たないCustomUsersを持つことができます。

また、emailaddressも考慮してください。両方のコンテキストでこのフィールドを使用するのは冗長なようですが、実際に自分のGoogleアカウントを使用してログインしてカスタムメールアドレスの更新情報を受け取ることができます。

したがって、CreatedByフィールドの意味は何ですか？また、どのように使用する予定ですか？カスタム・コンテキストの一部（レポート用など）の場合は、CustomUser表があり、その表に関連する必要があります。管理目的でこれをチェックしたいのであれば、ユーザ名を保存するだけで十分でしょう。あなたはそのフィールドで質問しますか？ CustomUserAddressのような追加情報が必要ですか？

うまくいけば、実際には重複フィールドはないと思います。彼らはすべて目的と意味が異なるためです。

いずれにしても、あなたは文脈を超えて関係することを望んでいません。そして、別のコンテキストから情報を取得するために、idのリストを送信してしまうことを望んでいません。

問題は、現在のユーザーをリンクすることです。識別トークンは、ユーザーを識別するために使用されます。これはあなたのリソースに何も意味しません。しかし、アクセストークンには、リソース内の実際のユーザーに関する情報が含まれています。

リソースに近い権限を保持することで、CustomUserIdを使用して承認ユーザーを拡張できます。アクセストークンにこの情報を追加します。アクセストークンは認証の一部であるためです。ユーザーに指定されたユーザーのデータにしかアクセスできないことをリソースに通知します。

[アクセストークン] .customUserIdを使用すると、CustomUserと一致させることができます。したがって、CreatedByはCustomUser.Idの値を持つ必要があります。

また、私はこの記事をお勧めしたいと思います：https://leastprivilege.com/2016/12/16/identity-vs-permissions/