マイクロサービスおよび消費者向けの承認および認証システム

会社のシステムをマイクロサービスベースのシステムにリファクタリングする予定です。このマイクロサービスは、社内の社内アプリケーションと、必要に応じてサードパーティパートナーによって使用されます。予約用、製品用など

ロールとスコープをどのように処理するかは不明です。管理者、エージェント、エンドユーザーなどの3つの基本的なユーザーロールを作成し、必要に応じてコンシューマーアプリがスコープを微調整できるようにするという考え方です。

• 管理者は、デフォルトで（会社の）すべてのリソースを作成、更新、読み取り、削除できます。
• エージェントは、会社のデータを作成、更新、および読み取ることができます。
• エンドユーザーはデータを作成、更新、削除、および読み取ることができますが、エージェントまたは管理者と同じエンドポイントにアクセスすることはできません。また、エージェントや管理者と同じレベルではなく、データを作成または変更することもできます。たとえば、エンドユーザーはアカウント情報を更新または読み取ることができます。これは、エージェントができるようになりますが、管理者ノートを表示または更新することはできません。

デフォルトでは、エージェントは会社の各リソースを作成、読み取り、更新でき、それはトークン/セッションに要求できる最大スコープですが、クライアント（APIコンシューマー）アプリケーションの開発者は、エージェントの1人が特定のリソースのみを読み取り、作成します。

内部セキュリティでこれを処理し、データベースにデータを書き込むようにするか、クライアントにスコープを小さくしてトークンを要求することで内部的に処理させ、どのエージェントがデータベースにどのスコープを持つかを書き込むようにすることをお勧めします？この方法では、トークンスコープのみを追跡する必要があります。

この欠点は、チームが内部アプリケーションで微調整されたアクセスメカニズムを作成する必要があることです。

この考え方では、マイクロサービスとその承認システムはクライアントのニーズに煩わされるべきではありません。なぜなら、それらは消費者であり、システムの一部ではないからです。

この委任は良いアプローチですか？

認証と承認は常に良いトピックです

私が取り組んでいる現在のマルチテナントサービスの承認をどのように扱うかを説明しようと思います。認証と承認は、JSON Web Tokenオープンスタンダードを使用したトークンベースです。このサービスは、あらゆる種類のクライアント（Web、モバイル、デスクトップアプリケーション）がアクセスできるREST APIを公開します。ユーザーが正常に認証されると、サービスはサーバーへの各リクエストで送信する必要があるアクセストークンを提供します。

そこで、サーバーアプリケーション上のデータをどのように認識して処理するかに基づいて、使用するいくつかの概念を紹介します。

リソース：クライアントがサービスを介してアクセスできるデータのユニットまたはグループです。制御したいすべてのリソースに、単一の名前を割り当てます。たとえば、次のエンドポイントルールがある場合、次のように名前を付けることができます。

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

したがって、これまでのところ、サービスには3つのリソースがあります。product、paymentおよびorder。

アクション：読み取り、作成、更新、削除など、リソースに対して実行できる操作です。従来のCRUD操作だけでなく、followたとえば、 WebSocketを使用して何らかの情報を伝達するサービスを公開したい。

能力：実行する機能actionにresource。例えば; 製品の読み取り、製品の作成など。これは基本的に単なるリソース/アクションのペアです。ただし、名前と説明を追加することもできます。

役割：ユーザーが所有できる一連の能力。たとえば、ロールにCashierは「支払いの読み取り」、「支払いの作成」Seller機能があり、ロールには「製品の読み取り」、「注文の読み取り」、「注文の更新」、「注文の削除」の機能があります。

最後に、ユーザーにはさまざまな役割を割り当てることができます。

説明

前にも言ったように、JSON Web Tokenを使用し、ユーザーが所有する能力はトークンのペイロードで宣言されています。それで、小さな小売店のために、キャッシャーとセラーの役割を同時に持つユーザーがいるとします。ペイロードは次のようになります。

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

scopesクレームでわかるように、ロール（キャッシャー、セラー）の名前は指定しませんが、代わりに、関係するリソースとアクションのみが指定されます。クライアントがエンドポイントにリクエストを送信すると、サービスはアクセストークンに必要なリソースとアクションが含まれているかどうかを確認する必要があります。たとえばGET、エンドポイントへのリクエスト/payments/88は成功しますがDELETE、同じエンドポイントへのリクエストは失敗する必要があります。

• リソースをグループ化して名前を付ける方法、およびアクションと能力を定義して名前を付ける方法は、開発者が決定します。

• 役割とその役割を持つ能力とは、顧客が下す決定です。

もちろん、トークンを発行したユーザーと顧客（テナント）を識別するために、ペイロードに追加のプロパティを追加する必要があります。

{
    "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を導入する必要があります。管理者としてあなたに接続しますが、サービスを呼び出す前に、独自のカスタム認証要件に対して着信リクエストをチェックします

セキュリティに関する考慮事項

あなたの設計をよく理解していれば、いくつかのリソースアクセス制御メカニズムをクライアント側に委任するつもりです。つまり、消費アプリはユーザーが見ることができるアイテムを減らします。あなたの仮定は：

マイクロサービスとその承認システムは、クライアントのニーズに煩わされるべきではありません。なぜなら、彼らは消費者であり、システムの一部ではないからです。

私はここに深刻なビジネスのための2つの深刻な問題を見ています：

• ある悪意のあるユーザー（パートナーの工場など）がクライアントアプリをリバースエンジニアリングしてAPIを見つけ、彼の会社がクライアントに課した制限を回避し、その情報を使用して会社に害を及ぼす場合はどうでしょうか？あなたの会社は損害賠償を請求しますが、パートナー会社はあなたがあなたのデータを十分に保護する手段を与えなかったと主張します。
• 通常、機密データが悪用される（または監査によってリスクが発見される）のは時間の問題であり、管理者はそのデータのより厳密な制御を求めてしまいます。

そのため、このようなイベントを予測し、承認リクエストを処理することをお勧めします。あなたは初期のリエンジニアリング段階にあり、アーキテクチャでこれらを考慮することは（それらをすべて実装していなくても）後よりもはるかに簡単になります。

現在の職務に就く場合は、少なくとも情報セキュリティ担当者に相談してください。

実装方法

あなたにはトリックがあります：

この方法では、トークンスコープのみを追跡する必要があります。

OK、クライアントによって選択されたいくつかの一般的なトークンを使用するつもりです。繰り返しますが、私の目には弱点があります。一部のクライアントはあなたのコントロールを奪われる可能性があるからです。

すでにJWTを使用しているか、他のテクニックを使用しているかはわかりません。ただし、JWTを使用する場合は、ユーザーのIDを保持するIDトークン（および発信元アプリを安全に識別する2番目のトークンを使用することもできます。これにより、社内クライアントと外部クライアントの信頼レベルを区別できます。 ）。

マイクロサービスアーキテクチャを使用する場合、ユーザー管理と認証プロセス（専用サービスとして実行する必要があります）とアクセス制御（各マイクロサービスに固有であり、それぞれがローカルで処理されます）。もちろん、使いやすいように、いくつかの管理クライアントはいくつかのサービスにわたって包括的な概要を提供すべきです。

ここには短い答えもあります。「クライアント」に提供したいすべてのコア機能を自分で実装する必要があります。すでにユーザー認証を行っているため、クライアントにユーザー権限などの基本的な動作を追加させるのは問題があるようです。それを実装するためにクライアントに任せた場合、同じ許可コードの複数の実装を「サポート」することになります。「所有」していなくても、コードにバグがあり、クライアントに期待どおりの機能を持たせたいと思うので、クライアントが抱えている問題の解決をサポートします。複数のコードベースをサポートするのは楽しいことではありません。