12.2. カスタムモジュール
JaasSecurityManager には Subject プリンシパルのセットの特定の使用パターンが必要です。JAAS Subject クラスの情報ストレージの機能および JaasSecurityManager と動作するログインモジュールを書くためのこうした機能の必要な使用方法を理解しておく必要があります。
LoginModule 実装を紹介します。
Subject と関連付けられたセキュリティ情報を取得できます。
Subject アイデンティティとロールに関しては、JBossSX は getPrincipals() と getPrincipals(java.lang.Class) により取得されるプリンシパルのセットという最も論理的な選択をしました。使用パターンは以下のとおりです。
- ユーザーアイデンティティ (例えばユーザー名、ソーシャルセキュリティ番号、従業員 ID) は
SubjectPrincipalsセットのjava.security.Principalオブジェクトとして保存されます。ユーザーアイデンティティを表すPrincipal実装は、プリンシパルの名前に関する比較と等値で始める必要があります。適切な実装はorg.jboss.security.SimplePrincipalクラスとして使用できます。他のPrincipalインスタンスは必要に応じてSubjectPrincipalsセットに追加できます。 - 割り当てられたユーザーロールも
Principalsセットに保存され、java.security.acl.Groupインスタンスを使用して名前付きロールセットでグループ化されます。GroupインターフェースはPrincipal/Groupの集まりを定義し、java.security.Principalのサブインターフェースとなります。 Subjectに割り当てるロールセットの数はいくつでも構いません。
- JBossSX フレームワークは
RolesとCallerPrincipalという名前のよく知られた 2 つのロールセットを使用します。RolesグループはSubjectが認証されたアプリケーションドメインで知られた名前付きロールに対するPrincipalの集まりです。このロールセットはEJBContext.isCallerInRole(String)のようなメソッドで使用され、EJB は現在の呼び出し側が名前付きアプリケーションドメインロールに属しているか確認するためにこれを使用できます。メソッドパーミッションの確認を実行するセキュリティインターセプタのロジックもこのロールセットを使用します。CallerPrincipalGroupはアプリケーションドメインのユーザーに割り当てられた単一のPrincipalアイデンティティで構成されます。EJBContext.getCallerPrincipal()メソッドはCallerPrincipalを使用して、アプリケーションドメインが動作環境アイデンティティからアプリケーションに適したユーザーアイデンティティにマップすることができます。SubjectにCallerPrincipalGroupがない場合は、アプリケーションアイデンティティは動作環境アイデンティティと同じです。
12.2.1. Subject の使用パターンのサポート リンクのコピーリンクがクリップボードにコピーされました!
Subject 使用パターンの正しい実装を簡略化するために、JBossSX には Subject を強制的に正しく使用するテンプレートパターンを使用して認証された Subject を生成するログインモジュールが含まれています。
2 つのうち最も汎用的なクラスは org.jboss.security.auth.spi.AbstractServerLoginModule クラスです。
javax.security.auth.spi.LoginModule インターフェースの実装を提供し、動作環境セキュリティインフラストラクチャに固有の主要なタスクに対し抽象メソッドが可能になります。そのクラスに関する重要な詳細は 例12.14「AbstractServerLoginModule クラスの一部」 で強調表示されています。JavaDoc コメントがサブクラスの役割を詳しく説明します。
重要
loginOk インスタンス変数は極めて重要です。ログインが成功する場合はtrue に、そうでない場合はログインメソッドを上書きするサブクラスにより false に設定されます。この変数が正しく設定されていないと、コミットメソッドはサブジェクトを正しく更新しません。
例12.14 AbstractServerLoginModule クラスの一部
カスタムのログインモジュールに適する2つ目の抽象ベースログインモジュールは org.jboss.security.auth.spi.UsernamePasswordLoginModule です。
char[] パスワードを認証資格情報として強制することで、カスタムのログインモジュール実装をさらに簡略化します。また、ロールを持たないプリンシパルへの匿名ユーザー (null ユーザー名とパスワードで表示) のマッピングにも対応しています。クラスに関する重要な詳細は次のクラスの一部で強調表示されています。JavaDoc コメントがサブクラスの役割を詳しく説明しています。
例12.15 UsernamePasswordLoginModule クラスの一部
作成中のログインモジュールの認証技術に対して文字列ベースのユーザー名と資格情報の使用が可能であるかによって AbstractServerLoginModule と UsernamePasswordLoginModule のどちらをサブクラス化するか選択します。文字列ベースのセマンティックが有効な場合、サブクラスは UsernamePasswordLoginModule となり、有効でない場合は AbstractServerLoginModule となります。
カスタムのログインモジュールが実行しなければならない手順は、選択するベースのログインモジュールクラスにより異なります。セキュリティインフラストラクチャと統合するカスタムのログインモジュールを書く場合、AbstractServerLoginModule または UsernamePasswordLoginModule をサブクラス化することから始めて、ログインモジュールが認証された Principal 情報を JBossSX セキュリティマネージャーが要求する形式で提供するようにします。
AbstractServerLoginModule をサブクラス化する場合は、次を上書きする必要があります。
void initialize(Subject, CallbackHandler, Map, Map): 解析するカスタムのオプションがある場合。boolean login(): 認証アクティビティを実行するためです。ログインに成功する場合、loginOkインスタンス変数を true に設定するようにします。ログインに失敗する場合は false となるようにします。Principal getIdentity():log()のステップで認証されるユーザーのPrincipalオブジェクトを返すためです。Group[] getRoleSets():login()の間に認証されるPrincipalに割り当てられるロールが含まれるRolesという名前のGroupを最低でも 1 つ返すためです。2 番目の共通のGroupはCallerPrincipalという名前で、セキュリティドメインアイデンティティではなく、ユーザーのアプリケーションアイデンティティを提供します。
UsernamePasswordLoginModule をサブクラス化する場合は、次を上書きする必要があります。
void initialize(Subject, CallbackHandler, Map, Map): 解析するカスタムのオプションがある場合。Group[] getRoleSets():login()の間に認証されるPrincipalに割り当てられるロールが含まれるRolesという名前のGroupを最低でも 1 つ返すためです。2 番目の共通のGroupはCallerPrincipalという名前で、セキュリティドメインアイデンティティではなく、ユーザーのアプリケーションアイデンティティを提供します。String getUsersPassword():getUsername()メソッドで取得できる現在のユーザー名に必要なパスワードを返すためです。getUsersPassword()メソッドはcallbackhandlerがユーザー名と候補パスワードを返した後にlogin()内から呼び出されます。