12.2. カスタムモジュール
JaasSecurityManager
には Subject
プリンシパルのセットの特定の使用パターンが必要です。JAAS Subject クラスの情報ストレージの機能および JaasSecurityManager
と動作するログインモジュールを書くためのこうした機能の必要な使用方法を理解しておく必要があります。
LoginModule
実装を紹介します。
Subject
と関連付けられたセキュリティ情報を取得できます。
Subject
アイデンティティとロールに関しては、JBossSX は getPrincipals()
と getPrincipals(java.lang.Class)
により取得されるプリンシパルのセットという最も論理的な選択をしました。使用パターンは以下のとおりです。
- ユーザーアイデンティティ (例えばユーザー名、ソーシャルセキュリティ番号、従業員 ID) は
Subject
Principals
セットのjava.security.Principal
オブジェクトとして保存されます。ユーザーアイデンティティを表すPrincipal
実装は、プリンシパルの名前に関する比較と等値で始める必要があります。適切な実装はorg.jboss.security.SimplePrincipal
クラスとして使用できます。他のPrincipal
インスタンスは必要に応じてSubject
Principals
セットに追加できます。 - 割り当てられたユーザーロールも
Principals
セットに保存され、java.security.acl.Group
インスタンスを使用して名前付きロールセットでグループ化されます。Group
インターフェースはPrincipal
/Group
の集まりを定義し、java.security.Principal
のサブインターフェースとなります。 Subject
に割り当てるロールセットの数はいくつでも構いません。
- JBossSX フレームワークは
Roles
とCallerPrincipal
という名前のよく知られた 2 つのロールセットを使用します。Roles
グループはSubject
が認証されたアプリケーションドメインで知られた名前付きロールに対するPrincipal
の集まりです。このロールセットはEJBContext.isCallerInRole(String)
のようなメソッドで使用され、EJB は現在の呼び出し側が名前付きアプリケーションドメインロールに属しているか確認するためにこれを使用できます。メソッドパーミッションの確認を実行するセキュリティインターセプタのロジックもこのロールセットを使用します。CallerPrincipal
Group
はアプリケーションドメインのユーザーに割り当てられた単一のPrincipal
アイデンティティで構成されます。EJBContext.getCallerPrincipal()
メソッドはCallerPrincipal
を使用して、アプリケーションドメインが動作環境アイデンティティからアプリケーションに適したユーザーアイデンティティにマップすることができます。Subject
にCallerPrincipal
Group
がない場合は、アプリケーションアイデンティティは動作環境アイデンティティと同じです。
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()
内から呼び出されます。