Spring Securityの機能について簡単に見ていきましょう。
SpringSecurityは、認証と認可の機能を提供してくれます。
WEBが分かりやすいと思いますが、一般的なWEBは、IDとパスワードを入力して両方とも合っていればログインできると思います。
この処理を認証と呼んでいて、さらに認証できた人に対してある画面を見せるか見せないか、という閲覧権限の機能も存在します。
これを認可と言います。
SpringSecurityでは両方ともを設定ファイルのみで実装できます。
かなりパワフルな機能です。
しかも、拡張して独自の機能をつけることもできます。
また、WEBだけでなく普通のJavaアプリケーションに対しても認証と認可の機能を実装できるようです。
【機能の実際】
ここでは、SpringSecurityのWEBの認証と認可の処理がどのような機能なのかを簡単に見てみましょう!
項目 | 概要 |
---|---|
ログイン方法 | 一般的な認証と同様、ログイン画面からID/PWを入力してWEBに入ります。 |
ログアウト方法 | 指定のURLにアクセスするとログアウトします。 このとき、セッションの情報を保持しておくこともできるようです。 これにより、次回ログイン画面を開いたときに、最後にアクセスしたユーザのIDを表示することもできるようです。 |
認証が必要な画面にログインせずにアクセスした場合 |
ログイン画面に強制的に遷移させられます。 その後、ログインに成功すると最初にアクセスしようとした画面を表示します。 ログイン後、常に指定の画面を表示するようにすることもできます。 |
権限ロール | 権限ロールがあり、自由に追加できます。 SpringSecurityでは、権限ロール自体に何か意味があるのではなく、グループを分けるグループ名くらいの意味しかありません。 ただし、予約名が存在し、それは意味が決まっています。 良く使う予約名には以下のものがあります。 IS_AUTHENTICATED_FULLY ・・・認証されたユーザすべて IS_AUTHENTICATED_ANONYMOUSLY ・・・認証されたユーザと認証されていないユーザすべて |
認可の方法 | WEBのパス名に対して認可をします。(リクエストパラメタに対して行う方法もあるようですがここでは説明しません。) 設定イメージは、以下のようになります。 【設定イメージ】 /secure/sys* ⇒ ROLE_ADMIN /secure/* ⇒ ROLE_ADMIN,ROLE_USER /** ⇒ IS_AUTHENTICATED_ANONYMOUSLY 【意味】 設定の順番には意味があります。 上から順番にURLを見ていき、最初に引っかかったところでロールのチェックをします。 では、上記の例の場合を見てみましょう。 ----------------------------- /secure/の下の頭に"sys"が付くURLに対しては、ROLE_ADMINというグループに閲覧を許します。 上記以外の、/secure/直下のURLに対しては、ROLE_ADMIN と ROLE_USERというグループに閲覧を許します。 上記以外の、ドキュメントルート配下のURLに対しては、すべてのユーザに閲覧を許します。 ----------------------------- *は、ワイルドカードで/以外の文字を表します。 上記では、/security/sysTop.do や/security/sysRegist.doなどが対象になります。 **はディレクトリまで含めてすべてのワイルドカードです。 上記では、/A/include/main.css や /login.html などが対象になります。 |
組み込み方法 | SpringSecurityは、どうやって機能を実現しているのでしょうか? 実は、SpringSecurityはtomcatのフィルター 機能なのです。 ですので、Servletを実装するときに、何か特殊なクラスを継承しないといけないとか、必ず何かのメソッドを呼ばないといけないなどの制約を受けません。 Strutsを使っても、SpringMVCを使ってもかまいません! |
【動作】
上記で、ログイン・ログアウト、認可の方法がなんとなく分かったと思います。
ここでは、実際のログインの動作を見てみましょう。
基本の動きは、リダイレクトを使用しています。
①ログイン画面を表示します
②ID/PWが送信されると認証を行います。認証NGなら指定のエラー画面を表示します。
③認証OKなら、リダイレクトで指定のURLに遷移します。
③では、上記一覧表の「認証が必要な画面にログインせずにアクセスした場合」の内容も見てみてください。
こんな機能もあります。
【注意点】
パス名で認可をするため、パスの命名規則はしっかりと設計しておいた方がいいと思います。
これはシステムを設計する段階で決めておくべきです。
なぜならたいていの場合、デザイン(HTML)にパスをハードコーディングすることになるので、後ですべてのパスを変更するのが大変だからです。
ワイルドカードの"*"が使用できないので大変!、というだけで、設定できないわけではありません。
ですので、既に使用されているシステムに途中からSpringSecurityで認証・認可の機能をつけることはできます。
ただ、システムを新規作成するときにSpringSecurityの導入を決めているなら
設定しやすいようにパスの命名規則を決めておいた方がいいと思います!
【機能拡張について】
機能拡張は他の記事 で触れようと思います。
ここでは軽く触れるにとどめます。
Springは基本的に、設定のタグ1つに付き、1つのクラスが担当するので、変更したい設定タグの機能が
どのクラスに相当するのかを調べて、そのクラスを拡張するだけでよいです。
ただし、認証のフィルタについて勉強しておく必要があります。
大雑把に書きますが、SpringSecurityの機能は複数のフィルタで成り立っていて、順番にフィルタが実行されています。
フィルタは実行順番が決まっているので、目的の機能の前にフィルタが働いて、そこで処理が終わると
自分が作った機能まで処理が回ってこない可能性もあります。
この辺が注意点かと思います。
かなりパワフルな機能で、拡張しなくても事足りると思います。
ぜひぜひ使って楽をしましょう
参考:
・実際に認証と認可をWEBにつけるには? (基礎編:設定方法)
・DBのユーザ情報を使用して認証するには? (実践編:DBを使用する方法)
・ログイン後の画面にログインしたユーザを表示するには? (ログイン情報の表示方法)
・ロール(権限)によって画面のリンクの表示/非表示を制御するには?