マイクロサービスはユーザーである必要がありますか？

Question

マイクロサービスの権限が制限されていることを確認しながら、マイクロサービスアーキテクチャでユーザーを承認するための最良の方法を決定しようとしています。私たちのアーキテクチャは、中央承認サービスを使用してJWTトークンの発行を処理します。

次の要件があります。

ユーザーは特定の役割を実行するように制限する必要があります。例えばユーザーは自分が所有するコンテンツの作成、変更、読み取りのみができる必要があります。
マイクロサービスは、必要な権限のみに制限する必要があります。例えば別のサービスからデータを読み取るだけでよいマイクロサービスは、そのサービスへのデータの書き込みを明示的に禁止する必要があります。

例として、ユーザーが画像を画像保管サービスにアップロードできるシステムがあるとします。写真に場所を自動的にタグ付けするタグ付けサービスがあります。ユーザーは自分の写真のみをCRUDできます。タグ付けサービスは、イメージストアサービスから任意のイメージを読み取ることができますが、変更/削除することはできません。

JWTトークンを使用して上記を実現する良い方法は何ですか？これまでに説明したいくつかのソリューションは次のとおりです。

画像ストアサービスは2つのAPIを公開します。1つは外部で使用可能（ユーザーにCRUDアクセスを許可）、もう1つは内部で使用可能（内部読み取り専用アクセスを許可）です。柔軟性がないようです-別の内部サービスがすべての画像（たとえば、明示的な画像を自動的に削除するもの）への読み取り/書き込みアクセスを必要とする場合はどうなりますか？
ユーザーのJWTに2つの権限を設定しました。1つはCRUD_OwnImagesで、もう1つはREAD_ForAnalysisです。タグ付けサービスは、ユーザーがREAD_ForAnalysis権限を持っているかどうかを確認でき、もしあれば、適切なリクエストを行います。ユーザーが自分の画像に対するCRUD操作用のCRUD_OwnImagesを持っているかどうかを確認する別のマイクロサービスがあります。これにより、各マイクロサービスに責任があり、ユーザーが必要なアクションに制限されるようにします。イメージストアには、このアプローチで各マイクロサービスを制限する方法がないため、不安定でエラーが発生する可能性があります。
READ_ForAnalysisを許可として、タグ付けマイクロサービスに独自のユーザーを付与します。次に、タグサービスが画像ストアから画像を要求すると、画像へのアクセス権が付与されますが、画像の変更は禁止されます。ユーザーのユーザーはCRUD_OwnImages権限しか持っていないため、フロントエンドから自分の画像のみを取得してアクセスできます。別のサービスがすべてのデータへのCRUDを必要とする場合、CRUD_AllDataまたは同様のサービスを提供できます。各サービスが独自のデータを担当するため（このロジックは複数のサービス間で複製されるのではなく）、このアプローチが気に入っていますが、サービスがユーザー権限とマイクロサービス権限の両方を必要とする場合はどうなりますか？ 2つのJWTトークン（ユーザーとマイクロサービスの両方）を安全に送信できますか？アクセス許可を安全に組み合わせて送信する方法はありますか？例えばタグ付けサービスはすべての画像を読み取ることができますが、ユーザーの画像を場所とともに書き込むこともできますか？

ユーザー情報がさらに下流（2または3マイクロサービス離れている）に必要な場合、問題はさらに悪化します。必要なアクションに制限するのは個々のマイクロサービス次第であり、それを明示的にしないのではないかと思いますか？

Telastyn · Answer

一般に、できるだけ多くの操作を実際の人間のユーザーに関連付ける必要があります。これは、人々に適切な認証を強制し、単一の一貫した承認戦略を推進し、まとまりのある監査証跡を提供する重要な部分です。

そして一般的に、マイクロサービスには3種類のシナリオがあります。

1。ユーザーが入ってきて、写真をアップロードし、タグを付ける必要があります。すばらしい。写真サービスは、JWTをタグ付けサービスに渡すだけ（または依存関係の方向によってはその逆）で、ユーザーがサブ操作を実行する権限を持たない場合は、適切なアクションを実行します（タグなしで写真をアップロードする場合があります）、エラーを返す場合があります。

2。ユーザーが入ってきて、写真をアップロードし、タグを付ける必要があります...しかし今は必要ありません。かっこいい。これで、写真は通常どおり処理されます。後で、タグ付けが発生すると（イベント/メッセージ処理、CQRSスタイルのコマンド処理、定期的なジョブ処理など）、タグ付けサービスがユーザーを偽装し（共有シークレットを使用して認証からカスタムJWTを要求することにより）、次に実行します。元のリクエスターに代わる副操作（すべての許可と制限付き）。この方法には、非同期操作に関する通常の問題があり、スムーズに進まない場合にユーザーにエラーを返すのは困難ですが、このパターンをクロスサービス操作に使用している場合は、すでに解決済みです。

。一部のサブシステムは、ユーザーのコンテキスト外で処理を行う必要があります。古い画像をアーカイブするための夜間の仕事があるかもしれません。タグを統合する必要があるかもしれません...この場合、これらの各アクターに、制限付きの権限と監査証跡の一意のIDを持つ独自の疑似ユーザーを作成する必要があります。

どちらを使用するかは、シナリオ、ニーズ、およびリスク許容度によって異なります。そしてもちろん、これらは広範なストロークの一般化の不完全なセットにすぎません。

しかし、一般的に、マイクロサービス自体は、可能であればユーザーであってはなりません。