Java アーキテクチャ | SpringCloud 分散アーキテクチャ権限管理

概要

この記事では、分散アーキテクチャの権限管理の 2 つの状況、つまり統合認証アクセスとクロスプラットフォーム インターフェイス アクセスについて説明します。

分散アーキテクチャでは、ビジネスが独立したサブビジネスまたはサブプラットフォームに分割されますが、多くの場合、同じプラットフォーム上で統合された認証とシングル サインオンが行われます。クライアントにとってはプラットフォーム全体がひとつとなり、統一された認可アクセス権限管理となります。ただし、複数のプラットフォームが連携する状況が発生する場合があります。この場合、他のプラットフォームのアーキテクチャを考慮する必要はありません。それらに接続するためのデータ インターフェースを提供するだけで済みます。この場合、クロスプラットフォーム インターフェース アクセスの権限管理を考慮する必要があります。

1. 統合認証アクセス

フロントエンドでは、nginx や haproxy などの Web サーバーを使用します。第 1 層のリバース プロキシとして Nginx が使用され、第 2 層のリバース プロキシとして zuul が使用されます。 2 層リバース プロキシは、基本的に一般的なネットワーク侵入やクローラーに簡単に対処できます。この前提の下で、インターフェース認証やアクセスセキュリティなどの問題に対処し、クライアントとサーバーの両方でセキュリティ制御を実行する必要があります。

1. ユーザーはユーザー名とパスワードを使用してログイン要求を開始します。認証コード、SMS認証、WeChat認証などを使用することでセキュリティレベルを向上させることができます。ログインリクエストは許可センターのZUULにアクセスします。

2. ZUULから権限センターのSERVICEへのリバースプロキシ。

3. ユーザーとロールの情報を照会し、クエリのマッチングを実行します。

4. クエリ結果が得られると、ユーザーのステータス、ユーザー、役割、権限情報などのフィードバックが提供されます。

5. TOKEN を生成します。 TOKEN アルゴリズムは自分で記述する必要があります。暗号化のためにタイムスタンプやその他の情報を追加することをお勧めします。 SESSION に保存するか、REDIS に直接保存します。分散アーキテクチャで SESSION を共有するには、SESSION 共有プールが必要であるため、通常は SESSION に保存することをお勧めします。 SESSION の共有プールは一般的に REDIS で行われ、SESSION は SESSIONID を使用して一意のユーザーを確認できるため、より便利です。

6. ユーザー、ロール、および権限情報をクライアントに返します。

7. ブラウザクライアントは、取得したユーザー、ロール、権限情報を通じてフロントエンド機能とメニューをレンダリングし、許可されていない機能を隠し、この情報に基づいてフロントエンド検証を実行できます。ただし、この検証はクライアント側で行われるため、改ざんされやすいという欠点があります。基本的な保護しか実行できませんが、必要です。

8. ブラウザ クライアントはサーバーにビジネス リクエストを送信します。リクエストには、クライアント メニューまたは機能の権限情報が付随します。サーバーは、ZUUL インターセプターを介してビジネス リクエストをインターセプトし、SESSION 共有プールにアクセスします。

9. 次に、SESSIONID を通じて TOKEN 情報を取得し、TOKEN アルゴリズムを通じて復号化し、ユーザー、ロール、および権限情報を取得します。

10. 一致チェックを実行して、この要求にインターフェイス アクセス権があるかどうかを確認します。チェックに合格すると、インターフェースにアクセスできます。チェックに失敗した場合、インターフェースにアクセスできません。

2. クロスプラットフォームインターフェースアクセス

ここでのインターフェースは、Web サービスに似たクロスプラットフォーム インターフェース サービスを指します。シングル サインオンや統合認証はありません。他のプラットフォームが当社のプラットフォームとリモートでやり取りするためによく使用されます。これら 2 つのプラットフォームは、多くの場合同じ会社または部門のものではないため、インターフェースは長期使用向けではなく、一定の時間制限があります。

1. ユーザー管理者は、外部クライアント ユーザーとその権限情報を設定します。

2. ユーザーデータベースにユーザー情報と権限情報を追加します。

3. 外部クライアントインターフェースにトークンがない場合は、まず権限センターに承認要求を送信する必要があります。

4. 権限センターは、外部クライアントユーザーが設定されているかどうかを確認し、ユーザーの権限情報を取得します。検証に合格すると、暗号化アルゴリズムを通じてトークンが生成されます。ここでのTOKENは実際の状況に基づいています。セキュリティ要件が高い場合は、タイムスタンプが追加され、トークンが期限切れになり無効になり、相手側が再度リクエストできるようになります。

5. TOKEN を REDIS に保存して、TOKEN 共有プールを形成します。ここにはブラウザの SESSIONID がないので、それを SESSION に保存してもあまり意味がありません。

6. TOKENをクライアントに返します。

7. クライアントはトークンを取得した後、サービス インターフェイス アドレスにサービス要求を送信します。

8. ビジネス インターフェイスは ZUUL を介してリクエストをインターセプトし、TOKEN を REDIS TOKEN と比較します。

9. 比較が成功したら、トークンを復号化し、インターフェース認証があるかどうかを確認します。

10. インターフェースが承認されている場合、アクセスが許可されます。そうでない場合、アクセスは許可されません。

Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo の高同時実行性分散などのチュートリアルを網羅した高度な Java 資料を自分で収集する必要があります。