Apache Taro ユーザーマニュアル (1) Roku アーキテクチャの概要

Apache Taro ユーザーマニュアル (1) Roku アーキテクチャの概要

1.Shiro とは

Apache Taro は、認証、承認、暗号化、およびセッション管理機能を提供する強力で使いやすい Java セキュリティ フレームワークです。 - ユーザー ID 認識 (ユーザー「ログイン」と呼ばれることもあります);
認証 - アクセス制御;
パスワード暗号化 - データを覗き見から保護または隠す;
セッション管理 - 各ユーザーに関連付けられた時間に敏感な状態。

どのようなアプリケーションに対しても、Shiro は包括的なセキュリティ管理サービスを提供できます。また、他のセキュリティ フレームワークと比較して、Shiro ははるかにシンプルです。

2.Shiro のアーキテクチャの紹介

まず、Shiro の 3 つのコアコンポーネントを見てみましょう: 以下に示すように:

サブジェクト: つまり、「現在の操作ユーザー」です。 ”。ただし、Shiro では、サブジェクトの概念は人だけを指すのではなく、サードパーティのプロセス、バックグラウンド アカウント (デーモン アカウント)、またはその他の同様のものを指す場合もあります。それは単に「ソフトウェアが現在対話しているもの」を意味します。しかし、ほとんどの目的や用途では、Shiro の「ユーザー」の概念と考えることができます。

Subject は現在のユーザーのセキュリティ操作を表し、SecurityManager はすべてのユーザーのセキュリティ操作を管理します。

SecurityManager: これは、Shiro フレームワークのコアであり、典型的な Facade モードです。Shiro は、SecurityManager を使用して内部コンポーネント インスタンスを管理し、それを通じてセキュリティ管理のためのさまざまなサービスを提供します。

レルム: レルムは、Shiro とアプリケーションのセキュリティ データ間の「ブリッジ」または「コネクタ」として機能します。つまり、ユーザーの認証 (ログイン) と認可 (アクセス制御) の検証を実行する際、Shiro はアプリケーションに設定されたレルムからユーザーとその権限情報を検索します。

この意味で、Realm は本質的にセキュリティ関連の DAO です。データ ソースの接続の詳細をカプセル化し、必要に応じて関連データを Shihiro に提供します。 Shiro を構成するときは、認証および/または認可のために少なくとも 1 つのレルムを指定する必要があります。複数のレルムを構成できますが、少なくとも 1 つが必要です。

Shiro には、LDAP、リレーショナル データベース (JDBC)、INI のようなテキスト構成リソースやプロパティ ファイルなど、多数の安全なデータ ソース (ディレクトリとも呼ばれます) に接続できる Realm が組み込まれています。デフォルトの Realm がニーズを満たさない場合は、カスタム データ ソースを表す独自の Realm 実装をプラグインすることもできます。

Shiro の完全なアーキテクチャ図:

上記の Subject、SecurityManager、および Realm の 3 つのコア コンポーネントに加えて、Shiro の主要コンポーネントには以下も含まれます:

Authenticator: 認証は、ユーザー ID を検証するプロセスです。このプロセスの一般的な例は、よく知られた「ユーザーとパスワード」の組み合わせです。ほとんどのユーザーはソフトウェア システムにログインするときに、通常、自分のユーザー名 (プリンシパル) と自分をサポートするパスワード (証明書) を入力します。システムに保存されているパスワード (またはパスワード表現) がユーザーが提供したものと一致する場合、認証されたとみなされます。

承認者: 承認は本質的にアクセス制御であり、ユーザーがリソース、Web ページなど、アプリケーション内のどのコンテンツにアクセスできるかを制御します。

SessionManager: セキュリティ フレームワークの世界では、Apache Taro はユニークなものを提供します。それは、アプリケーションまたはアーキテクチャ層でのセッション API の一貫した使用です。つまり、Shiro は、小規模なバックエンドのスタンドアロン アプリケーションから大規模なクラスター化された Web アプリケーションまで、あらゆるアプリケーションに会話型プログラミング パラダイムを提供します。これは、セッションを使用したいアプリケーション開発者がサーブレットまたは EJB コンテナの使用を強制されないことを意味します。あるいは、これらのコンテナが使用されている場合、開発者はサーブレットや EJB メカニズムの代わりに、任意の層で一貫したセッション API を使用することを選択できるようになりました。

CacheManager:Shiro の他のコンポーネントにキャッシュのサポートを提供します。

上記は Apache Taro ユーザーマニュアル (1) の内容です。 詳細については、PHP 中国語 Web サイト (www.php.cn) をご覧ください。