web-dev-qa-db-ja.com

マイクロサービスと承認

現在、マイクロサービスベースのシステムに取り組んでいます。その背後にある考え方は、モノリシックシステムを小さなドメインに分割することです（ドメインごとのマイクロサービス）。

すべてのサービスは内部アプリケーションで使用されますが、公開する予定です。

サービスの1つは、トークンの発行と検証を担当するID管理サービスです。

共有参照には、SharedKernelを使用しています。共有カーネルのライブラリの1つは、すべてのマイクロサービスで使用されるカスタムAuthorizationAttributeです。基本的に、属性が行うことは、ベアラートークンを承認サービスに転送することであり、承認サービスは、トークンの有効性、ユーザー情報、指定されたトークンの許可されたエンドポイント/リソースなどの情報で応答します。

現在のエンドポイントがリストされていない場合は、401 HTTP応答が返されます。

今、私は2つの懸念があります：

  1. 私たちは正しい軌道に乗っており、これは有効なアプローチですか？そうでない場合、それを改善するために何ができますか？
  2. UserTypes/Rolesの概念にまだ問題があります。おそらく3種類のユーザーがいます。管理者、エージェント、エンドユーザー、さらには、サードパーティ企業がAPIを使用することを決定した場合、私たちのニーズのために作成されたロールは彼らのニーズに適さない可能性があります。問題は、すべてのエージェントが同じ権限のセットを持つわけではないということです。たとえば、アカウンティングを担当するエージェントがいて、彼はアカウンティング関連のマイクロサービスにしかアクセスできない場合がありますが、予約のみを担当するエージェントもいる可能性があります。これにより、エージェントタイプごとにUserTypeを設定する必要がある場合は、fe。 AccountingAgent、BookingAgentなど、複数のUserTypesをユーザーに割り当てるか、これを解決するためのより簡単な方法がありますか？
securitymicroservicesauthorization
3
Robert

いいえ、トークンを正しく使用していません。

アイデアは、トークンを発行する認証サービスと、トークンを検証してトークンに含まれるクレームを読み取ることができるリソースサービスがあるということです。したがって、フローが次のようになるたびに、ベアラートークンを認証サービスに転送するのではなく、

  • クライアント->認証：トークンをください。ここにユーザー名とパスがあります
  • Auth-> Client：これは私が秘密鍵で署名したトークンで、「私は会計担当者です」という主張が含まれています

その後

  • クライアント->リソース：こんにちは、アカウントのリストを教えてください。これが私のトークンです
  • リソース->クライアント：認証サービスの公開鍵を使用してトークンの署名を確認しました。ですから、私はあなたがアカウントエージェントであるというあなたの主張を信頼できると確信しています。こちらがアカウント一覧です

その後

  • クライアント->リソース：このアカウントを削除してください。これが私のトークンです
  • リソース->クライアント：申し訳ありませんが、アカウントエージェントはアカウントの削除を許可されていません

このフローは、Authサービスがパフォーマンスのボトルネックになるのを防ぎ、さまざまなマイクロサービスに、クレームXがオペレーションYを実行できるかどうかを決定させる

役割

役割と権限に関する2番目の質問に対処します。結局のところ、サービスには、認識している一連の役割または権限が必要です。たとえば、実際に次のようなコードを記述する必要があります。

If(users.Role != "RoleX")
{
    return "Access Denied!";
}

「canEditAccounts」、「canEditCustomers」、「canDeleteAccounts」などのさまざまな権限の完全なリストを用意するのではなく、代わりに、基本的に一連の権限として機能するロール「AccountingAgent」の短いリストを使用する方法が最近のアプローチです。

サードパーティがサービスを利用する場合でも、サービスが認識しているロールを使用する必要があります。これは、役割で提供する細分性のレベルでスタックしていることを意味します。

つまり、あなたの会計エージェントがあまりにも少なく、あなたの会計マネージャーがサードパーティに対してあまりにも多くのことをするなら、あなたは立ち往生しています。

これを回避する1つの方法は、役割と権限を動的にマッピングすることです。サービスに権限を認識させ、役割が持つ権限を照会します。

次に、サードパーティのコンシューマが独自のロールを作成できるようにして、それぞれが持つ権限を選択できます。

6
Ewan

トークンを非表示にするTLSなどの別の場所がない限り、トークンが傍受された場合、誰でもそのトークンを使用して、有効期間中そのユーザーになりすます可能性があることに注意してください。個人的には、シークレットを渡す必要がなく、アプリケーションからセッションを管理する必要がないクライアント証明書のようなものを好みますが、リスクを理解して説明する限り、トークンアプローチに問題はありません。

ユーザーが許可されているもので応答する別のサービスを用意することの利点の1つは、必要に応じて交換できることです。したがって、サードパーティが別のことをしたい場合、そのサービスの動作を変更します。単純に「ここにユーザーX」と言うと、彼または彼女は何ができますか？これにより、認可構造がサービス実装から完全に切り離されます。

別のサービスを使用して承認を管理すると、いくつかの潜在的な課題が生じます。主にそれは単一障害点になる可能性があり、任意のサービスへのすべての呼び出しの要求を受け取ります。実装全体を通して水平スケーリングでこれを管理できるはずです。キャッシングを組み込んで過度のチャットを回避することもできます。

1
JimmyJames