正しいタイトルを使用したかどうかはわかりませんが、より適切な記述方法を考えることができませんでした。それはもっと設計上の問題かもしれない。マルチテナントデータアクセスを使用したWeb API認証
1人のユーザーが1つ以上のエンティティに所属できるマルチテナントDBがあります。 /トークンエンドポイントを呼び出すことによって、ユーザーの資格情報でユーザーを認証します。
私はトークンを受け取った後、自分のエンドポイント(トークンを使用)を呼び出して、このユーザーの利用可能なエンティティのリストを取得し、このユーザーが現在のエンティティをメモリキャッシュに設定できるようにします。私はその後、メモリキャッシュでこれを使用して、DBを呼び出すときにユーザーがどのエンティティ/テナントに「ログインしているか」を知るためのすべての要求のエンティティ/テナントIDを検索します。
理想的には、エンティティ/テナントIDをトークンに含めることでアプリケーションをよりステートレスにするために、メモリキャッシュの必要性を排除したいと思いますが、ユーザーが認証されて選択された後でのみ彼/彼女の主体。私は明らかにトークンが発行された後、クレームを変更または追加することはできませんが、この種の動作を実装する代替設計がありますか?
私はおそらくテナントごとにサブドメインを使用していると考えましたが、技術的にはセットアップやメンテナンスが難しくなります。私はまた、ユーザーに資格情報を使って自由なテキストとしてログインしたいエンティティを入力するように促すことを考えましたが、これは理想的ではありません。
誰もこの挑戦に直面したことはありますか?
あなたの回答Federicoに感謝します。これはまさに私が後にしたものです。 – Ross
_ ** "アクセストークンの内部にテナントIDを含めることはできません" ** _ - 私は同意します。アクセストークンは、リクエスト自体ではなく、リクエスタのプロパティを識別するためのものでなければなりません。私。彼らが何をすることができるのかを示しています。 2つのシナリオを混在させることが問題となるのは、ユーザーが複数のテナントにアクセスし、トークンに複数のテナントIDが含まれている可能性があるということです。 – Snixtor
アクセストークンにTenantIdを含めることが維持しやすくなるとは思わないでしょうか。フロントエンドの人はトークン全体を送信するだけで、データはアクセストークンに基づいてフィルタリングされますか? –