セキュリティーアーキテクチャー

Kerberos はチケットと呼ばれるセキュリティートークンを使用します。セキュアサービスを利用するためには、ユーザーはネットワーク上のサーバーで動作するサービスである Ticket Granting Service (TGS) からチケットを入手する必要があります。チケットの取得後、同じネットワークで実行される別のサービスである認証サービス (AS) からサービスチケット (ST) を要求します。その後、ユーザーは ST を使用して希望のサービスに対して認証されます。TGS と AS は、ともに KDC (Key Distribution Center) と呼ばれる囲い込みサービスの内部で動作します。

Kerberos は、クライアントサーバーデスクトップ環境での使用を目的としているため、通常は web アプリケーションやシンクライアント環境では使用されません。しかし、デスクトップの認証に Kerberos システムをすでに使用しているため、web アプリケーション用のシステムを作成せずに、既存のシステムを再使用したい組織が多くあります。Kerberos は Microsoft Active Directory には欠かせない要素で、Red Hat Enterprise Linux 環境の多くでも使用されています。

web ブラウザーなどのクライアントコンピューター上のアプリケーションが web サーバーの保護されたページにアクセスしようとすると、サーバーは承認が必要であることを伝えます。その後、アプリケーションは Kerberos Key Distribution Center (KDC) にサービスチケットを要求します。チケットの取得後、アプリケーションはこのチケットをSPNEGO 向けにフォーマットされたリクエストにラップし、ブラウザーを介して web アプリケーションに返信します。デプロイされた web アプリケーションを実行している web コンテナーはリクエストをアンパックし、チケットを認証します。認証に成功するとアクセスが許可されます。

SPNEGO は、Red Hat Enterprise Linux に含まれる Kerberos サービスや Microsoft Active Directory には不可欠な Kerberos サーバーなど、全タイプの Kerberos プロバイダーと動作します。

Active Directory は、共に動作する 3 つのコアテクノロジーに依存します。

SSO を実装する方法は、要求ベースのアイデンティティー システムを使用することです。クレームベースのアイデンティティーシステムでは、システムはアイデンティティー情報を渡すことができますが、その情報をクレームと発行者 (またはオーソリティー) の 2 つに抽象化します。クレームは、ユーザー、グループ、アプリケーション、組織などの 1 つのサブジェクトが他のサブジェクトに関して作成するステートメントです。1 つまたは複数のクレームは、1 つまたは複数のトークンにパッケージ化され、プロバイダーによって発行されます。クレームベースのアイデンティティーでは、個別のセキュアなリソースがユーザーに関する情報をすべて認識しなくても SSO を実装できます。

JBoss EAP 6 は、モジュールクラスローディングの概念に基づいて構築されています。JBoss EAP によって提供される各 API およびサービスはモジュールとして実装され、必要に応じてロードおよびアンロードされます。コアサービスは、サーバーの起動時に常にロードされるサービスで、追加のサブシステムを起動する前に実行する必要があります。

サブシステムは、拡張によってコアサーバーに追加される機能の追加セットです。サブシステムの例としては、サーブレット処理機能を提供するサブシステム、EJB コンテナーを提供するサブシステム、JTA を提供するサブシステムなどがあります。

プロファイルはサブシステムの名前付きリストで、各サブシステムの設定の詳細と提供されます。プロファイルのサブシステムの数が多いと、サーバーの機能が多くなります。プロファイルのサブシステムが集中的で数が少ないと、機能が少なくなりますが、フットプリントも少なくなります。デフォルトで、JBoss EAP 6 には、いくつかの事前定義されたプロファイル (default、full、ha、full-ha など) が付属しています。これらのプロファイルでは、管理インターフェースと関連するセキュリティーレルムはコアサービスとしてロードされます。

JBoss EAP 6 は、その設定を操作および編集するための 2 つの異なる管理インターフェイス (API) を提供します。管理コンソール (HTTP API) と管理 CLI (ネイティブ API) です。これらのインターフェイスはいずれも、JBoss EAP のコア管理の機能を公開するものです。つまり、これらのインターフェイスは、同じ基幹管理システムにアクセスするための 2 つの方法を提供しているのです。

管理コンソールは、JBoss EAP 6 の Web ベースの管理ツールです。サーバーの開始および停止、アプリケーションのデプロイおよびアンデプロイ、システム設定の調整、サーバー設定への永続的な変更を行うために使用できます。管理コンソールは、管理タスクを実行する機能も持ち、変更の反映にサーバーインスタンスの再起動またはリロードが必要な場合はライブ通知も行います。管理対象ドメインでは、同じドメイン内のサーバーインスタンスやサーバーグループをドメインコントローラーの管理コンソールから集中管理できます。

管理コマンドラインインターフェース (CLI) は、JBoss EAP 6 のコマンドライン管理ツールです。管理 CLI は、サーバーの開始および停止、アプリケーションのデプロイおよびアンデプロイ、システム設定の指定、およびその他の管理タスクの実行に使用できます。操作はバッチモードで実行可能で、複数のタスクをグループとして実行できます。管理CLIは、マネージドドメインのドメインコントローラーへの接続が可能で、ドメイン上で管理操作を実行できます。管理 CLI は、web ベースの管理ツールが実行できるタスクをすべて実行でき、web ベースの管理ツールでは利用できない多くの細かな低レベル操作も実行できます。

セキュリティーレルムは、ユーザー、パスワード、およびグループメンバーシップ情報のアイデンティティーストアで、EJB、Web アプリケーション、および管理インターフェースのユーザーを認証するときに使用されます。デフォルトでは、JBoss EAP ６ には事前設定された ManagementRealm および ApplicationRealm の 2 つのセキュリティーレルムが含まれています。これらのセキュリティー領域はいずれも、ユーザーとパスワード、ユーザーとグループメンバーの情報のマッピングを保存するためにファイルシステムを使用し、認証の際にはデフォルトでダイジェスト機構を使用する。

ダイジェスト機構とは、簡単に言えば、users/password マッピングプロパティーファイルに格納された情報を含む様々な情報から設定されるワンタイム、ワンウェイハッシュを利用してユーザーを認証する機構である。これにより、JBoss EAP はネットワーク上でプレーンテキストのパスワードを送信せずに認証を行うことができます。

スクリプトは JBoss EAP 6 インストールに含まれています。これにより、管理者は両方のレルムにユーザーを追加できます。このようにユーザーを追加すると、ユーザー名とハッシュ化されたパスワードは対応するユーザー/パスワードプロパティーファイルに保存されます。ユーザーが認証を試みると、JBoss EAP は nonce という 1 度限りの番号をクライアントに送信します。次にクライアントは、ユーザー名、パスワード、nonce、その他いくつかのフィールドを使用して一方向ハッシュを生成し、JBoss EAP にユーザー名、nonce、一方向ハッシュを返送します。次に JBoss EAP は、ユーザーの事前ハッシュ化されたパスワードを検索し、提供されたユーザー名と nonce および他のいくつかのフィールドとともにそれを使用して、同じ方法で別の一方向ハッシュを生成します。双方で同じ情報 (正しいパスワードなど) が使用されていれば、ハッシュは一致し、ユーザーは認証されます。

セキュリティーレルムはデフォルトでダイジェスト認証を使用しますが、他の認証方法を使用するように再設定することもできます。管理インターフェースは起動時に、ManagementRealm に設定された認証方法を基にして、有効化される認証方法を判断します。

セキュリティーレルムは承認には全く関与しません。しかし、後で承認の決定に使用されるユーザーのグループメンバーシップ情報をロードするよう設定することが可能です。ユーザーの認証後、ユーザー名を基にグループメンバーシップ情報をロードする 2 つ目の手順が発生します。

デフォルトでは、ManagementRealm は管理インターフェースの認証および承認中に使用されます。ApplicationRealm は、web アプリケーションと EJB がユーザーの認証および承認時に使用できるデフォルトのレルムです。

セキュリティードメインは JAAS (Java Authentication and Authorization Service) の宣言的なセキュリティー設定で、認証、承認、監査、およびマッピングを制御するために 1 つ以上のアプリケーションによって使用されます。デフォルトでは、jboss-ejb-policy、jboss-web-policy、other 3 つのセキュリティードメインが含まれています。jboss-ejb-policy および jboss-web-policy は、アプリケーションの設定済みのセキュリティードメインがない場合に使用されるデフォルトの承認メカニズムです。これらのセキュリティードメインと other は承認のために JBoss EAP の内部でも使用されるため、適切な操作に必要です。

セキュリティードメインは、認証、承認、セキュリティーマッピング、および監査の設定で構成されます。セキュリティードメインは、JBoss EAP ６ セキュリティーサブシステムの一部で、ドメインコントローラーまたはスタンドアロンサーバーによって一元管理されます。ユーザーは、アプリケーションの要件に応じて必要な数のセキュリティードメインを作成できます。

JBoss EAP にデプロイされた web アプリケーションのセキュア化の一部として、セキュリティーレルムとセキュリティードメインの両方を使用できます。セキュリティーレルムとセキュリティードメインの違いを理解してから、どちらを使用するかを決定することが重要になります。

web アプリケーションと EJB デプロイメントは、セキュリティードメインのみを直接使用できます。セキュリティードメインは、アイデンティティーストアから渡されたアイデンティティー情報を使用するログインモジュールを使用して実際の認証と承認を実行します。セキュリティードメインは、ID 情報のためにセキュリティーレームを使用するように設定することができる (たとえば、other では、アプリケーションは認証と認可情報の取得に使用するセキュリティーレームを指定できる) が、外部の ID ストアを使用するように設定することもできます。認証にセキュリティーレルムを直接使用するよう Web アプリケーションと EJB デプロイメントを設定することはできません。セキュリティードメインは security サブシステムの一部でもあるため、コアサービスの後にロードされます。

Security Realms を直接使用できるのは、コアマネジメント (管理インターフェイスなど) と EJB リモーティングエンドポイントのみです。セキュリティーレルムは、認証および承認情報を提供するアイデンティティーストアです。コアサービスの 1 つでもあり、サブシステムの起動前にロードされます。ManagementRealm および ApplicationRealm は初期状態のセキュリティーレルムで、簡単なファイルベースの認証を使用しますが、別の認証を使用するよう設定できます。

セキュリティー監査とは、ログへの書き込みなど、security サブシステム内で発生するイベントに対してトリガーするイベントのことです。監査方法は、認証、承認、およびセキュリティーマッピングの詳細とともにセキュリティードメインの一部として設定されます。セキュリティーイベントの報告方法を制御するため、監査にはプロバイダーモジュールが使用されます。JBoss EAP には複数のセキュリティー監査プロバイダーが含まれますが、カスタムのプロバイダーを使用することもできます。また、JBoss EAP のコア管理には、security サブシステムの一部ではなく別に設定される独自のセキュリティー監査およびロギング機能があります。

セキュリティーマッピングを使用すると、認証または承認後、情報がアプリケーションに渡される前に認証情報と承認情報を組み合わせることができます。ロール (承認)、プリンシパル (認証)、またはクレデンシャル (プリンシパルでもロールでもない属性) はすべてマッピングされる可能性があります。ロールマッピングは、認証後にサブジェクトへロールを追加、置換、または削除するために使用されます。プリンシパルマッピングは、認証後にプリンシパルを変更するために使用されます。クレデンシャル (属性) マッピングは、外部システムからの属性値をアプリケーションで使用するために変換したり、逆にそのような外部システムへ属性を変換したりするために使用されます。

JMX (Java Management Extensions) は、JDK およびアプリケーション管理操作をリモートで行う方法を提供します。JBoss EAP 6 の管理 API は、JMX 管理 Bean として公開されます。管理 Bean は core mbeans と呼ばれ、これらの Bean へのアクセスは基礎の管理 API 自体と全く同じように制御およびフィルターされます。

ロールベースのアクセス制御 (RBAC) は管理ユーザーにパーミッションを指定するメカニズムです。JBoss EAP ６ サーバーの管理責任を複数のユーザーに分担でき、各ユーザーは無制限のアクセスを必要としません。JBoss EAP 6 は、管理ユーザーの 役割 を分離することで、組織が不必要な特権を与えることなく、個人やグループ間で責任を分散させることを容易にすることができます。これにより、設定、デプロイメント、および管理の柔軟性を維持しながらサーバーやデータのセキュリティーを可能な限り最大限にします。

JBoss EAP 6 のロールベースアクセス制御は、ロールパーミッションと制約の組み合わせにより動作します。それぞれに異なる固定パーミッションを持つ 7 つの事前定義されたロールが提供されます。各管理ユーザーには、サーバーの管理時に許可される動作を指定する 1 つ以上のロールが割り当てられます。

ロールベースアクセス制御は JBoss EAP 6.2 以降でサポートされますが、デフォルトでは無効になっています。

¹ パーミッションはアプリケーションリソースに制限されます。

² 機密データとして考慮されるリソースは、Sensitivity で設定されます。

制約は、以下の 3 つの分類に分類されます。

宣言型セキュリティーは、コンテナーを使用してセキュリティーを管理することでアプリケーションコードからセキュリティーの懸念を分離する方法です。コンテナーはファイルパーミッション、またはユーザー、グループ、およびロールを基に承認システムを提供します。通常この方法は、アプリケーション自体にセキュリティーの責任をすべて与えるプログラムによるセキュリティーよりも優れています。JBoss EAP 6 は、Security Subsystem の Security Domain を介して宣言的なセキュリティーを提供します。

Java Authentication and Authorization Service (JAAS) は、ユーザー認証と認可のために設計された一連の Java パッケージからなる宣言的なセキュリティー API です。この API は 標準の PAM (Pluggable Authentication Modules) フレームワークの Java 実装です。Java EE アクセス制御アーキテクチャーを拡張し、ユーザーベースの承認をサポートします。JBoss EAP ６ の security サブシステムは実際に JAAS API をベースにしています。

JAAS はセキュリティーサブシステムの基盤であるため、認証はプラグイン方式で行われます。これにより、Java アプリケーションは Kerberos や LDAP などの基礎の認証技術から独立でき、セキュリティーマネージャーは異なるセキュリティーインフラストラクチャーで機能できます。セキュリティーマネージャーの実装を変更しなくてもセキュリティーインフラストラクチャーとの統合を実現できます。JAAS が使用する認証スタックの設定のみを変更する必要があります。

デフォルトでは、コア管理認証は HTTP と ネイティブの各管理インターフェースを、ローカルクライアントとリモートクライアントの 2 つの形式でセキュア化します。これら両方は、デフォルトでは ManagementRealm セキュリティーレルムを使用して設定されます。デフォルトの設定は変更可能で、設定を完全に置き換えることもできます。管理インターフェイスをセキュアにする以外に、HTTP およびネイティブインターフェイスをそれぞれ無効にすることができます。

保護方法に影響を及ぼす、管理インターフェースや認証/承認方法のデフォルト設定を変更する方法は複数あります。

JBoss EAP 6 にはパスワード vault が含まれています。このパスワード vault は、機密性の高い文字列を暗号化して暗号化されたキーストアに保存し、アプリケーションや検証システムに対して復号化します。XML デプロイメント記述子などのプレーンテキストの設定ファイルでは、パスワードや他の機密情報を指定する必要があるときがあります。JBoss EAP のパスワード vault を使用すると、プレーンテキストファイルで使用する機密性の高い文字列をセキュアに格納することができます。

セキュリティードメインは、ドメインコントローラーまたはスタンドアロンサーバーで一元的に設定されます。セキュリティードメインが使用される場合、セキュリティーを個別に設定する代わりに、アプリケーションがセキュリティードメインを使用するように設定できます。これにより、ユーザーと管理者は 宣言的セキュリティー を利用することができます。

security サブシステムのセキュリティー管理部分は、security サブシステムのハイレベルな動作を上書きするために使用されます。各設定は任意になります。ディープコピーサブジェクトモード以外の設定を変更することはあまりありません。

ほとんどの SSO のシナリオでは、SP は有効なアサーションで SAML 応答を SP に送信する IDP に認証リクエストを送信して、フローを開始します。これはサービスプロバイダー (SP) の起動フローとして知られています。しかし、SAML 2.0 仕様は、アイデンティティープロバイダー (IDP) の起動済みまたは未承認の Response フローと呼ばれる別のフローも定義します。このフローの場合、サービスプロバイダーは認証フローを開始せずに IDP から SAML 応答を受信します。このフローは IDP 側で起動します。認証が終わると、ユーザーはリストから特定のサービスプロバイダーを選択し、サービスプロバイダーの URL にリダイレクトされます。このフローを有効にするのに特別な設定は必要ありません。

あるサービスプロバイダーで開始されるグローバルログアウトで、アイデンティティープロバイダー (IDP) およびすべてのサービスプロバイダーからユーザーをログアウトします。グローバルログアウトの実行後に、SP または IDP のセキュアな部分にアクセスするユーザーは再認証が強制になります。

JBoss EAP は管理コンソールを含む、管理インターフェースによる HTTPS の使用をサポートします。HTTPS を有効にするには、secure-interface 要素を設定し、secure-port を管理インターフェースの http-interface セクションに追加し、希望の設定 (サーバー ID、プロトコル、キーストア、エイリアスなど) で既存または新規セキュリティーレルムを設定します。これにより、管理インターフェースがすべての HTTP トラフィックに SSL/TLS を使用できるようになります。HTTPS と管理インターフェースのセキュア化に関する背景情報は、「高度なセキュリティー」 セクションを参照してください。

JBoss EAP では、複数の異なる認証スキームを使用して、管理インターフェースの RBAC を有効にすることもできます。この例では、ManagementRealm で使用される既存のプロパティーファイルでユーザー名とパスワードを使用します。RBAC を有効にするには、管理インターフェースに対して provider 属性を rbac に設定し、希望のユーザーとロールで ManagementRealm を更新します。

この例では、以下のユーザーが既存のセキュリティーレルムに追加されています。

グループメンバーシップを基に、ユーザーは以下の RBAC ロールにマップされています。

起動時、JBoss EAP は ManagementRealm と RBAC 設定、および管理インターフェースをコアサービスの一部としてロードします。また、管理インターフェースの HTTPS 用に設定された http-interface も起動されます。ユーザーは HTTPS を介して管理インターフェースにアクセスできるようになり、RBAC も有効化および設定されます。RBAC が有効になっていない場合、ManagementRealm のユーザーはすべて SuperUser として考慮され、アクセスが無制限になります。RBAC が有効になっているため、各ユーザーは持つロールに基づいて制限されるようになりました。Suzy、Tim、Emily、Zach、および Natalie はすべて上記の表で表示される異なるロールを持ちます。たとえば、Suzy と Tim のみがアクセス制御情報の読み取りと変更が可能です。Suzy、Tim、および Emily はランタイム状態や他の永続設定情報を変更できます。Zach もランタイム状態とその他の永続設定情報を編集できますが、アプリケーションリソースにのみ関連します。Suzy、Tim、Emily、Zach、Natalie はすべて設定および状態情報をすべて実行できますが、Natalie は何も更新できません。各ロールの詳細と JBoss EAP による RBAC の処理方法については、「ロールベースのアクセス制御」 および 「管理インターフェースへの RBAC の追加」 セクションを参照してください。

JBoss EAP は、アプリケーション向けの HTTPS の使用をサポートし、web subsystem を使用して処理されます。HTTPS の新しいコネクターは Web subsystem に追加され、希望の設定 (プロトコル、ポート、キーストアなど) で設定されます。設定が保存されると、web アプリケーションは設定されたポート上で HTTPS トラフィックを許可できるようになります。また、認証に IdentityLoginModule を使用する sample-domain という新しいセキュリティードメインも追加されました。sampleApp2.war は、sample-domain を使用してユーザーを認証するように設定されます。

セキュリティードメイン (sample-domain) が作成され、IdentityLoginModule を使用するよう設定されています。以下のクレデンシャルがログインモジュールに設定されています。

JBoss EAP は起動時にコアサービスをロードし、すべての web アプリケーションと sample-domain の HTTPS 接続を管理する web サブシステムおよび security サブシステムを起動します。次に、sampleApp2.war がロードされ、セキュアな URL の認証および承認を提供するために sample-domain を検索します。sampleApp2.war には /hello.html と /secure/hello.html の 2 つの HTML ファイルがあり、BASIC HTTP 認証を使用してパス /secure/* をセキュア化します。sample-domain セキュリティードメインを使用し、sample ロールを必要とします。

Vincent が /hello.html を要求すると、認証なしでページを閲覧できます。Vincent が /secure/hello.html をリクエストすると、ユーザー名とパスワードの入力が求められます。これにより、ログインに成功したら /secure/hello.html を閲覧できます。その他すべてのユーザーはログインせずに /hello.html にアクセスできますが、Vincent は sample-domain の唯一のユーザーであるため、/secure/hello.html にはアクセスできません。これは、HTTPS 上で処理されるすべてのトラフィックにも適用されます。

JBoss EAP は security、web、および infinispan サブシステムの組み合わせを使用し、web アプリケーションでクラスター化された SSO とクラスター化されていない SSO の両方のサポートを提供します。security サブシステムは認証と承認を実行するためのセキュリティードメインを提供します。infinispan および web サブシステムは、JBoss EAP インスタンス上または JBoss EAP クラスター全体のすべての web アプリケーション間で SSO 情報をキャッシュおよび分散できるようにします。4 つの EAP インスタンスはすべてセキュリティードメイン sso-domain を持ち、IdentityLoginModule を使用するよう設定されています。sampleAppA および sampleAppB は、sso-domain セキュリティードメインを使用してパス /secure/* をセキュア化するよう設定され、アクセスするには sample ロールが必要です。以下のクレデンシャルが sso-domain ログインモジュールに設定されています。

4 つの JBoss EAP インスタンスはすべて standalone-full-ha または full-ha プロファイルで起動するよう設定され、このシナリオで SSO を有効化するのに必要な infinispan サブシステムとその他の機能を追加します。web キャッシュコンテナーとレプリケートされた SSO キャッシュも追加され、web サブシステムはこれら両方を使用するよう設定されています。EAP1 と EAP2 の web サブシステムはクラスター化されていない SSO に対して設定され、EAP3 および EAP4 が含まれるクラスターはクラスター化された SSO を使用するよう設定されています。

JBoss EAP は起動時にコアサービスをロードし sso-domain と SSO 情報に関連するキャッシュを管理する security、web、および infinispan サブシステムを起動します。sampleAppA.war および sampleAppB.war は 4 つの JBoss EAP インスタンスすべてでロードされます。各 JBoss EAP インスタンスは、認証および承認を提供するために sso-domain を検索します。

Jane が EAP1/sampleAppA/secure/hello.html にアクセスしようとすると、認証が要求されます。正しい情報を提供した後、Jane は EAP1/sampleAppA/secure/hello.html の閲覧が許可されます。Jane のセッションは web および infinispan サブシステムによって使用される SSO キャッシュに追加されます。Jane が EAP1/sampleAppB/secure/hello.html にアクセスしようとすると、再認証が要求されます。EAP1 で実行されている sampleAppB は、web サブシステムキャッシュと infinispan サブシステムを使用して Jane のセッションを検索します。Jane はすでに認証されているため、アクセスを許可します。Jane は EAP2/sampleAppA/secure/hello.html または EAP2/ sampleAppB/secure/hello.html にアクセスしようとすると、EAP1 と EAP2 はキャッシュを共有しないため、再認証が要求されます。

Jane が EAP3/sampleAppA/secure/hello.html にアクセスしようとすると、認証を要求され、Jane のセッションは SSO キャッシュに保存されます。これらのキャッシュはクラスター全体で保存されるため、Jane が EAP3/sampleAppB/secure/hello.html、EAP4/sampleAppA/secure/hello.html、または EAP4/sampleAppB/secure/hello.html にログインする際に再認証する必要ありません。また、EAP3 または EAP4 のいずれかが再起動した場合、他の JBoss EAP インスタンスとクラスターは稼働状態であるため、Jane の SSO 情報はキャッシュに残るので、キャッシュが保持されます。同様に、Jane のセッションが無効化された場合はキャッシュ全体で無効化され、クラスターでアクセスしようとするアプリケーションやサーバーに関係なく、再認証が要求されます。

JBoss EAP は、web アプリケーションで SAML を介してブラウザーベースの SSO をサポートし、アイデンティティープロバイダーのホストもサポートします。アイデンティティープロバイダーをホストするには、セキュリティードメイン(idp-domain)を定義された認証メカニズムで設定する必要があります。この場合、idp-domain は DatabaseLoginModule を認証方法として使用するよう設定されます。アイデンティティープロバイダーアプリケーション (IDP.war) がその JBoss EAP インスタンス (EAP-IDP) にデプロイされ、idp-domain をアイデンティティーストアとして使用するよう設定されます。IDP.war は、アプリケーションの機能とともにアイデンティティーストアを使用してユーザーを認証し、ユーザーのアイデンティティーとロール情報が含まれる SAML トークンを発行します。3 つの追加の JBoss EAP インスタンス (EAP1、EAP2、および EAP3) はそれぞれ、個別のサービスプロバイダーとして機能する 1 つの異なるアプリケーション (それぞれsampleAppA.war、sampleAppB.war、および sampleAppC) をホストします。各 JBoss EAP インスタンスには、SAML2LoginModule を認証方法として使用するよう設定されている sso-domain セキュリティードメインがあります。各アプリケーションには、SSO をサポートし、IDP.war をアイデンティティープロバイダーとして使用し、認証に HTTP/POST バインディングを使用する機能が含まれています。また、各アプリケーションは sso-domain を使用してパス /secure/* をセキュア化するよう設定され、承認の処理に独自のロールのリストを提供します。

この例では、idp-domain セキュリティードメインの DatabaseLoginModule によって使用されるデータベースに以下のユーザーが追加されています。

EAP-IDP の起動時、管理インターフェースが起動した後に idp-domain を含む security サブシステムを含め、サブシステムとデプロイされたアプリケーション、IDP.war が起動します。IDP-domain はデータベースに接続し、DatabaseLoginModule ログインモジュールに設定されたようにユーザー名、パスワード、およびロールをロードします。機密情報が DatabaseLoginModule ログインモジュールのパスワードハッシュ化の設定にプレーンテキストに保存されないようにするには、特定のフィールドを隠すように設定されます (例: データベースのパスワード)。IDP.war は認証および承認に idp-domain を使用します。IDP.war は (jboss-web.xml、web.xml、picketlink.xml、および jboss-deployment-structure.xml を介して) 設定され、認証されたユーザーに SAML トークンを発行し、ユーザーが認証する簡単なログインフォームを提供します。これにより、アイデンティティープロバイダーとして機能できるようになります。

EAP1、EAP2、および EAP3 の起動時、管理インターフェースが起動した後に security を含むサブシステムとデプロイされたアプリケーションが起動します。security サブシステムには各インスタンスの sso-domain が含まれ、それぞれ sampleAppA.war、sampleAppB.war、および sampleAppC.war が含まれます。sso-domain は SAML2LoginModule ログインモジュールを使用するよう設定されますが、アプリケーションに依存して適切な SAML トークンを提供します。つまり、sso-domain を使用するすべてのアプリケーションは、アイデンティティープロバイダーに正しく接続し、SAML トークンを取得する必要があります。この場合、各 sampleAppA、sampleAppB、および sampleAppC は jboss-web.xml、web.xml、picketlink.xml、および jboss-deployment-structure.xml を介して設定され、アイデンティティープロバイダーのログインフォームを使用して IDP.war から SAML トークンを取得します。

また、各アプリケーションは独自の許可されるロールでも設定されます。

認証されていないユーザーが sso-domain によってセキュア化された URL (すべてのアプリケーションの /secure/*) にアクセスしようとすると、ユーザーは IDP.war のログインページにリダイレクトされます。その後、ユーザーはフォームを使用して認証され、ユーザーのアイデンティティーとロール情報が含まれる SAML トークンが発行されます。ユーザーは元の URL にリダイレクトされ、SAML トークンがアプリケーション (サービスプロバイダー) に提示されます。アプリケーションは SAML トークンが有効であることを確認し、SAML トークンによって提供されたロールとアプリケーションで設定されたロールを基にしてユーザーを承認します。ユーザーに SAML トークンが発行された後、同じアイデンティティープロバイダーを使用して SSO によってセキュア化された別のアプリケーションでは、ユーザーはそのトークンを使用して認証および承認されます。SAML トークンの期限が切れ、無効になると、ユーザーはアイデンティティープロバイダーから新しい SAML トークンを取得する必要があります。

この例では、Eric が EAP1/sampleAppA/secure/hello.html にアクセスすると、ログインのために EAP-IDP/IDP/login.html にリダイレクトされます。正常にログインした後、Eric にユーザー情報とロール all が含まれる SAML トークンが発行され、EAP1/sampleAppA/secure/hello.html にリダイレクトされます。この SAML トークンが sampleAppA に提示され、トークンの確認後にロールを基にして承認が行われます。sampleAppA は、ロール all および AB の /secure/* へのアクセスを許可します。 Eric は all ロールを持っているため、EAP1/sampleAppA/secure/hello.html にアクセスできます。

Eric が EAP2/sampleAppB/secure/hello.html にアクセスしようとすると、このサービスプロバイダーに対しては認証されていないため、認証リクエストとともに IDP.war に再びリダイレクトされます。Eric はすでにアイデンティティープロバイダー (IDP.war) に対して認証されているため、再認証しなくても、そのサービスプロバイダーの新しい SAML トークンを持つ IDP.war によって EAP2/sampleAppB/secure/hello.html にリダイレクトされます。sampleAppB は、新しい SAML トークンを確認し、ロールを基にして承認を行います。sampleAppB は、ロール all および AB の /secure/* へのアクセスを許可します。Eric は all ロールを持っているため、EAP2/sampleAppB/secure/hello.html にアクセスすることもできます。Eric が EAP3/sampleAppC/secure/hello.html にアクセスする場合も同様に処理されます。

SAML トークンがグローバルログアウトによって無効になった後、Eric が EAP1/sampleAppA/secure/hello.html や、EAP2/sampleAppB/secure/* または EAP3/sampleAppC/secure/* 以下の URL に戻ろうとすると、再認証のために EAP-IDP/IDP/login.html へリダイレクトされ、新しい SAML トークンが発行されます。

Amar が EAP1/sampleAppA/secure/hello.html または EAP2/sampleAppB/secure/hello.html にアクセスしようとすると、Eric と同様に処理されます。Amar は AB ロールを持ち、EAP1/sampleAppA/secure/* および EAP2/sampleAppB/secure/* のみにアクセスできます。そのため、EAP3/sampleAppC/secure/hello.html にアクセスしようとすると、SAML トークンの保持または取得が必要になりますが、EAP3/sampleAppC/secure/hello.html の閲覧は制限されます。Brian も同様ですが、EAP3/sampleAppC/secure/* のみにアクセスできます。Alan はロールを持たないため、サービスプロバイダーのセキュアな領域にアクセスしようとすると、SAML トークンの保持または取得が必要になりますが、閲覧はすべて制限されます。各サービスプロバイダーには、承認の有無に関わらず、すべてのユーザーが SAML トークンを取得しなくても閲覧可能なセキュアでない領域もあります。

JBoss EAP は、LDAP および Kerberos を使用したセキュリティーレルムでの認証をサポートします。これには、既存の ManagementRealm が認証タイプとして ldap を使用するよう更新し、LDAP サーバーへのアウトバウンド接続を作成します。これにより、認証方法が digest から BASIC / Plain に変更され、ネットワーク上ではデフォルトでユーザー名とパスワードがクリアテキストで送信されます。

以下のユーザーが LDAP ディレクトリーに追加されています。

起動時、EAP1 は ManagementRealm と管理インターフェースを含むコアサービスをロードします。ManagementRealm は LDAP ディレクトリーサーバーに接続し、必要に応じて管理インターフェースの認証を提供します。

Adam が管理インターフェースにアクセスしようとすると、認証が強制的に実行されます。Adam のクレデンシャルは、認証に LDAP ディレクトリーサーバーを使用する ManagementRealm セキュリティーレルムに渡されます。認証された後、ロールは管理インターフェイスに戻され、認証のために渡されます。Adam は SuperUser ロールを持っているので、管理インターフェイスへのアクセスが許可されます。Sam が管理インターフェースにアクセスしようとすると、LDAP 経由で認証されますが、SuperUser の適切なロールを持たないため、アクセスは拒否されます。

JBoss EAP は、SPNEGO と JBoss Negotiation による web アプリケーションでの SSO に対する Kerberos の使用をサポートします。Kerberos および SPNEGO の詳細は、「サードバーティー SSO 実装」 セクションを参照してください。JBoss EAP とデプロイされた web アプリケーションが認証に Kerberos を使用するようにするには、2 つのセキュリティードメインを作成する必要があります。最初のセキュリティードメイン host-domain は、kerberos ログインモジュールで設定され、Kerberos サーバーへ接続します。これにより、JBoss EAP のコンテナーレベルでの認証が可能になります。2 つ目のセキュリティードメイン spnego-domain は、2 つのログインモジュールで作成されます。その 1 つは spnego ログインモジュールを使用して host-domain に接続し、ユーザーを認証します。もう 1 つは別のログインモジュール (プロパティーファイルを使用してユーザーをロールにマップする UsersRoles など) を使用して、承認の決定に使用するロール情報をロードします。

これら 2 つのログインモジュールは、password-stacking を利用して、承認モジュールのユーザーとロールを認証モジュールのユーザーにマップします。EAP1 は host-domain と spnego-domain の両方で設定されます。アプリケーションは、spnego-domain を使用して認証を実行し、承認のためにユーザーのロールを取得するよう、web.xml および jboss-web.xml を介して設定されます。また、セクリティートークンを OS からブラウザーに渡せない場合のために、FORM 認証をフォールバック認証としてアプリケーションに設定することもできます。FORM 認証がフォールバックとして設定された場合、追加のセキュリティードメインを追加してサポートする必要があります。このセキュリティードメインは Kerberos と SPNEGO には依存せず、FORM 認証のみ (ユーザー名/パスワードの検証およびロール) をサポートする必要があります。各アプリケーションは、spnego-domain を使用するよう設定され、FORM 認証をフォールバックとして提供するよう設定されます。また、各アプリケーションはパス /secure/* をセキュアにするよう設定され、承認の処理に独自のロールリストを提供します。

以下のユーザーが Kerberos サーバーに作成されています。

以下のロールは、 password-stacking オプションを useFirstPass に設定してチェーンされた追加のモジュールを介してユーザーにマップします。

各アプリケーションには以下のロールが設定されています。

起動時に、EAP1 はコアサービスをロードしてから security およびその他のサブシステムをロードします。host-domain は Kerberos サーバーへの接続を確立し、spnego-domain が host-domain に接続します。sampleAppA および sampleAppB がデプロイされ、認証のために spnego-domain に接続します。

Brent は Kerberos でセキュア化されたコンピューターにログインしています。その後、ブラウザーを開き、sampleAppA/secure/hello.html へのアクセスを試みます。これはセキュリティーが保護されているため、認証が必要になります。EAP1 は、Brent のコンピューターに設定されている Kerberos Key Distribution Center (Kerberos サーバー) へのキーを要求するリクエストを送信するよう、ブラウザーに指示します。ブラウザーがキーを取得すると、これは simpleAppA に送信されます。simpleAppA はチケットを spnego-domain に送信します。そこでチケットがアンパックされ、設定済みの Kerberos サーバーとともに host-domain によって認証が実行されます。チケットが認証されたら、Brent のロールは sampleAppA に戻され、承認が実行されます。Brent は all ロールを持っているため、sampleAppA/secure/hello.html にアクセスできます。Brent が sampleAppB/secure/hello.html にアクセスしようとすると、同じ処理が行われ、(all のロールを持つため) アクセスが許可されます。Andy と Bill は同じプロセスに従いますが、Andy は sampleAppA/secure/hello.html のみにアクセスでき、sampleAppB/secure/hello.html にはアクセスできません。Bill はこの逆で、sampleAppB/secure/hello.html にアクセスでき、sampleAppA/secure/hello.html にはアクセスできません。Ron は sampleAppA/secure/hello.html または sampleAppB/secure/hello.html の認証に成功しますが、ロールを持たないためどちらにもアクセスできません。

オフィスのネットサークに接続する個人のラップトップなど、Andy が Kerberos でセキュア化されていないコンピューターから sampleAppA/secure/hello.html にアクセスしようとすると、フォールバックのログインとして FORM ログインページに転送されます。Andy のクレデンシャルはフォールバックセキュリティードメイン経由で認証され、承認の処理が続行されます。