性能 (capability) とは、JBoss EAP で使用される機能の一部で、管理レイヤーを使用して公開されます。性能は他の性能に依存することもでき、この依存関係は管理レイヤーによって仲介されます。一部の性能は JBoss EAP によって自動的に提供されますが、起動時に利用可能な性能の完全セットは、JBoss EAP の設定を使用して判断されます。管理レイヤーは、サーバーの起動中と設定の変更時に、性能に必要な別の性能がすべて存在することを検証します。性能は JBoss Modules および拡張と統合しますが、これらの概念はすべて異なります。

性能は、依存する他の性能を登録する他に、依存する性能に関連する要件を登録する必要もあります。性能は以下のような要件を指定できます。

性能と要件の詳細は、WildFly ドキュメント を参照してください。

Elytron はセキュリティー API および SPI を提供します。他のサブシステムやコンシューマーはそれらの API や SPI を直接使用できるため、統合のオーバーヘッドが削減されます。ほとんどのユーザーは JBoss EAP で提供される機能を使用しますが、Elytron API および SPI は Elytron の機能を置き換えまたは拡張するためにカスタム実装によっても使用されます。

セキュリティードメインは、1 つ以上のセキュリティーレルムや変換を実行するリソースのセットが関係するセキュリティーポリシーを表します。セキュリティードメインは SecurityIdentity を作成します。SecurityIdentity は、アプリケーションなど、承認を実行する他のリソースによって使用されます。SecurityIdentity は、未処理の AuthorizationIdentity とその関連するロールやパーミッションを基にした現在のユーザーを表します。

セキュリティードメインを設定して、別のセキュリティードメインから SecurityIdentity の インフローを許可することもできます。アイデンティティーが インフロー すると、元の処理されていない AuthorizationIdentity を保持し、新しいロールとパーミッションのセットが割り当てられ、新しい SecurityIdentity が作成されます。

セキュリティーレルムはアイデンティティーストアへのアクセスを提供し、クレデンシャルの取得に使用されます。これらのクレデンシャルにより、認証メカニズムは認証を実行するために未処理の AuthorizationIdentity を取得できます。また、これらのクレデンシャルは、証拠の検証時に認証メカニズムが検証を行えるようにします。

1 つ以上のセキュリティーレルムを 1 つのセキュリティードメインに関連付けることができます。また、一部のセキュリティー実装は変更のために API も公開するため、セキュリティーレルムは基盤のアイデンティティーストアへの更新を作成できます。

ロールデコーダーはセキュリティードメインに関連付けられ、現ユーザーのロールをデコードするために使用されます。ロールデコーダーは、セキュリティーレルムから返される未処理の AuthorizationIdentity を取り、その属性をロールに変換します。

ロールマッパーはロールの変更をアイデンティティーに適用します。これは、ロールの形式の正規化から特定ロールの追加や削除までさまざまです。ロールマッパーはセキュリティーレルムとセキュリティードメインの両方に関連付けることができます。ロールマッパーがセキュリティーレルムに関連付けられた場合、セキュリティードメインレベルでロールのデコードや追加のロールマッピングなどの変換が発生する前に、マッピングがセキュリティーレルムレベルで適用されます。ロールマッパーと他の変換 (ロールデコーダーなど) が両方セキュリティードメインで設定された場合、ロールマッパーが適用される前に他の変換がすべて実行されます。

パーミッションマッパーはセキュリティードメインと関連付けられ、パーミッションを SecurityIdentity に割り当てます。

プリンシパルトランスフォーマーは、 elytron サブシステム内の複数の場所で使用できます。プリンシパルトランスフォーマーは名前を別の名前に変換またはマップできます。

プリンシパルデコーダーは、 elytron サブシステム内の複数の場所で使用できます。プリンシパルデコーダーはアイデンティティーを Principal から名前の文字列表現に変換します。たとえば、X500PrincipalDecoder を使用すると X500Principal を証明書の識別名から文字列表現に変換できます。

レルムマッパーはセキュリティードメインと関連付けられ、セキュリティードメインに複数のセキュリティーレルムが設定されている場合に使用されます。レルムマッパーは、http-authentication-factory および sasl-authentication-factory の mechanism または mechanism-realm に関連付けられることもあります。レルムマッパーは、認証中に提供された名前を使用して認証のセキュリティーレルムを選択し、未処理の AuthorizationIdentity を取得します。

認証ファクトリーは、認証ポリシーを表します。認証はセキュリティードメイン、メカニズムファクトリー、およびメカニズムセレクターと関連付けられます。セキュリティードメインは、認証される SecurityIdentity を提供します。メカニズムファクトリーはサーバー側の認証メカニズムを提供します。メカニズムセレクターは、選択したメカニズムに固有する設定を取得します。メカニズムセレクターには、メカニズムがリモートクライアントに提示する必要のあるレルム名に関する情報や、認証プロセス中に使用する追加のプリンシパルトランスフォーマーとレルムマッパーに関する情報を含めることができます。

key-store は、キーストアの種類、その場所、アクセスするためのクレデンシャルなどを含むキーストアまたはトラストストアの定義です。

key-manager は key-store を参照し、SSL コンテキストとともに使用されます。

trust-manager は、key-store に定義されるトラストストアを参照します。通常は、双方向 SSL/TLS の SSL コンテキストとともに使用されます。

elytron サブシステム内で定義される SSL コンテキストは javax.net.ssl.SSLContext で、SSL コンテキストを直接使うものが使用できます。 SSL コンテキストの通常の設定の他に、暗号化スイートやプロトコルなどの追加項目を設定することが可能です。SSL コンテキストは、設定された追加項目をラップします。

プレーンテキストの文字列の暗号化に使用されたこれまでの vault 実装は、新設計のクレデンシャルストアに置き換えられました。クレデンシャルストアは、保存するクレデンシャルの保護の他に、プレーンテキストの文字列を保存するために使用されます。

ネイティブインターフェース (管理 CLI) は、稼働中の JBoss EAP インスタンスと同じホストにてローカルで呼び出すことができ、別のマシンからリモートで呼び出すこともできます。ネイティブインターフェースを使用して接続を確立しようとすると、JBoss EAP は local jboss user やベーシック認証などの利用可能な SASL 認証のリストをクライアントに提示します。クライアントは希望する認証方法を選択し、JBoss EAP インスタンスとの認証を試行します。認証に失敗すると、他の方法で認証を再試行するか、接続の確立を停止します。ローカルクライアントは local jboss user 認証を使用することもできます。これは、ローカルファイルシステムにアクセスできるクライアントの機能を基にしたセキュリティーメカニズムです。これは、ログインしようとしているユーザーが JBoss EAP インスタンスと同じホスト上のローカルファイルシステムにアクセスできる権限があるかを検証します。

この認証は 4 つのステップで行われます。

このような認証は、ファイルシステムへ物理的にアクセスできれば他のセキュリティーメカニズムは不要であるという原理に基づいています。これは、ユーザーがローカルのファイルシステムにアクセスできれば、ユーザーは新規ユーザーを作成できる権限があり、そうでなければ他のセキュリティーメカニズムが阻止されるという論理です。ローカルユーザーはユーザー名やパスワードの認証なしで管理 CLI にアクセスできるため、サイレント認証と呼ばれることもあります。

この機能は利便性のためと、管理 CLI スクリプトを実行しているローカルユーザーの追加認証を不要にするために有効になっています。通常、ユーザーがローカル設定にアクセスできれば、独自のユーザー詳細を追加することもできるため便利な機能と見なされます。

リモートクライアントとして、別のサーバーや同じサーバーからネイティブインターフェースにアクセスすることもできます。リモートクライアントとしてネイティブインターフェースにアクセスする場合、local jboss user を使用してクライアントを認証することはできず、ダイジェストなどの別の認証を使用するよう強制されます。local jboss user を使用したローカルクライアントの認証に失敗すると、自動的にフォールバックされ、リモートクライアントとして別の認証方法の使用を試みます。

HTTP インターフェースは、稼働中の JBoss EAP インスタンスと同じホスト上のクライアントがローカルで呼び出すことができ、他のマシンからクライアントがリモードで呼び出すこともできます。ローカルおよびリモートクライアントは HTTP インターフェースにアクセスできますが、HTTP インターフェースにアクセスするすべてのクライアントはリモート接続として処理されます。

クライアントが HTTP 管理インターフェースへの接続を試みると、JBoss EAP は HTTP 応答とともに状態コード 401 Unauthorized と、ダイジェストや GSSAPI などのサポートされる認証をリストする一連のヘッダーを返信します。ダイジェストのヘッダーには、JBoss EAP によって生成された nonce も含まれます。クライアントはヘッダーを確認して使用する認証方法を選択し、適切な返答を送信します。クライアントがダイジェストを選択した場合、ユーザーにユーザー名とパスワードの入力を要求します。クライアントは、ユーザー名やパスワードなどの提供されたフィールド、nonce、その他の情報を使用し、一方向ハッシュを生成します。その後、一方向ハッシュ、ユーザー名、および nonce を返答として JBoss EAP に返信します。JBoss EAP はその情報を取得して別の一方向ハッシュを生成し、両方のハッシュを比較した結果を基にしてユーザーを認証します。

JBoss EAP では、管理者は認証および承認方法を変更できるだけでなく、管理インターフェース自体の設定も更新できます。これには複数のオプションがあります。

セキュリティーレルムには、LDAP サーバーなどの外部インターフェースに接続するものあります。アウトバウンド接続は、このような接続の確立方法を定義します。事前定義された接続タイプ ldap-connection は、LDAP サーバーへ接続し、クレデンシャルを検証するために必要な属性と任意の属性をすべて設定します。

デフォルトでは、RBAC システムは無効になっています。有効にするには、provider 属性を simple から rbac に変更します。これは、管理 CLI を使用して変更できます。稼働中のサーバーで RBAC を無効化または有効化した場合、サーバー設定をリロードして変更を反映する必要があります。

管理インターフェースに対して RBAC が有効化された場合、アクセスできるリソースとリソースの属性で実行できる操作は、ユーザーに割り当てられたロールによって決定されます。Administrator または SuperUser ロールのユーザーのみがアクセス制御システムを閲覧および変更できます。

ユーザーがリソース属性の読み取り権限を持たない場合、その属性はコンソールでは空欄で表示されます。たとえば、ほとんどのロールはデータソースのユーザー名およびパスワードフィールドを読み取りできません。

ユーザーがリソース属性の読み取り権限を持ち、書き込み権限は持たない場合、その属性はリソースの編集フォームで無効化されます。ユーザーがリソースへの書き込み権限を持たない場合、そのリソースの編集ボタンは表示されません。

ユーザーがリソースまたは属性へのアクセス権を持たず、そのロールに対してアドレス指定できない場合、そのユーザーのコンソールには表示されません。この例の 1 つがアクセス制御システム自体で、デフォルトでは特定のロールのみが閲覧できます。

管理コンソールは、以下の一般的な RBAC タスクに対してもインターフェースを提供します。

読み取りできないリソースや属性は、結果からフィルター処理されます。ロールがフィルターされたリソースや属性をアドレス指定できる場合、結果の response-headers セクションにある filtered-attributes としてリストされます。ロールがリソースや属性をアドレス指定できない場合はリストされません。

アドレス指定できないリソースにアクセスしようとすると、Resource Not Found エラーが発生します。

適切な書き込みまたは読み取り権限のないユーザーが、アドレス指定可能なリソースを読み取りまたは書き込みしようとすると、Permission Denied エラーが返されます。

管理 CLI は、管理コンソールと同じ RBAC タスクをすべて実行でき、さらに以下のような追加のタスクも実行できます。

使用されるプロバイダーに関係なく、JBoss EAP はユーザーへロールを割り当てます。ManagementRealm または LDAP サーバーで認証を行う場合、これらのシステムはユーザーグループ情報を提供できます。JBoss EAP はこの情報を使用してユーザーにロールを割り当てることもできます。

JBoss EAP には、LDAP サーバーを web および EJB アプリケーションの認証および承認機関として使用できるようにする複数の認証および承認モジュールが含まれています。

LDAP サーバーを管理コンソール、管理 CLI、または管理 API の認証ソースとして使用するには、以下のタスクを実行する必要があります。

LDAP オーセンティケーターは、最初にリモートディレクトリーサーバーへ接続を確立します。その後、ユーザーが認証システムに渡すユーザー名を使用して検索を実行し、LDAP レコードの完全修飾識別名 (DN) を探します。ユーザーによって提供されるクレデンシャルおよびパスワードとしてユーザーの DN を使用して、LDAP サーバーへの新しい接続が確立されます。LDAP サーバーの認証に成功すると、DN が有効であることが検証されます。

LDAP が有効なセキュリティーレルムが作成されると、管理インターフェースによる参照が可能になります。管理インターフェースはセキュリティーレルムを認証に使用します。管理インターフェースおよび管理 CLI で認証に双方向 SSL/TLS を使用すると、LDAP サーバーへのアウトバウンド接続を使用するよう JBoss EAP を設定することもできます。

JAAS を使用して管理インターフェースをセキュア化できます。管理インターフェースに JAAS を使用する場合、セキュリティーレルムがセキュリティードメインを使用するように設定する必要があります。これにより、コアサービスとサブシステムの依存関係が発生します。SSL/TLS は、管理インターフェースのセキュア化に JAAS を使用する必要はありませんが、管理者は SSL/TLS を有効にして、セキュアでない状態で機密情報を誤送信しないようにすることが推奨されます。

JBoss EAP には、セキュリティードメイン内で設定されるほとんどのユーザー管理ロールに適する、バンドルされたログインモジュールが複数含まれています。security サブシステムは、リレーショナルデータベース、LDAP サーバー、またはフラットファイルからユーザー情報を読み取りできるコアログインモジュールを複数提供します。JBoss EAP はこれらのコアログインモジュールの他に、カスタマイズの必要性に対応する、ユーザー情報や機能を提供するログインモジュールも提供します。

UnauthenticatedIdentity ログインモジュールオプションも一般的に使用されます。一部のケースでは、認証された形式でリクエストが受信されないことがあります。UnauthenticatedIdentity は、guest などの特定のアイデンティティーを、関連する認証情報がない状態で作成されたリクエストに割り当てます。これを使用すると、保護されていないサーブレットは特定ロールを必要としない EJB でメソッドを呼び出すことができます。このようなプリンシパルには関連したロールがなく、セキュアでない EJB や、チェックされていないパーミッション制約と関連する EJB メソッドのみにアクセスできます。

スタックでは複数のログインモジュールをチェーンでき、各ログインモジュールは認証中にクレデンシャルの検証とロールの割り当てを提供します。これは多くのユースケースで機能しますが、クレデンシャルの検証とロールの割り当てが複数のユーザー管理ストアに分散されることがあります。

ユーザーは中央の 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 以下に格納されます。

ログインモジュールのほとんどは、クライアントが提供するパスワードをユーザー管理システムに保存されたパスワードと比較する必要があります。通常、これらのモジュールはプレーンテキストのパスワードを使用しますが、プレーンテキストのパスワードがサーバー側に保存されないようにするため、ハッシュ化されたパスワードをサポートするよう設定できます。JBoss EAP は、ハッシュ化するアルゴリズム、エンコーディング、および文字セットを設定する機能をサポートします。さらに、ユーザーパスワードとストアパスワードがハッシュ化されるタイミングも定義します。

ディープコピーサブジェクトモードが無効であるときに (デフォルト設定)、セキュリティーデータ構造をコピーすると、データ構造全体がコピーされずに元のデータ構造への参照が作成されます。この挙動は効率的ですが、同じアイデンティティーを持つ複数のスレッドによってフラッシュまたはログアウトの操作が行われ、サブジェクトが消去されると、データが破損しやすくなります。

ディープコピーサブジェクトモードが有効になっていると、データ構造の完全コピーと、クローン可能な関連するデータがすべて作成されます。これはよりスレッドセーフになりますが、効率が悪くなります。

Java Authentication SPI for Containers (JASPI または JASPIC) は Java アプリケーションのプラグ可能なインターフェースで、 JSR-196 に定義されています。JBoss EAP では JAAS 認証だけでなく、JASPI 認証も使用できます。JASPI 認証はセキュリティードメインのログインモジュールを使用して設定され、これらのモジュールはスタック可能です。jaspitest セキュリティードメインは、開発用にデフォルトで含まれる簡単な JASPI セキュリティードメインです。web ベースの管理コンソールは JASPI 認証モジュールの設定を公開しません。JBoss EAP にデプロイされたアプリケーションが JASPI セキュリティードメインを使用するには、デプロイメント記述子に特別なオーセンティケーターを設定する必要があります。

JACC (Java Authorization Contract for Containers) はコンテナーと承認サービスプロバイダー間のコントラクトを定義する規格で、これによりコンテナーによって使用されるプロバイダーが実装されます。これは JSR-115 に定義され、バージョン 1.3 以上ではコア Java EE 仕様の一部となっています。

JBoss EAP は、security サブシステムのセキュリティー機能内に JACC のサポートを実装します。

粒度の細かい承認 (Fine Grained Authorization) は、モジュールへのアクセス権限を付与する意思決定プロセスに関係する要件や変数の変化に管理者が対応できるようにします。そのため、粒度の細かい承認は複雑になります。

JBoss EAP は XACML を媒体として使用し、粒度の細かい承認を実現します。XACML は標準ベースのソリューションを提供し、複雑な粒度の細かい承認に対応します。XACML は、意思決定のポリシー言語やアークテクチャーを定義します。XACML アーキテクチャーには、通常のプログラムフローでリクエストを阻止する PEP (Policy Enforcement Point: ポリシー強制ポイント) が含まれ、PDP (Policy Decision Point: ポリシー決定ポイント) に関連するポリシーを基にアクセスを決定するよう PDP に要求します。PDP は PEP によって作成された XACML リクエストを評価し、ポリシーを確認して以下の 1 つを決定します。

XACML には以下の機能もあります。

JBoss は undertow および infinispan サブシステムを使用して、クラスター化された SSO とクラスター化されていない SSO に対して初期状態のサポートを提供します。これには以下の要件があります。