マイクロサービスおよびコンシューマ用の承認および認証システム
当社のシステムをマイクロサービスベースのシステムにリファクタリングする予定です。このマイクロサービスは、社内の社内アプリケーションと、必要に応じてサードパーティのパートナーによって使用されます。予約用、商品用など.
ロールとスコープの処理方法が不明です。このアイデアは、管理者、エージェント、エンドユーザーなどの3つの基本的なユーザーロールを作成し、必要に応じてコンシューマーアプリでスコープを微調整できるようにすることです。
- 管理者（会社の）デフォルトですべてのリソースを作成、更新、読み取り、削除できます。
- エージェントは、自社のデータを作成、更新、および読み取ることができます。
- End-Usersデータの作成、更新、削除、読み取りはできますが、エージェントまたは管理者と同じエンドポイントにはアクセスできません。また、エージェントや管理者と同じレベルではなく、データを作成または変更することもできます。たとえば、エンドユーザーはエージェントがアカウント情報を更新できるのと同じように、アカウント情報を更新または読み取ることができますが、管理者メモを表示または更新することはできません。
エージェントがデフォルトで会社の各リソースを作成、読み取り、更新でき、それがトークン/セッションに要求できる最大スコープであるとしますが、クライアント（APIコンシューマー）アプリケーションの開発者は、エージェントの1つが特定のリソースのみを読み取り、作成します。
これを内部セキュリティで処理し、データベースにデータを書き込むようにするか、クライアントにスコープの小さいトークンを要求して内部で処理させ、どのエージェントがデータベースにどのスコープを持つかを書き込むようにするのが良い方法ですか？ ？この方法では、トークンスコープのみを追跡する必要があります。
これの欠点は、私たちのチームが内部アプリケーションで微調整されたアクセスメカニズムを作成する必要があることです。
この考え方では、マイクロサービスとその承認システムはクライアントのニーズに煩わされるべきではありません。なぜなら、それらはコンシューマーにすぎず、システムの一部ではないからです（これらのコンシューマーの一部は独自の内部アプリですが）。
この委任は良いアプローチですか？
認証と承認は常に良いトピックです
私が取り組んでいる現在のマルチテナントサービスでの承認の処理方法について説明します。認証と承認は、JSON Web Tokenオープンスタンダードを使用したトークンベースです。サービスは、REST APIを公開します。これは、あらゆる種類のクライアント（Web、モバイル、およびデスクトップアプリケーション）がアクセスできます。ユーザーが正常に認証されると、サービスは、それぞれに送信する必要があるアクセストークンを提供しますサーバーへのリクエスト。
それでは、サーバーアプリケーション上のデータをどのように認識して処理するかに基づいて、使用するいくつかの概念を紹介しましょう。
Resource：クライアントがサービスを介してアクセスできるデータの任意のユニットまたはグループです。制御したいすべてのリソースに単一の名前を割り当てます。たとえば、次のエンドポイントルールがある場合、次のように名前を付けることができます。
product
/products
/products/:id
payment
/payments/
/payments/:id
order
/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id
したがって、これまでのところ、サービスに3つのresourcesがあるとしましょう。 product、payment、order。
Action：これは、読み取り、作成、更新、削除など、リソースに対して実行できる操作です。従来のCRUD操作である必要はなく、アクションを持つことができますたとえば、WebSocketを使用してある種の情報を伝播するサービスを公開する場合は、followという名前を付けます。
能力：actionでresourceを実行する能力。例えば;製品の読み取り、製品の作成など。基本的には、リソースとアクションのペアです。ただし、名前と説明を追加することもできます。
ロール：ユーザーが所有できる一連の能力。たとえば、ロールCashierは「支払いの読み取り」、「支払いの作成」の機能を持つことができ、ロールSellerは「製品の読み取り」、「注文の読み取り」の機能を持つことができます、「更新順序」、「削除順序」。
最後に、ユーザーにはさまざまな役割を割り当てることができます。
説明
前に述べたように、JSON Web Tokenを使用し、ユーザーが所有する機能はトークンのペイロードで宣言されます。したがって、小さな小売店で、レジ係とセラーの役割を同時に持つユーザーがいるとします。ペイロードは次のようになります。
{
"scopes": {
"payment": ["read", "create"],
"order": ["read", "create", "update", "delete"]
}
}
scopesクレームでわかるように、ロール（キャッシャー、セラー）の名前は指定していません。代わりに、関係するリソースとアクションのみを指定しています。クライアントがリクエストをエンドポイントに送信すると、サービスは、アクセストークンに必要なリソースとアクションが含まれているかどうかを確認する必要があります。たとえば、エンドポイント/payments/88へのGETリクエストは成功しますが、同じエンドポイントへのDELETEリクエストは失敗する必要があります。
resourcesをグループ化して名前を付ける方法、およびactionsとabilitiesを定義して名前を付ける方法は、開発者が決定します。
rolesとは何であり、どのような能力がそれらの役割を持つかは、お客様が行う決定です。
もちろん、トークンを発行したユーザーと顧客（テナント）を識別するために、ペイロードに追加のプロパティを追加する必要があります。
{
"scopes": {
...
},
"tenant": "acme",
"user":"coyote"
}
この方法を使用すると、ユーザーアカウントからサービスへのアクセスを微調整できます。そして最も重要なのは、質問で指摘するように、管理者、エージェント、およびエンドユーザーのような、事前定義された静的なさまざまな役割を作成する必要がないことです。 スーパーユーザーはroleを所有するユーザーになり、サービスのresourcesとactionsがすべて割り当てられますそれ。
では、100個のリソースがあり、それらのすべてまたはほとんどすべてにアクセスできるロールが必要な場合はどうでしょうか。トークンのペイロードは巨大になります。これは、リソースをネストし、親リソースをアクセストークンスコープに追加するだけで解決されます。
承認は複雑なトピックであり、各アプリケーションのニーズに応じて対処する必要があります。
ユーザーを検証するために作成する認証サービスによって提供される認証トークンをサービスが受け入れるようにする必要があると思います。これは、マイクロサービスの誤用を防ぐための最も簡単で安全な方法です。また、一般に、クライアントに優れたエクスペリエンスを提供する場合は、重要な機能を自分で実装し、十分にテストして、提供する機能が適切に実装されていることを確認する必要があります。
すべての呼び出し元は、認証されたというマイクロサービスの証拠を提供する必要があるため、アクセス許可をその認証に関連付けることもできます。ユーザーを任意のアクセスグループに関連付ける機能を提供する場合（または、派手になりたい場合は、グループですが、許可の追加と削除はここでは対処することが困難です）、ユーザーからの理由に関するクライアントからの質問が少なくなります。 xは望ましくない操作を実行できました。いずれにせよ、誰かが各サービスのアクセスリストチェックを行わなければならないので、あなたである可能性もあります。これは、すべてのサービスの冒頭で非常に簡単にコーディングできるものです（if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }）自分で行って、ユーザーグループを追跡することもできます。権限グループマネージャーが必要であり、それをユーザー管理UIに組み込む必要があることは事実です（ユーザー権限に既存のグループを作成するか、新しいグループを作成します）定義を編集するときは、混乱を避けるために、グループに関連付けられているユーザーを明確にリストしてください。 。しかし、それは難しい仕事ではありません。すべてのサービスのメタデータを用意し、グループとサービス間のマッピングを検索して認証トークンの処理に結び付けます。
わかりましたので、かなり多くの詳細がありますが、この機能を必要とする各クライアントは、これをコード化する必要があります。また、3レベルのユーザー権限をサポートしている場合は、ユーザーアクセスごとに拡張することもできます。グループ。おそらく、基本グループの権限とユーザー固有の権限の間の論理的な交差が適切な集約になりますが、管理者、エージェント、エンドユーザーの基本権限のうち、基本権限を追加および削除できるようにするには、次の操作を行う必要があります。権限グループの通常のトライステートフラグ：権限の追加、権限の拒否、デフォルトの権限、および権限の適切な組み合わせ。
（メモとして、会話の両端のセキュリティを懸念している場合、これはすべてSSLまたは双方向SSLなどで発生するはずです。これらのトークンを攻撃者に「漏らす」と、彼はあたかも彼がしているようですdパスワードをクラックした。）
私の見解では、ここには2つの選択肢があります。
本質的に同じアプリケーションへの構成可能なアクセスが必要な場合は、サービスに権限を確認させ、顧客に各ロールに付与された権限を変更できるインターフェースを提供します。これにより、ほとんどのユーザーはデフォルトのロール設定を使用できます。「問題」のある顧客は、ロールを微調整したり、ニーズに合わせて新しいロールを作成したりできます。
顧客が独自のアプリケーションを開発している場合は、独自の中間APIを導入する必要があります。これは管理者としてあなたのものに接続しますが、サービスを呼び出す前に独自のカスタム認証要件に対して着信リクエストをチェックします
ここでは、短い答えもあります。 「クライアント」に提供したいすべてのcore機能を自分で実装する必要があります。すでにユーザー認証を行っているため、クライアントにユーザー権限などの基本的な動作を追加させるのは問題があるようです。クライアントに任せて実装すると、同じアクセス許可コードの複数の実装が「サポート」される可能性があります。 「所有している」わけではありませんが、コードにバグがあり、クライアントが期待していた機能を妥当な範囲内で実現したいので、クライアントが抱えている問題の解決をサポートします。複数のコードベースをサポートするのは楽しいことではありません。
セキュリティに関する考慮事項
私があなたのデザインをよく理解している場合、いくつかのリソースアクセス制御メカニズムをクライアント側に委任するつもりです。つまり、消費するアプリは、ユーザーが見ることができるアイテムを減らします。あなたの仮定は：
マイクロサービスとその承認システムは、クライアントのニーズに煩わされるべきではありません。これらは、システムの一部ではなく、単なるコンシューマであるためです。
私はここに深刻なビジネスのための2つの深刻な問題を見ます：
- ある悪意のあるユーザー（たとえば、パートナーの工場の1つ）がクライアントアプリをリバースエンジニアリングしてAPIを見つけ、彼の会社がクライアントに課した制限を回避し、その情報を使用して会社に害を与えた場合はどうなるでしょうか。あなたの会社は損害賠償を請求しますが、あなたのデータを十分に保護する手段をあなたが与えなかったとあなたは主張します。
- 通常、機密データが悪用される（または監査によってリスクが発見される）ことは時間の問題であり、経営陣は最終的にそのデータのより厳密な制御を要求することになります。
そのため、このようなイベントを予測し、承認リクエストを処理することをお勧めします。あなたは初期のリエンジニアリング段階にあり、これらをすべて実装しない場合でも、アーキテクチャーでこれらを考慮することは、後で行うよりもはるかに簡単です。
現在の地位を追求する場合は、少なくとも情報セキュリティ担当者に相談してください。
実装方法
あなたはトリックを持っています：
この方法では、トークンスコープのみを追跡する必要があります。
さて、クライアントが選択したいくつかの一般的なトークンを使用する予定です。一部のクライアントはあなたのコントロールの外にある可能性があるため、再び私の目の弱点です。
[〜＃〜] jwt [〜＃〜] をすでに使用しているか、他のテクニックを使用しているかはわかりません。ただし、JWTを使用する場合は、ユーザーのIDを保持するIDトークン（さらに、元のアプリを安全に識別する2番目のトークン）を使用できます。これにより、社内クライアントと外部クライアント間の信頼レベルを区別できます。 ）。
マイクロサービスアーキテクチャを採用するつもりなので、ユーザー管理と認証プロセス（専用サービスとして実行する必要があります）と認証プロセスの 違い を確認することをお勧めします。アクセス制御（各マイクロサービスに固有であり、各マイクロサービスによってローカルで処理される必要があります）。もちろん、一部の管理クライアントは、使いやすさのために、いくつかのサービスにわたって包括的な概要を提供する必要があります。