GlassFish の PAM/Solaris レルムを利用する (ja)

GlassFishが標準で備えている認証レルムを試してみるこの連載も、今回でひとまず最終回となります。本当はCertificateレルムとカスタムレルムが残っているのですが、前者は電子証明書を必要とすること、後者はJAAS/JACCのカスタムモジュールを開発しなければならないことから、今回は対象から外すことにしました。Certificateレルムの動作確認にはCA署名を持つ正式な電子証明書の取得と公開サーバーの準備が必要で、それだけで相当の労力を取られてしまうので、あまり現実的とは言えません。

このようなケースでは一般的に自己署名証明書を使う方法が採られますが、ルートCAからの証明書チェーンが上手く機能していることを証明できないため、個人的には避けたいと考えています。環境を整備するための資金を提供するから確かめて欲しいというのであれば話は別ですが...

さて、今回取り上げるPAMレルムとSolarisレルムですが、いずれもOSの認証APIを利用する点では変わりません。また、WindowsなどPAMを使用しないOSでも使用することはできません。従って、基本的にはUnix/Linux専用だと思って頂ければ良いかと思います。

1. PAMレルム
ユーザー認証にOSのPAMのAPIを使用するレルムです。GlassFishの動作保証の範囲では、Solaris、Linux、Mac OS X、AIXが該当します。なお、HP-UXでも動作したという話を耳にしたことがあるので、PAMに対応したOSであれば基本的に動作するかと思います。

設定そのものは簡単で、OS側に認証するユーザーとグループ(POSIX準拠)が揃っていれば、GlassFishでレルムを作成してPAMレルムに指定するだけです。設定項目は以下の通りです(追加プロパティは不要です)。
  • 名前 -- 任意(pam などわかりやすい名前を推奨)
  • クラス名 -- com.sun.enterprise.security.auth.realm.pam.PamRealm
  • JAASコンテキスト -- pamRealm
私の手元ではRed Hat Enterprise Linux 6での動作確認を行いました。Solaris 10でも検証を試みましたが、LDAPサーバー構築と重なりPAM関係の設定が不十分であったこともあり、成功しませんでした。ただし、PAM自体は基本的に大抵のUnix/Linuxに対応しているので、OS側のPAM設定が正しければ問題なく動作するはずです。

ちなみに、PAMは標準のOS認証(/etc/passwd、/etc/shadow、/etc/groupを使う)だけでなく、他の名前解決サービス、具体的にはLDAPやNISと連携させることができます。つまり、PAM-LDAP連携が確立しているシステム上では、敢えてLDAP認証を使わなくてもPAM認証で代用できることを示唆しています。
ただし、PAM認証で使用するユーザー認証データはPOSIXで規定されたOS認証のためのものであるため、追加情報を埋め込む余地がほとんどありません。その点、JDBCレルムやLDAPレルムに比べて柔軟性に欠けます。

2. Solarisレルム
名前の通りSolaris専用のレルムです。Solaris 9以降の環境下で動作するGlassFishでのみ使用できます。実際に私がRed Hat Enterprise Linux 6上でSolarisレルムを使用したところ、認証プロセスが全く働きませんでした。

設定自体はPAMレルムとほぼ同様です。
  • 名前 -- 任意(solaris などわかりやすい名前を推奨)
  • クラス名 -- com.sun.enterprise.security.auth.realm.solaris.SolarisRealm
  • JAASコンテキスト -- solarisRealm
ユーザー認証データもSolarisで使用可能なものを準備します。こちらもPOSIX準拠ですので、PAM認証の場合と同様に追加情報を埋め込む余地がほとんどありません。

3. 誰が使うのか?
PAMレルムやSolarisレルムは環境依存の仕組みであるため、JDBCレルムやLDAPレルムに比べて汎用性に欠き、またこれらほど大規模なユーザー認証データベースを構築するのも難しいと考えられます。では、なぜこのような認証レルムがGlassFishに実装されたのでしょう?

私の知る限り、PAMレルムやSolarisレルムが実装されたのは比較的最近のことです。気付いたらレルム選択でこれらが選べるようになっていた、というのが率直なところです。

理由の1つとしては、OSとGlassFishの認証を統一するという発想が考えられます。既にWindowsでは、Windows Serverと各種サーバー製品(SQL Server等)の認証をWindows側の認証で統一できる仕組みが提供されています。これはこれで問題点も指摘されてはいますが、システム全体で統一した認証を使用できることは運用側の負荷を多少なりとも軽減させることができます(覚えなければならないパスワードの種類が減ると言うことです)。BtoCレベルでもOpenIDなどの統一認証が普及してきており、この傾向はあながち間違いとも言い切れないかと思います。

GlassFishの持つ主要なレルムの解説は今回にてひとまず終了となります。今後も機会を見てGlassFishと認証の話題は掲載してゆきたいと考えていますので、よろしくお願いします。