2.7. コア管理認証

ネイティブインターフェイス (管理 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 および Jakarta Enterprise Beans アプリケーションの認証および承認機関として使用できるようにする複数の認証および承認モジュールが含まれています。

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

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

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

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