第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 の統合方法について示しています。
<security-domain> デプロイメント記述子の値、コンポーネントコンテナ、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 という名前のセキュリティドメインが割り当てられることです。
セキュアな EJB ホームメソッド呼び出しの認証と承認のステップ

図4.2 セキュアな EJB ホームメソッド呼び出しの認証と承認のステップ

図4.2「セキュアな EJB ホームメソッド呼び出しの認証と承認のステップ」 はサーバー通信にクライアントのビューを提供します。実行手順は以下のとおりです。
  1. クライアントは JAAS ログインを実行して、認証に対してプリンシパルと資格情報を確立する必要があります。図では Client Side Login (クライアント側のログイン) と記されています。これがクライアントが JBoss でログインアイデンティティを確立する方法です。JNDI InitialContext プロパティによりログイン情報を提示するサポートは別の設定で行われます。
    JAAS ログインでは、LoginContext インスタンスを作成し、使用する設定名を渡すことが必要です。設定名は other です。この 1 度きりのログインによってログインプリンシパルと資格情報をすべての後続 EJB メソッド呼び出しに関連付けます。このプロセスではユーザーを認証しない場合があることに注意してください。クライアント側ログインの性質は、クライアントが使用するログインモジュール設定に依存しています。この例では other クライアント側のログイン設定エントリは ClientLoginModule モジュール (org.jboss.security.ClientLoginModule) を使用するよう設定されています。これはサーバー上で後ほど行われる認証に対して単にユーザー名とパスワードを JBoss EJB 呼び出しレイヤにバインドするデフォルトのクライアント側のモジュールです。クライアントのアイデンティティはクライアント上では認証されません。
  2. クライアントは EJB ホームインターフェースを取得し、Bean の作成を試みます。このイベントは Home Method Invocation (ホームメソッド呼び出し) と記されます。これにより、ホームインターフェースメソッド呼び出しが JBoss サーバーに送られます。呼び出しには、ステップ 1 で行われたクライアント側の JAAS ログインからのユーザーアイデンティティと資格情報とともに、クライアントから渡されるメソッド引数が含まれます。
  3. サーバー側ではセキュリティインターセプタは最初にコールを呼び出すユーザーの認証が必要となり、クライアント側では JAAS ログインが必要です。
  4. EJB がセキュアであるセキュリティドメインがログインモジュールの選択を行います。セキュリティドメイン名は LoginContext コンストラクタに渡されるログイン設定エントリ名として使用されます。EJB セキュリティドメインは jwdomain です。JAAS ログインがユーザーを認証すると、PrincipalsSet に以下を含む JAAS Subject が作成されます。
    • 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 メソッド値として使用されます。つまり、動作しているプリンシパルはアプリケーションドメインのプリンシパルと同じです。
  5. セキュリティインターセプタチェックの最後のステップは、認証されたユーザーが要求されたメソッドを呼び出すパーミッションを持っていることの確認です。これは 図4.2「セキュアな EJB ホームメソッド呼び出しの認証と承認のステップ」 で Server Side Authorization (サーバー側の承認) と記されています。承認を実行することで、次のステップを実行する必要があります。
    • EJB コンテナから EJB メソッドへのアクセスを許可したロール名を取得します。ロール名は呼び出されたメソッドを含むすべての <method-permission> 要素の ejb-jar.xml 記述子 <role-name> 要素により決定されます。
    • 割り当てられたロールがない場合や、exclude-list 要素でメソッドが指定されていない場合は、メソッドへのアクセスは拒否されます。そうでない場合は、doesUserHaveRole メソッドはセキュリティインターセプタによりセキュリティマネージャで呼び出され、呼び出し側が割り当てられたロール名を持っているか確認します。このメソッドはロール名を使って反復し、認証されたユーザーの Subject Roles グループが割り当てられたロール名を持つ 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 設定の一部として使用する認証キャッシュのインスタンスを指定できます。ユーザー定義のキャッシュがない場合は、設定可能な期間中に資格情報を管理するデフォルトキャッシュが使用されます。