第5章 レガシーのコア管理とセキュリティーサブシステムの例

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、Zack、および Natalie は設定および状態情報を読み取りできますが、Natalie は何も更新できません。各ロールの詳細とJBoss EAP による RBAC の処理方法については、「ロールベースのアクセス制御」と「管理インターフェースへの RBAC の追加」を参照してください。

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

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

JBoss EAP は起動時にコアサービスをロードし、すべての web アプリケーションの HTTPS 接続を管理する undertow サブシステムと、sample-domain の HTTPS 接続を管理する 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 は認証なしでこのページを閲覧できます。Vincent が /secure/hello.html をリクエストすると、ユーザー名とパスワードの入力が要求されます。正常にログインした後、Vincent は /secure/hello.html を閲覧できます。その他すべてのユーザーはログインせずに /hello.html にアクセスできますが、sample-domain に存在するユーザーは Vincent のみであるため、/secure/hello.html にはアクセスできません。これは、HTTPS 上で処理されるすべてのトラフィックにも適用されます。

JBoss EAP は security、undertow、および infinispan サブシステムの組み合わせを使用し、web アプリケーションでクラスター化された SSO とクラスター化されていない SSO のサポートを提供します。security サブシステムは認証と承認を実行するためのセキュリティードメインを提供します。infinispan および undertow サブシステムは、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 キャッシュも追加され、undertow サブシステムはこれら両方を使用するよう設定されています。EAP1 と EAP2 の undertow サブシステムはクラスター化されていない SSO に対して設定され、EAP3 および EAP4 が含まれるクラスターはクラスター化された SSO を使用するよう設定されています。

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

Jane が EAP1/sampleAppA/secure/hello.html にアクセスしようとすると、認証が要求されます。正しい情報を提供した後、Jane は EAP1/sampleAppA/secure/hello.html の閲覧が許可されます。Jane のセッションは undertow および infinispan サブシステムによって使用される SSO キャッシュに追加されます。Jane が EAP1/sampleAppB/secure/hello.html にアクセスしようとすると、再認証は要求されません。EAP1 で実行されている sampleAppB は、undertow サブシステムキャッシュと 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 アプリケーション (例: IDP.war) がその JBoss EAP インスタンス (この例では EAP-IDP) にデプロイされ、idp-domain をアイデンティティーストアとして使用するよう設定されます。IDP.war は、アプリケーションの機能とともにアイデンティティーストアを使用してユーザーを認証し、ユーザーのアイデンティティーとロール情報が含まれる SAML トークンを発行します。EAP1、EAP2、および EAP3 の 3 つの JBoss EAP インスタンスは、それぞれ個別の SP として動作するアプリケーション sampleAppA.war、sampleAppB.war、および sampleAppC をホストします。各 JBoss EAP インスタンスには、SAML2LoginModule を認証方法として使用するよう設定されている sso-domain セキュリティードメインがあります。各アプリケーションには、SSO をサポートし、 IDP.war をアイデンティティープロバイダーとして使用し、認証に HTTP/POST バインディングを使用する機能が含まれています。また、各アプリケーションは sso-domain を使用してパス /secure/* をセキュア化するよう設定され、承認の処理に独自のロールのリストを提供します。

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

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

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

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

認証されていないユーザーが sso-domain によってセキュア化された URL (すべてのアプリケーションの /secure/*) にアクセスしようとすると、ユーザーは IDP.war のログインページにリダイレクトされます。その後、ユーザーはフォームを使用して認証され、ユーザーのアイデンティティーとロール情報が含まれる SAML トークンが発行されます。ユーザーは元の URL にリダイレクトされ、SAML トークンが SP であるアプリケーションに提示されます。アプリケーションは SAML トークンが有効であることを確認し、SAML トークンによって提供されたロールとアプリケーションで設定されたロールを基にしてユーザーを承認します。ユーザーに SAML トークンが発行された後、同じ IDP を使用して SSO によってセキュア化された別のアプリケーションでは、ユーザーはそのトークンを使用して認証および承認されます。SAML トークンの期限が切れ、無効になると、ユーザーは IDP から新しい 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 にアクセスしようとすると、この SP に対しては認証されていないため、認証リクエストとともに IDP.war にリダイレクトされます。Eric はすでに IDP に対して認証されているため、その SP に対する新しい 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 トークンの保持または取得が必要になりますが、閲覧はすべて制限されます。各 SP には、承認の有無に関わらず、すべてのユーザーが SAML トークンを取得しなくても閲覧可能なセキュアでない領域もあります。

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

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

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

Adam が管理インターフェースにアクセスしようとすると、認証が強制的に実行されます。Adam のクレデンシャルは、認証に LDAP ディレクトリーサーバーを使用する ManagementRealm セキュリティーレルムに渡されます。EAP1 は認証後にデフォルトの簡単なアクセス制御を使用しているため、Adam のロールはチェックされず、アクセスが許可されます。Sam が管理インターフェースにアクセスしようとしても同様に処理されます。

Adam の認証後に RBAC が有効化されると、承認のために Adam のロールは管理インターフェースに戻されます。Adam は SuperUser ロールを持っているため、管理インターフェースへのアクセスが許可されます。サムが RBAC が有効になっている管理インターフェースにアクセスしようとすると、LDAP によって認証されますが、適切なロールを持っていないためアクセスは拒否されます。

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 を介して設定されます。また、セクリティートークンをオペレーティングシステムからブラウザーに渡せない場合のために、FORM 認証をフォールバック認証としてアプリケーションに設定することもできます。FORM 認証がフォールバックとして設定された場合、追加のセキュリティードメインを追加してサポートする必要があります。このセキュリティードメインは Kerberos と SPNEGO には依存せず、FORM 認証のみ (ユーザー名とパスワードの検証およびロール) をサポートする必要があります。各アプリケーションは、spnego-domain を使用するよう設定され、FORM 認証をフォールバックとして提供するよう設定されます。また、各アプリケーションはパス /secure/* をセキュアにするよう設定され、承認の処理に独自のロールリストを提供します。