第4章 JBoss セキュリティ拡張アーキテクチャ
一般的な JBoss セキュリティレイヤに関する前述の説明では、JBoss セキュリティ拡張フレームワーク (JBossSX) がセキュリティレイヤインターフェースの実装であると記載しました。これが JBossSX フレームワークの第一の目的です。フレームワークにより、既存のセキュリティインフラストラクチャと統合するカスタマイズの可能性が高くなります。セキュリティインフラストラクチャはデーターベースまたは LDAP サーバーから高度なセキュリティソフトウェアスィートまで何でも構いません。JAAS フレームワークで使用できる プラグ可能な認証モデル (PAM) を使用し、柔軟性のある統合が実現します。
JBossSX フレームワークの中核は
org.jboss.security.plugins.JaasSecurityManager
です。これは AuthenticationManager
と RealmMapping
インターフェースのデフォルト実装です。図4.1「<security-domain> デプロイメント記述子の値、コンポーネントコンテナ、JaasSecurityManager 間の関係」 は、対応するコンポーネントのデプロイメント記述子の <security-domain> 要素を基にした EJB と Web コンテナレイヤへの JaasSecurityManager
の統合方法について示しています。
図4.1 <security-domain> デプロイメント記述子の値、コンポーネントコンテナ、JaasSecurityManager 間の関係
図4.1「<security-domain> デプロイメント記述子の値、コンポーネントコンテナ、JaasSecurityManager 間の関係」 では、セキュリティドメイン
jwdomain
でセキュアな EJB と Web コンテンツを含むエンタープライズアプリケーションを示しています。EJB と Web コンテナにはセキュリティインターセプタを含む要求インターセプタアーキテクチャがあり、これによりコンテナセキュリティモデルを強制実施します。デプロイメント時に、jboss.xml
と jboss-web.xml
記述子の <security-domain> 要素値を使用して、コンテナに関連付けられたセキュリティマネージャインスタンスを取得します。次にセキュリティインターセプタはセキュリティマネージャを使用して、そのロールを実行します。セキュアなコンポーネントが要求されると、セキュリティインターセプタはセキュリティチェックをコンテナに関連付けられたセキュリティマネージャインスタンスに委譲します。
JBossSX
JaasSecurityManager
実装は、<security-domain> 要素値と一致する名前のもとで設定される JAAS ログインモジュールを実行することで得られる Subject
インスタンスに関連付けられた情報を基にセキュリティチェックを行います。次項では JaasSecurityManager
実装とその JAAS の使用について詳しく見ていきます。
4.1. JaasSecurityManager による JAAS の使用方法
JaasSecurityManager
は JAAS パッケージを使用して、AuthenticationManager
と RealmMapping
インターフェース動作を実装します。特に、その動作は JaasSecurityManager
が割り当てられたセキュリティドメインと一致する名前のもとで設定されたログインモジュールインスタンスを実行することで発生します。ログインモジュールはセキュリティドメインのプリンシパル認証とロールマッピング動作を実装します。こうして、ドメインに対して異なるログインモジュール設定をプラグインするだけで異なるセキュリティドメインに渡り JaasSecurityManager
を使用することができます。
JAAS 認証プロセスにおける
JaasSecurityManager
の使用方法の詳細を図解するため、EJB ホームメソッド呼び出しのクライアント呼び出しを見ていきます。前提条件となる設定は、EJB が JBoss サーバーでデプロイされ、そのホームインターフェースメソッドが ejb-jar.xml
記述子の <method-permission> 要素を使用してセキュアであること、JBoss サーバーには jboss.xml
記述子 <security-domain> 要素を使用して jwdomain
という名前のセキュリティドメインが割り当てられることです。
図4.2 セキュアな EJB ホームメソッド呼び出しの認証と承認のステップ
図4.2「セキュアな EJB ホームメソッド呼び出しの認証と承認のステップ」 はサーバー通信にクライアントのビューを提供します。実行手順は以下のとおりです。
- クライアントは JAAS ログインを実行して、認証に対してプリンシパルと資格情報を確立する必要があります。図では Client Side Login (クライアント側のログイン) と記されています。これがクライアントが JBoss でログインアイデンティティを確立する方法です。JNDI
InitialContext
プロパティによりログイン情報を提示するサポートは別の設定で行われます。JAAS ログインでは、LoginContext
インスタンスを作成し、使用する設定名を渡すことが必要です。設定名はother
です。この 1 度きりのログインによってログインプリンシパルと資格情報をすべての後続 EJB メソッド呼び出しに関連付けます。このプロセスではユーザーを認証しない場合があることに注意してください。クライアント側ログインの性質は、クライアントが使用するログインモジュール設定に依存しています。この例ではother
クライアント側のログイン設定エントリはClientLoginModule
モジュール (org.jboss.security.ClientLoginModule
) を使用するよう設定されています。これはサーバー上で後ほど行われる認証に対して単にユーザー名とパスワードを JBoss EJB 呼び出しレイヤにバインドするデフォルトのクライアント側のモジュールです。クライアントのアイデンティティはクライアント上では認証されません。 - クライアントは EJB ホームインターフェースを取得し、Bean の作成を試みます。このイベントは Home Method Invocation (ホームメソッド呼び出し) と記されます。これにより、ホームインターフェースメソッド呼び出しが JBoss サーバーに送られます。呼び出しには、ステップ 1 で行われたクライアント側の JAAS ログインからのユーザーアイデンティティと資格情報とともに、クライアントから渡されるメソッド引数が含まれます。
- サーバー側ではセキュリティインターセプタは最初にコールを呼び出すユーザーの認証が必要となり、クライアント側では JAAS ログインが必要です。
- EJB がセキュアであるセキュリティドメインがログインモジュールの選択を行います。セキュリティドメイン名は
LoginContext
コンストラクタに渡されるログイン設定エントリ名として使用されます。EJB セキュリティドメインはjwdomain
です。JAAS ログインがユーザーを認証すると、PrincipalsSet
に以下を含む JAASSubject
が作成されます。java.security.Principal
は、デプロイメントセキュリティ環境で既知のクライアントアイデンティティに該当します。Roles
という名前のjava.security.acl.Group
には、ユーザーが割り当てられるアプリケーションドメインからのロール名が含まれています。org.jboss.security.SimplePrincipal
オブジェクトを使用してロール名を表します。SimplePrincipal
はシンプルな文字列をベースにしたPrincipal
の実装です。こうしたロールを使用して、ejb-jar.xml
にあるメソッドに割り当てられたロールとEJBContext.isCallerInRole(String)
メソッド実装を検証します。CallerPrincipal
という名前のオプションのjava.security.acl.Group
には、アプリケーションドメインの呼び出し側のアイデンティティに該当する単一のorg.jboss.security.SimplePrincipal
が含まれます。CallerPrincipal
の唯一のグループメンバーはEJBContext.getCallerPrincipal()
メソッドにより返される値となります。このマッピングの目的は、セキュリティ動作環境で既知のPrincipal
がアプリケーションに既知の名前を持つPrincipal
にマップできるようにすることです。CallerPrincipal
がないと、デプロイメントセキュリティ環境のプリンシパルのマッピングがgetCallerPrincipal
メソッド値として使用されます。つまり、動作しているプリンシパルはアプリケーションドメインのプリンシパルと同じです。
- セキュリティインターセプタチェックの最後のステップは、認証されたユーザーが要求されたメソッドを呼び出すパーミッションを持っていることの確認です。これは 図4.2「セキュアな EJB ホームメソッド呼び出しの認証と承認のステップ」 で Server Side Authorization (サーバー側の承認) と記されています。承認を実行することで、次のステップを実行する必要があります。
- EJB コンテナから EJB メソッドへのアクセスを許可したロール名を取得します。ロール名は呼び出されたメソッドを含むすべての <method-permission> 要素の
ejb-jar.xml
記述子 <role-name> 要素により決定されます。 - 割り当てられたロールがない場合や、exclude-list 要素でメソッドが指定されていない場合は、メソッドへのアクセスは拒否されます。そうでない場合は、
doesUserHaveRole
メソッドはセキュリティインターセプタによりセキュリティマネージャで呼び出され、呼び出し側が割り当てられたロール名を持っているか確認します。このメソッドはロール名を使って反復し、認証されたユーザーの SubjectRoles
グループが割り当てられたロール名を持つSimplePrincipal
を含んでいるか確認します。ロール名がRoles
グループのメンバーである場合はアクセスは許可されます。いずれのロール名もメンバーでない場合はアクセスは拒否されます。 - EJB がカスタムのセキュリティプロキシで設定された場合、メソッド呼び出しはそれに委譲されます。セキュリティプロキシが呼び出し側へのアクセスを拒否したい場合は、
java.lang.SecurityException
を投げます。SecurityException
が投げられなかった場合は、EJB メソッドへのアクセスは許可され、メソッド呼び出しは次のコンテナインターセプタに渡されます。SecurityProxyInterceptor
がこのチェックを処理するため、このインターセプタは表示されないことに注意してください。 - JBoss Web 接続では、Tomcat がセキュリティ制約の要素とロール検証を管理します。Web 接続に対して要求が受け取られると、Tomcat は要求されたリソースとアクセスされた HTTP メソッドに一致する
web.xml
で定義されたセキュリティ制約を確認します。ある制限が要求に対して存在する場合、Tomcat は JaasSecurityManager を呼び出してプリンシパルの認証を実行します。これにより確実にユーザーロールがそのプリンシパルのオブジェクトと関連付けられているようにします。唯一 Tomcat がロールの検証を実行します。例えばallRoles
などのパラメータやSTRICT_MODE
が使用されたかどうかを確認します。
すべてのセキュアな EJB メソッド呼び出し、またはセキュアな Web コンテンツアクセスには呼び出し側の認証と承認が必要です。その理由は、セキュリティ情報は各要求で表示、検証される必要がある要求のステートレス属性として処理されるためです。JAAS ログインにクライアントとサーバー間の通信が含まれる場合、これはコストの高い操作となる場合があります。このため、
JaasSecurityManager
は前の成功したログインからのプリンシパルと資格情報を保存するために使用する認証キャッシュの概念をサポートします。次項の関連する MBean サービスに関する説明のとおり、JaasSecurityManager
設定の一部として使用する認証キャッシュのインスタンスを指定できます。ユーザー定義のキャッシュがない場合は、設定可能な期間中に資格情報を管理するデフォルトキャッシュが使用されます。