Spring Security+Web3.0 署名検証

N17 は Spring Security テクノロジーを使用してプラットフォームのセキュリティ問題を解決します。 Spring フレームワークに基づいて、Spring Security は Web アプリケーション セキュリティの完全なソリューションを提供します。 一般に、Web アプリケーションのセキュリティには、ユーザー認証 (Authentication) とユーザー承認 (Authentication) の 2 つの部分があります。

DAPPで集中化されたデータを呼び出したり、いくつかの集中化された機能を操作したりする場合、DAPPはMetaMaskウォレットを呼び出してデータに署名し、バックグラウンドに渡します.バックグラウンドは、署名データが現在のユーザーのウォレットアドレスによって署名されたデータであるかどうかを検証して認証を行います.

(a) ユーザー認証: ユーザーがシステム内で正当なサブジェクトであるかどうか、つまりユーザーがシステムにアクセスできるかどうかを検証します。 ユーザー認証では、通常、ユーザーはユーザー名とパスワードを提供する必要があります。 システムは、ユーザー名とパスワードを確認して認証プロセスを完了します。 ここで、Dapp フロントエンド エントリは Web3.0 署名データを使用し、バックエンドは Web3.0 とユーザー認証を組み合わせてデータを 2 回検証します。

(b) ユーザー権限: ユーザーが操作を実行する権限を持っていることを確認します。 システムでは、さまざまなユーザーがさまざまな権限を持っています。 たとえば、ファイルの場合、一部のユーザーはそのファイルを読み取ることしかできず、他のユーザーはそれを変更できます。 一般的に言えば、システムはさまざまなユーザーにさまざまな役割を割り当て、各役割は一連の権限に対応します。

システムに多くのモジュールがある場合、各モジュールを承認および認証する必要があります。 そのため、N17 プラットフォームはトークン ベースの承認と認証を選択します。 ユーザーは、ユーザー名とパスワードに従って正常に認証され、現在のユーザー ロールの一連の権限値を取得し、ユーザー名をキーとして使用します。 権限リストは値の形でredisキャッシュに保存され、ユーザー名に関連する情報に従ってトークンが生成されて返されます。 ブラウザーはトークンを Cookie に記録し、API インターフェースが呼び出されるたびに、トークンはデフォルトでヘッダー要求ヘッダーで運ばれます。 Spring Security は、ヘッダーを解析してトークン情報を取得し、トークンを解析して現在のユーザー名を取得し、ユーザー名に従って redis から権限リストを取得します。 このようにして、Spring Security は現在のリクエストにアクセス許可があるかどうかを判断できます。 回路図は以下の通りです:

Last updated