Welcome to the jGuard's wiki » 全体像 » どういう仕組みか?

どういう仕組みか?

Last modified by RaffaelloPelagalli on 2006/01/13 05:32

どういう仕組みか?

net.sf.jguard.filters.AccessFilterクラスが、WebアプリケーションとjGuardの中心の接着剤となります。アクセス制御は、AccessFileterクラスを通して行われます。AccessFilterは サーブレット・フィルター(javax.servlet.Filter)で 以下の仕事を行います。

  • Webアプリケーションのアクセス制御の設定
  • ユーザー認証
  • あるURLへの未承認アクセスの拒否
  • ユーザのログオフ(ユーザはログインが最後必要になる)
jGuardによって保護されるリソースをどうするかは、フィルター設定の中で設定されます。これはweb.xmlのフィルタマッピングタグのURLパターン属性により設定されますので jGuardにWebアプリケーション全体を保護させることもできますし、ある特定の一部分を保護させる(StrutsActionの様に)こともできます。

Webアプリケーションが 読み込まれるときに、AccessFilterは jGuardPolicyが 現在のセキュリティ・ポリシーかどうかを 調べます。もし、JGuradが現在nセキュリティ・ポリシーでない場合、AccessFilterはjGuardPolicyを現在のセキュリティ・ポリシーとして設定します。jGuardは 全てのセキュリティ関連の決定をするわけではありませんが、jGuardの設定された1つ以上のWebアプリケーションのセキュリティを担当し、その他のセキュリティ関連の設定は、最後に使用されたセキュリティ・ポリシーに 任せます。

AccessFilterは、読み込まれるときに、Web.xmlから全ての設定情報を読み取り PermissionProviderを現在のクラスローターに 登録します。下の図は、以下で説明しているように ユーザーが 保護されたURLにアクセスする際のAccessFilterの実行フローを表しています。:

  1. ユーザーが保護されたURLへアクセスを試みる。AccessFilterはHTTPリクエストを、途中で受け取り そのURLが特別なURLかどうかを調べる。(すなわち LogonURL、authenticationFailedURI、accessDeniedURIのようなだれでもアクセスできる保護されていないURLかどうかを調べる。)そして 特別なURLの場合には、フローは、Step2へいく。それ以外は、Step3へ。
  2. Httpリクエストは、そのまま進み、ユーザーは、希望するURLへ行く。
  3. AccessFilterは ユーザーが認証済みかどうかをチェックする。ユーザーが認証されていない場合、フローはStep4へ。認証されている場合、Step8へ。
  4. フィルターは、リクエストの内部にログインユーザーIDとパスワードデータかあるかチェックする。もし それらの情報無い場合、jGuardはlogin/passwordが Guest/guestという情報を使い、guestユーザーとして認証する。そしてStep5へ。
  5. フィルターは、ユーザー認証をLoginModuleを使って行う。認証が成功したら Step6へ、失敗したばあいStep7へ。
  6. 認証の結果 作成されるSubjectデータは、セッションの保持され、ユーザーはindexURIページへリダイレクトされる。
  7. ユーザーは、認証失敗のため authenticationFailedURI へリダイレクトされる。
  8. フィルタは、URLがlogoffURI(ユーザーがログオフする意図を示すという意)かどうかチェックし、フローは、そうである場合 Step9へ、そうでない場合 STEP10へ。
  9. Subjectオブジェクトは セッションから除去され Sessionは 無効化される。ユーザーはlogoffURIへリダイレクトされる。
  10. jGuardは、ユーザーがそのURLへアクセス権を持つかどうかチェックする。アクセス権をもつとは、そのユーザーのプリンシパル(ロール)にひもついたパーミッションが いま対象としているURLへのパーミッションを暗示しているいるということ。(たとえば、そのロールのパーミッションが /webapp1/aaa であれば前方一致の /webapp1/aaa/bbbもパーミッションに含む(暗示する)。(ver0.7より前)。ver0.7以上だと/webapp1/aaa* というパーミッションURLとなる)。もしユーザーがアクセス権をもつのであれば STEP11へ、持たないのであれば Step12へ。
  11. ユーザーは、 希望のページへリダイレクトされる。
  12. ユーザーは、希望のURLへのアクセス権を持たないため accessDeniedURI へリダイレクトされる。
下の図が示しているように、全てのアクセス制御は、フィルターによって実行される。これについての 一番重要な利点は、簡単なマッピングにより アクセス制御の変更ができるという柔軟性を持つことができることである。 The main advantage is that user has the flexibility of enable or disable the access control by simple mapping or not the filter.(←ここの not the filter の意味がわからない。)

jaAccessFilterWorkflow.png

Tags:
Created by Masa Naka on 2006/01/11 04:40

jGuard team copyright 2004-2009
3.1.1