2.8. Security サブシステム
security
サブシステムは JAAS API をベースとし、アプリケーションのセキュリティーインフラストラクチャーを提供します。このサブシステムは現在のリクエストに関連するセキュリティーコンテキストを使用して、認証マネージャー、承認マネージャー、監査マネージャー、およびマッピングマネージャーの性能を関係のあるコンテナーに公開します。
認証および承認マネージャーは認証および承認を処理します。マッピングマネージャーは、情報をアプリケーションに渡す前に、プリンシパル、ロール、または属性に対してその情報を追加、変更、または削除します。監査マネージャーは、ユーザーがプリバイダーモジュールを設定して、セキュリティーイベントの報告方法を制御できるようにします。
ほとんどの場合、security
サブシステムの設定の更新では、管理者はセキュリティードメインの設定のみに集中する必要があります。セキュリティードメインの外部では、変更が必要になる場合があるセキュリティー要素は deep-copy-subject-mode
のみです。ディープコピーサブジェクトモードに関する詳細は、セキュリティー管理 を参照してください。
2.8.1. セキュリティードメイン
セキュリティードメインは JAAS (Java Authentication and Authorization Service) の宣言的なセキュリティー設定で、認証、承認、監査、およびマッピングを制御するために 1 つ以上のアプリケーションによって使用されます。デフォルトでは、jboss-ejb-policy
、jboss-web-policy
、other
、および jaspitest
の 4 つのセキュリティードメインが含まれます。jboss-ejb-policy
および jboss-web-policy
セキュリティードメインは、JBoss EAP インスタンスのデフォルトの承認メカニズムです。これらはアプリケーションの設定済みのセキュリティードメインが認証方法を全く定義しない場合に使用されます。これらのセキュリティードメインと other
は、認証のために JBoss EAP の内部でも使用され、操作の修正に必要です。jaspitest
セキュリティードメインは、開発用に含まれる簡単な JASPI セキュリティードメインです。
セキュリティードメインは、認証、承認、セキュリティーマッピング、および監査向けの設定で設定されます。セキュリティードメインは、JBoss EAP security
サブシステムの一部で、ドメインコントローラーまたはスタンドアロンサーバーによって一元管理されます。ユーザーは、アプリケーションの要件に応じて必要な数のセキュリティードメインを作成できます。
また、cache-type
属性を使用して、セキュリティードメインによって使用される認証キャッシュのタイプを設定することもできます。この属性を削除するとキャッシュは使用されません。このプロパティーに使用できる値は default
または infinispan
です。
Elytron セキュリティードメインと PickeBox セキュリティードメインの比較
デプロイメントを単一の Elytron セキュリティードメインか、1 つ以上のレガシー PicketBox セキュリティードメインと関連付ける必要があります。デプロイメントを Elytron と PicketBox の両方に関連付けしてはなりません。これは無効な設定です。
デプロイメントを複数の Elytron セキュリティードメインと関連付けると例外が発生しますが、レガシーセキュリティードメインの場合は複数関連付けることが可能です。
PicketBox の場合、セキュリティードメインは基礎のアイデンティティーストアへのアクセスと承認決定のマッピングの両方をカプセル化します。そのため、PicketBox に複数のストアがある場合は、ソースごとに異なるセキュリティードメインを使用する必要があります。
Elytron では、これら 2 つの機能が分離されています。ストアへのアクセスはセキュリティーレルムで処理され、承認のマッピングはセキュリティードメインによって処理されます。
そのため、独立した PicketBox セキュリティードメインが必要なデプロイメントは、独立した Elytron セキュリティードメインを必ずしも必要としません。
2.8.2. セキュリティーレルムとセキュリティードメインの使用
セキュリティーレルムとセキュリティードメインは、JBoss EAP にデプロイされた web アプリケーションのセキュア化に使用できます。セキュリティーレルムとセキュリティードメインの違いを理解してから、どちらを使用するかを決定することが重要になります。
web アプリケーションと EJB デプロイメントは、セキュリティードメインのみを直接使用できます。セキュリティードメインは、アイデンティティーストアから渡されたアイデンティティー情報を使用するログインモジュールを使用して実際の認証と承認を実行します。アイデンティティー情報にセキュリティーレルムを使用するよう、セキュリティードメインを設定できます。たとえば other
の場合、アプリケーションは認証と承認情報の取得に使用するセキュリティーレルムを指定できます。セキュリティードメインが外部のアイデンティティーストアを使用するよう設定することも可能です。eb アプリケーションと EJB デプロイメントが認証にセキュリティーレルムを直接使用するように設定することはできません。セキュリティードメインは security
サブシステムの一部でもあり、コアサービスの後にロードされます。
管理インターフェイスや EJB が リモーティングエンドポイントなどのコア管理のみがセキュリティーレルムを直接使用できます。セキュリティーレルムは、認証および承認情報を提供するアイデンティティーストアです。コアサービスの 1 つでもあり、サブシステムの起動前にロードされます。ManagementRealm
および ApplicationRealm
は初期状態のセキュリティーレルムで、簡単なファイルベースの認証を使用しますが、別の認証を使用するよう設定できます。
2.8.3. セキュリティー監査
セキュリティー監査とは、ログへの書き込みなど、security
サブシステム内で発生するイベントに対してトリガーするイベントのことです。監査方法は、認証、承認、およびセキュリティーマッピングの詳細とともにセキュリティードメインの一部として設定されます。セキュリティーイベントの報告方法を制御するため、監査にはプロバイダーモジュールが使用されます。JBoss EAP には複数のセキュリティー監査プロバイダーが含まれますが、カスタムのプロバイダーを使用することもできます。JBoss EAP のコア管理には、security
サブシステムの一部ではなく別に設定される独自のセキュリティー監査およびロギング機能があります。
2.8.4. セキュリティーマッピング
セキュリティーマッピングを使用すると、認証または承認後、情報がアプリケーションに渡される前に認証情報と承認情報を組み合わせることができます。マップできるのは、承認のロール、認証のプリンシパル、またはプリンシパルやロールでない属性のクレデンシャルです。ロールマッピングは、認証後にロールをサブジェクトに対して追加、置換、または削除するために使用されます。プリンシパルマッピングは、認証後にプリンシパルを変更するために使用されます。クレデンシャルマッピングを使用すると、外部システムの属性をアプリケーションが使用できるように変換することができます。また逆に、クレデンシャルマッピングを使用して、アプリケーションの属性を外部システムが使用できるように変換することもできます。
2.8.5. パスワード vault システム
JBoss EAP には、機密性の高い文字列を暗号化して暗号化されたキーストアに格納し、アプリケーションや検証システムに対して復号化するパスワード vault が含まれています。XML デプロイメント記述子などのプレーンテキストの設定ファイルでは、パスワードや他の機密情報を指定する必要があるときがあります。JBoss EAP のパスワード vault を使用すると、プレーンテキストファイルで使用する機密性の高い文字列をセキュアに格納することができます。
2.8.6. セキュリティードメインの設定
セキュリティードメインは、ドメインコントローラーまたはスタンドアロンサーバーで一元的に設定されます。セキュリティードメインが使用される場合、セキュリティーを別々に設定する代わりに、アプリケーションがセキュリティードメインを使用するよう設定することができます。これにより、ユーザーと管理者は 宣言的セキュリティー を利用することができます。
例
このような設定構造を有効に活用できる一般的な例が、アプリケーションをテスト環境と本番環境の間で移動する処理です。アプリケーションのセキュリティーが個別に設定されている場合、テスト環境から本番環境など、アプリケーションが新しい環境に移されるたびにアプリケーションを更新する必要がある可能性があります。代わりにアプリケーションがセキュリティードメインを使用すると、各環境の JBoss EAP インスタンスのセキュリティードメインは現在の環境に対して適切に設定されます。 アプリケーションはコンテナーに依存し、セキュリティードメインを使用して適切なセキュリティー設定を提供できます。
2.8.6.1. ログインモジュール
JBoss EAP には、セキュリティードメイン内で設定されるほとんどのユーザー管理ロールに適する、バンドルされたログインモジュールが複数含まれています。security
サブシステムは、リレーショナルデータベース、LDAP サーバー、またはフラットファイルからユーザー情報を読み取りできるコアログインモジュールを複数提供します。JBoss EAP はこれらのコアログインモジュールの他に、カスタマイズの必要性に対応する、ユーザー情報や機能を提供するログインモジュールも提供します。
一般的に使用されるログインモジュールの概要
- Ldap ログインモジュール
-
Ldap ログインモジュールは、LDAP サーバーに対して認証を行うログインモジュール実装です。
security
サブシステムはbindDN
を接続情報として使用し、LDAP サーバーに接続します。この bindDN は、JNDI 初期コンテキストを使用した場合にユーザーおよびロールのbaseCtxDN
およびrolesCtxDN
ツリーを検索する権限があります。ユーザーが認証を試みると、LDAP ログインモジュールは LDAP サーバーへ接続し、ユーザーのクレデンシャルを LDAP サーバーに渡します。認証に成功すると、JBoss EAP 内のそのユーザーにInitialLDAPContext
が作成され、ユーザーのロールが入力されます。 - LdapExtended ログインモジュール
- The LdapExtended ログインモジュールは、ユーザーと認証でバインドする関連ロールを検索します。ロールは再帰的にクエリーを行い、DN に従って階層的なロール構造を移動します。ログインモジュールオプションには、JNDI プロバイダーがサポートする指定の LDAP によってオプションがサポートされるかどうかが含まれます。
- UsersRoles ログインモジュール
- UsersRoles ログインモジュールは、Java プロパティーファイルからロードされる複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュールです。このログインモジュールの主な目的は、アプリケーションとともにデプロイされたプロパティーファイルを使用して複数のユーザーおよびロールのセキュリティー設定を簡単にテストすることです。
- Database ログインモジュール
- Database ログインモジュールは、認証とロールマッピングをサポートする JDBC (Java Database Connectivity) ベースのログインモジュールです。このログインモジュールは、ユーザー名、パスワード、およびロール情報がリレーショナルデータベースに格納される場合に使用されます。このログインモジュールは、想定される形式のプリンシパルおよびロールが含まれる論理テーブルへの参照を提供して動作します。
- Certificate ログインモジュール
-
Certificate ログインモジュールは、X509 証明書を基にユーザーを認証します。このログインモジュールの典型的なユースケースが、web 層の CLIENT-CERT 認証です。証明書ログインモジュールは認証のみを実行するため、セキュアな web または EJB コンポーネントへのアクセスを完全に定義するには、承認ロールを取得できる他のログインモジュールと組み合わせる必要があります。このログインモジュールの 2 つのサブクラスである
CertRolesLoginModule
およびDatabaseCertLoginModule
は動作を拡張し、プロパティーファイルまたはデータベースから承認ロールを取得します。 - Identity ログインモジュール
-
Identity ログインモジュールは、ハードコードされたユーザー名をモジュールに対して認証されたサブジェクトに関連付ける簡単なログインモジュールです。このモジュールは、プリンシパルのオプションによって指定された名前を使用して
SimplePrincipal
インスタンスを作成します。このログインモジュールは、固定のアイデンティティーをサービスに提供する必要がある場合に便利です。また、指定のプリンシパルに関連するセキュリティーや関連するロールをテストするために、開発環境でも使用できます。 - RunAs ログインモジュール
- RunAS ログインモジュールは、認証のログインフェーズの間に run-as ロールをスタックにプッシュするヘルパーモジュールです。ログインフェーズ後、コミットまたはアボートフェーズで run-as ロールをスタックからポップします。このログインモジュールの目的は、セキュアな EJB にアクセスするログインモジュールなど、セキュアなリソースにアクセスして認証を実行する必要のあるその他のログインモジュールにロールを提供することです。RunAs ログインモジュールは、run-as ロールの構築が必要なログインモジュールよりも先に設定する必要があります。
- Client ログインモジュール
-
Client ログインモジュールは、呼び出し元のアイデンティティーおよびクレデンシャルの確立時に JBoss クライアントによって使用されるログインモジュールの実装です。新しい
SecurityContext
を作成してプリンシパルとクレデンシャルに割り当て、SecurityContext
をThreadLocal
セキュリティーコンテキストに設定します。Client ログインモジュールは、クライアントが現在のスレッドの呼び出し元を確立するために唯一サポートされるログインモジュールです。セキュリティー環境が JBoss EAPsecurity
サブシステムを使用するよう透過的に設定されていない EJB クライアントとして動作するサーバー環境とスタンドアロンクライアントアプリケーションは、Client ログインモジュールを使用する必要があります。
このログインモジュールは認証を実行しません。サーバー上の後続の認証のために、提供されたログイン情報をサーバー EJB 呼び出しレイヤーにコピーすることもほとんどありません。JBoss EAP 内では、JVM 内の呼び出しに対してユーザーのアイデンティティーを切り替える場合のみサポートされます。リモートクライアントがアイデンティティーを確立する目的ではサポートされません。
- SPNEGO ログインモジュール
-
SPNEGO ログインモジュールは、KDC で呼び出し元のアイデンティティーとクレデンシャルを確立するログインモジュールの実装です。モジュールは JBoss Negotiation プロジェクトの一部で、SPNEGO を実装します。この認証を AdvancedLdap ログインモジュールとチェーンされた設定で使用すると、LDAP サーバーと連携できます。また、このログインモジュールを使用するには、web アプリケーションがアプリケーション内で
NegotiationAuthenticator
を有効にする必要があります。 - RoleMapping ログインモジュール
-
RoleMapping ログインモジュールは、1 つ以上の宣言的ロールへの認証プロセスの最終結果となるロールのマッピングをサポートします。たとえば、ユーザー John のロールが
ldapAdmin
とtestAdmin
で、web.xml
またはejb-jar.xml
ファイルで定義されたアクセスの宣言的ロールはadmin
であると認証プロセスによって判断された場合、このログインモジュールはldapAdmin
およびtestAdmin
ロールを John にマップします。RoleMapping ログインモジュールは、以前マップされたロールのマッピングを変更するため、ログインモジュール設定でオプションのモジュールとして定義する必要があります。 - Remoting ログインモジュール
- Remoting ログインモジュールは現在認証中のリクエストがリモーティング接続上で受信されたかどうかをチェックします。リクエストがリモーティングインターフェイスを使用して受信された場合、リクエストは認証プロセス中に作成されたアイデンティティーに関連付けられます。
- RealmDirect ログインモジュール
-
RealmDirect ログインモジュールは、認証および承認の決定に既存のセキュリティーレルムを使用できるようにします。このモジュールを設定すると、認証の決定とユーザーロールのマッピングに、参照したレルムを使用してアイデンティティー情報を検索します。たとえば、JBoss EAP に同梱される事前設定された
other
セキュリティードメインには RealmDirect ログインモジュールがあります。このモジュールに参照されるレルムがない場合、デフォルトでApplicationRealm
セキュリティーレルムが使用されます。 - カスタムモジュール
- JBoss EAP セキュリティーフレームワークとバンドルされるログインモジュールがセキュリティー環境の要件に対応できない場合、カスタムログインモジュール実装を作成できます。AuthenticationManager は、Subject プリンシパルの特定の使用パターンを必要とします。AuthenticationManager と動作するログインモジュールを作成するには、JAAS Subject クラスの情報ストレージ機能と、これらの機能の想定される使用方法を完全に理解する必要があります。
UnauthenticatedIdentity ログインモジュールオプションも一般的に使用されます。一部のケースでは、認証された形式でリクエストが受信されないことがあります。UnauthenticatedIdentity は、guest
などの特定のアイデンティティーを、関連する認証情報がない状態で作成されたリクエストに割り当てます。これを使用すると、保護されていないサーブレットは特定ロールを必要としない EJB でメソッドを呼び出すことができます。このようなプリンシパルには関連したロールがなく、セキュアでない EJB や、チェックされていないパーミッション制約と関連する EJB メソッドのみにアクセスできます。
2.8.6.2. パスワードスタッキング
スタックでは複数のログインモジュールをチェーンでき、各ログインモジュールは認証中にクレデンシャルの検証とロールの割り当てを提供します。これは多くのユースケースで機能しますが、クレデンシャルの検証とロールの割り当てが複数のユーザー管理ストアに分散されることがあります。
ユーザーは中央の LDAP サーバーで管理され、アプリケーション固有のロールはアプリケーションのリレーショナルデータベースに格納される場合を考えてみましょう。password-stacking
モジュールオプションはこの関係をキャプチャーします。
パスワードスタッキングを使用するには、各ログインモジュールは、<module-option>
セクションにある password-stacking
属性を useFirstPass
に設定する必要があります。パスワードスタッキングに設定した以前のモジュールがユーザーを認証した場合、他のすべてのスタッキングモジュールがユーザーによって認証されたこととなり、承認の手順でロールの提供のみを行います。
password-stacking
オプションを useFirstPass
に設定すると、このモジュールは最初にプロパティー名 javax.security.auth.login.name
で共有されたユーザー名を検索し、javax.security.auth.login.password
で共有されたパスワードを検索します。
これらのプロパティーが見つかった場合、プリンシパル名とパスワードとして使用されます。見つからなかった場合、プリンシパル名とパスワードはこのログインモジュールによって設定され、プリンシパル名は javax.security.auth.login.password
、パスワードは javax.security.auth.login.password
以下に格納されます。
2.8.6.3. パスワードのハッシュ化
ログインモジュールのほとんどは、クライアントが提供するパスワードをユーザー管理システムに保存されたパスワードと比較する必要があります。通常、これらのモジュールはプレーンテキストのパスワードを使用しますが、プレーンテキストのパスワードがサーバー側に保存されないようにするため、ハッシュ化されたパスワードをサポートするよう設定できます。JBoss EAP は、ハッシュ化するアルゴリズム、エンコーディング、および文字セットを設定する機能をサポートします。さらに、ユーザーパスワードとストアパスワードがハッシュ化されるタイミングも定義します。
Red Hat JBoss Enterprise Application Platform Common Criteria で認定された設定は、SHA-256 よりも弱いハッシュアルゴリズムはサポートしません。
2.8.7. セキュリティー管理
security
サブシステムのセキュリティー管理部分は、security
サブシステムのハイレベルな動作を上書きするために使用されます。各設定は任意になります。ディープコピーサブジェクトモード以外の設定を変更することはあまりありません。
2.8.7.1. ディープコピーモード
ディープコピーサブジェクトモードが無効であるときに (デフォルト設定)、セキュリティーデータ構造をコピーすると、データ構造全体がコピーされずに元のデータ構造への参照が作成されます。この挙動は効率的ですが、同じアイデンティティーを持つ複数のスレッドによってフラッシュまたはログアウトの操作が行われ、サブジェクトが消去されると、データが破損しやすくなります。
ディープコピーサブジェクトモードが有効になっていると、データ構造の完全コピーと、クローン可能な関連するデータがすべて作成されます。これはよりスレッドセーフになりますが、効率が悪くなります。
2.8.8. その他のコンポーネント
2.8.8.1. JASPI
Jakarta Authentication は Java アプリケーションのプラグ可能なインターフェイスで、Jakarta Authentication specification で定義されています。JBoss EAP では JAAS 認証だけでなく、Jakarta Authentication 認証も使用できます。Jakarta Authentication はセキュリティードメインのログインモジュールを使用して設定され、これらのモジュールはスタック可能です。jaspitest
セキュリティードメインは、開発用にデフォルトで含まれる簡単な JASPI セキュリティードメインです。
Web ベースの管理コンソールでは、JASPI モジュールを設定する以下の操作を利用できます。
- 追加
- 編集
- 削除
- リセット
JBoss EAP にデプロイされたアプリケーションが JASPI セキュリティードメインを使用するには、デプロイメント記述子に特別なオーセンティケーターを設定する必要があります。
2.8.8.2. Jakarta Authorization
Java Authorization はコンテナーと承認サービスプロバイダー間のコントラクトを定義する規格で、これによりコンテナーによって使用されるプロバイダーが実装されます。仕様の詳細は、Jakarta Authorization 1.1 Specification を参照してください。
JBoss EAP は、security
サブシステムのセキュリティー機能内に Jakarta Authorization のサポートを実装します。
2.8.8.3. Jakarta Security
Jakarta Security は、認証およびアイデンティティーストアの移植可能なプラグインインターフェイスと、プログラムによるセキュリティーのアクセスポイントを提供する新しい injectable-type SecurityContext
インターフェイスを定義します。これらの API のビルトイン実装を使用するか、カスタム実装を定義することができます。仕様の詳細は、Jakarta Security Specification を参照してください。
Jakarta Security API は elytron
サブシステムで利用でき、管理 CLI から有効にできます。詳細は、開発ガイドの Jakarta Security API を参照してください。
2.8.8.4. 粒度の細かい承認および XACML
粒度の細かい承認 (Fine Grained Authorization) は、モジュールへのアクセス権限を付与する意思決定プロセスに関係する要件や変数の変化に管理者が対応できるようにします。そのため、粒度の細かい承認は複雑になります。
JBoss EAP では、web および EJB の XACML バインディングはサポートされません。
JBoss EAP は XACML を媒体として使用し、粒度の細かい承認を実現します。XACML は標準ベースのソリューションを提供し、複雑な粒度の細かい承認に対応します。XACML は、意思決定のポリシー言語やアークテクチャーを定義します。XACML アーキテクチャーには、通常のプログラムフローでリクエストを阻止する PEP (Policy Enforcement Point: ポリシー強制ポイント) が含まれ、PDP (Policy Decision Point: ポリシー決定ポイント) に関連するポリシーを基にアクセスを決定するよう PDP に要求します。PDP は PEP によって作成された XACML リクエストを評価し、ポリシーを確認して以下の 1 つを決定します。
- PERMIT
- アクセスは許可されます。
- DENY
- アクセスは拒否されます。
- INDETERMINATE
- PDP にエラーがあります。
- NOTAPPLICABLE
- リクエストに足りない属性があるか、一致するポリシーがありません。
XACML には以下の機能もあります。
- Oasis XACML v2.0 ライブラリー
- JAXB v2.0 ベースのオブジェクトモデル
- XACML ポリシーおよび属性を保存および読み出しするための ExistDB 統合
2.8.8.5. SSO
JBoss は undertow
および infinispan
サブシステムを使用して、クラスター化された SSO とクラスター化されていない SSO に対して初期状態のサポートを提供します。これには以下の要件があります。
- 認証と承認を処理する設定済みのセキュリティードメイン。
-
SSO
infinispan レプリケーションキャッシュ。これは、管理対象ドメインではha
およびfull-ha
プロファイルにあります。 スタンドアロンサーバーの場合はstandalone-ha.xml
またはstandalone-full-ha.xml
設定ファイルを使用します。 -
web
キャッシュコンテナーと、その内部のSSO
レプリケーションキャッシュが存在する必要があります。 -
undertow
サブシステムが SSO を使用するように設定する必要があります。 - SSO 情報を共有する各アプリケーションが同じセキュリティードメインを使用するように設定する必要があります。