こんばんは。yumix と申します。
前回、これっきりにしてくださいと言ったはずなのに、またゲスト寄稿させて頂くことになりました。今度こそ最後だと思いますが、どうぞよろしくお付き合いください。
さて、前回は、GlassFishのBASIC認証とセキュリティロールと題しまして、BASIC 認証の大まかな流れと、認証・許可・セキュリティロールといったことについてご説明しました。簡単に復習しますと、
認証とは...
- サーバにアクセスしてきたユーザが本当にそのユーザか (そのユーザを騙る別人でないか) を確認すること。
- 認証は原則としてそれぞれのサーバ単位で行う。認証されたユーザはグループという単位でまとめられることが多い。
許可とは...
- 認証したユーザに対して、やってよいこと (あるいはやってはいけないこと) を定めること。
- 許可はアプリケーション単位で行う。許可はセキュリティロール (あるいは単にロール) ごとに決める。
- 認証したユーザは、アプリケーションごとに glassfish-web.xml / sun-web.xml などでロールに関連付けられる。
今回は認証について見てゆきます。
まず、一般論として、認証はどのタイミングで行われるのでしょうか？
例えば Apache HTTP Server の認証について考えてみます。ブログ主は iPlanet Web Server にご執心のようでとにかく iPlanet を持ち出そうとしますが、私も iPlanet は良い製品だとは思いますがそこまでの思い入れもないので、素直に Apache を取り上げます。
さて、Apache で公開するリソースに対して認証を課す場合には、大きく次の二通りの方法があります。
- httpd.conf に対象となるリソースを <Directory /> で指定する。
- 個別のリソースに対して .htaccess ファイルを置く。
Apache の場合、実際にはこれらの設定の中で許可についても指定してしまうため、純粋に認証だけを設定するわけではないのですが、これらの設定がきっかけとなり BASIC 認証や DIGEST 認証が行われるようになります。
これを見る限り Apache では許可を設定した場合には必ず認証も一緒についてきます。この傾向は Web のシステムでは一般的のようです。私も Apache と GlassFish と Tomcat しか知らない身なので何とも言えませんけど。
そもそも、認証だけ行っても、その後の許可がなければなんの意味も持たないので、許可を設定すれば認証もされるようになるという流れは、ある意味自然なのかもしれません。
Apache の場合は以上ですが、GlassFish についてはどうでしょう？
これは GlassFish に限らず Tomcat にも共通するのですが、アプリケーションの web.xml に <security-constraint /> が存在し、その中に許可の記述が存在すれば、認証が行われるようになります。
許可の対象としてリソースの URL パターン (/admin/* など)、許可として HTTP のメソッド (GET, POST, PUT, DELETE)、許可の対象としてロール名を指定します。例えば、こんな感じ:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<!-- snip -->
<security-constraint>
<web-resource-collection>
<web-resource-name>ReadOnly</web-resource-name>
<url-pattern>/protected/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Admin</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>file</realm-name>
</login-config>
</web-app>
この例では、<security-constraint /> の後に <login-config /> があり、そこで BASIC 認証を使うことと file という名前のレルムを使うことを指定している、ように取れます。実際にそうなのですが。
<auth-method> を BASIC 以外、例えば DIGEST などにすると、その方式で認証が行われるようになります。
レルム、というのは認証に使う仕組み、例えばユーザの一覧はどこから取得するのか (GlassFish ではファイル、JDBC、LDAP、UNIX PAM 認証、Solaris 認証が使用できます)、などをまとめたものです。
GlassFish はアプリケーション用に準備された認証用ファイルを使うファイルレルムがデフォルトです。GlassFish の管理用にも別のファイルレルムが存在します。ファイルレルムのユーザ一覧は管理コンソールで編集することができます。
ちなみに、ファイルレルムのユーザ名とパスワードを記録したファイルは暗号化されていますので、そのままでは読めません。あしからず。
レルムは GlassFish でいくつも作成することができます。ファイルレルムばかり 10 個作る、といったことも可能です。レルムが複数存在する場合はデフォルトレルムを選択する必要がありますが、デフォルトレルムで BASIC 認証を行う分には web.xml の <login-config /> を省略できるようになります。
Servlet 3.0 以降では、web.xml のほとんどを Servlet 本体のアノテーションで代替できるようになりました。<security-constraint /> の代わりに代替となる @ServletSecurity アノテーションを Servlet 本体に設定しても、GlassFish の認証 (と許可) が働くようになります。
今回は、
- HTTP の認証は、リソースへの許可を設定した箇所で (自動的に) 行われる。
- GlassFish の認証は、アプリケーションにおいて web.xml の <servlet-constraint /> か、代替となるアノテーションが存在する場合に行われる。
の二点についてご説明しました。
この調子だとブログ主が図に乗って第三の依頼を出しかねないので、@misaka_shiori bot と遊んでいる暇があったら、21 の小娘に押し付けないで自分で記事を書け! とブログ主に言ってやってください。
