第4章 Elytron サブシステムの例

アプリケーションをセキュアにするため、JBoss EAP には事前設定された HTTP 用の application-http-authentication と SASL 用の application-sasl-authentication が同梱されています。application-http-authentication http-authentication-factory は、認証に ApplicationRealm と groups-to-roles を使用する ApplicationDomain を使用します。ApplicationRealm は、ユーザー名、パスワード、およびロール情報に対して application-users.properties および application-roles.properties が関係する properties-realm です。

管理インターフェースをセキュアにするため、JBoss EAP には事前設定された HTTP 用の management-http-authentication と SASL 用の management-sasl-authentication が同梱されています。management-http-authentication http-authentication-factory は、認証に ManagementRealm と groups-to-roles を使用する ManagementDomain を使用します。 ManagementRealm は、ユーザー名、パスワード、およびロール情報に対して mgmt-users.properties および mgmt-roles.properties が関係する properties-realm です。management-sasl-authentication sasl-authentication-factory は JBOSS-LOCAL-USER 認証に local を使用し、DIGEST-MD5 認証に ManagementRealm を使用します。

デフォルトでは JBoss EAP のユーザーは存在しませんが、この例の目的で以下のユーザーが追加されています。

JBoss EAP インスタンスは起動時に、4 つの認証ファクトリーとそれらに関連するセキュリティードメイン、セキュリティーレルム、およびその他設定済みのコンポーネントをロードします。

JBOSS-LOCAL-USER を使用して管理 CLI で管理インターフェースにアクセスしようとするユーザーがいる場合 (JBoss EAP インスタンスと同じホストから管理 CLI を実行している)、そのユーザーは local セキュリティーレルムを使用して ManagementDomain でユーザーを認証しようとする management-sasl-authentication sasl-authentication-factory に転送されます。

Susan が異なるホストから管理 CLI を使用して管理インターフェースにアクセスしようとする場合、SASL で DIGEST-MD5 認証を使用します。Susan は、 ManagementRealm セキュリティーレルムを使用して ManagementDomain でユーザーを認証しようとする management-sasl-authentication sasl-authentication-factory に転送されます。

Susan が web ベースの管理コンソールを使用して管理インターフェースにアクセスしようとする場合、HTTP で DIGEST 認証を使用することになります。Susan は、ManagementRealm セキュリティーレルムを使用して ManagementDomain でユーザーを認証しようとする management-http-authentication http-authentication-factory に転送されます。

アプリケーション sampleApp1.war には /hello.html と /secure/hello.html の 2 つの HTML ファイルがあり、BASIC HTTP 認証を使用してパス /secure/* をセキュアにします。Application Realm を使用し、sample ロールが必要です。ユーザーが sampleApp1.war にアクセスしようとすると、application-http-authentication http-authentication-factory に転送されます。ApplicationRealm セキュリティーレルムを使用して ApplicationDomain でユーザーを認証しようとします。

Sarah が /hello.html を要求すると、認証なしでページを閲覧できます。Sarah が /secure/hello.html を要求すると、ユーザー名とパスワードの入力が求められます。ログインに成功した後、Sarah は /secure/hello.html を閲覧できます。Frank や Susan を含むすべてのユーザーが /hello.html にアクセスできますが、Frank と Susan は /secure/hello.html にはアクセスできません。Frank は sample ロールを持たず、Susan は ApplicationRealm セキュリティーレルムに存在しません。

JBoss EAP では、管理インターフェースとアプリケーションの両方を SSL/TLS でセキュアにすることができます。Elytron を使用してこの設定が統一されたため、管理インターフェースとアプリケーションの両方を同じ SSL/TLS 設定でセキュアにすることができるようになりました。Elytron では、key-store、key-manager、および server-ssl-context を作成して SSL/TLS が設定されます。管理インターフェースに対して SSL/TLS を有効にするには、http-interface で secure-socket-binding を設定し、server-ssl-context を管理インタフェースに割り当てます。これにより、管理インターフェースが HTTP トラフィックに SSL/TLS を使用できるようになります。アプリケーションに対して SSL/TLS を有効にするには、undertow サブシステムで server-ssl-context を https-listener に割り当てます。SSL/TLS の背景情報については、「高度なセキュリティー」を参照してください。

JBoss EAP は起動時に管理インターフェースをコアサービスの一部としてロードします。また、SSL/TLS に対して設定された http-interface も起動します。さらに、アプリケーションの SSL/TLS に設定された undertow サブシステムと、server-ssl-context より SSL/TLS 設定を提供する elytron サブシステムも起動します。SSL/TLS が有効になっているセキュアなポート上で管理インターフェースとアプリケーションの両方にアクセスできます。

JBoss EAP では、ManagementRealm と ApplicationRealm を超えてアイデンティティーストアで管理インターフェースとアプリケーションをセキュア化できます。Elytron では、同じアイデンティティーストアを使用して管理インターフェースとアプリケーションをセキュアにできますが、個別のアイデンティティーストアを設定することもできます。アイデンティティーストアは、filesystem-realm、jdbc-realm、ldap-realm などのセキュリティーレルムによって表されます。この例のために、exampleRealm という名前の filesystem-realm が作成されています。また、exampleDomain という名前のセキュリティードメインも作成されています。このセキュリティードメインは、exampleRealm をアイデンティティーストアとして使用し、groups-to-roles ロールマッパーを使用して exampleRealm によって提供されるグループ情報をロールにデコードし、マッピングパーミッションに default-permission-mapper を使用します。

HTTP 認証では、 exampleHttpAuthFactory という http-authentication-factory が作成されています。これは、認証に global HTTP サーバーファクトリーのメカニズムと exampleDomain を使用します。また、2 つのメカニズム設定があり、1 つは basicExampleDomain として公開される BASIC 認証を使用し、もう 1 つは digestExampleDomain として公開される DIGEST 認証を使用します。HTTP 管理インターフェースは exampleHttpAuthFactory を使用するよう設定されています。また、undertow サブシステムも exampleHttpAuthFactory を使用する新しい application-security-domain で設定されています。アプリケーション sampleApp2.war は BASIC 認証で basicExampleDomain を使用するよう設定されています。

SASL 認証では、exampleSaslAuthFactory という sasl-authentication-factory が作成されています。これは、認証に configured SASL サーバーファクトリーと exampleDomain を使用します。また、digestMD5ExampleDomain として公開される DIGEST-MD5 認証が設定されています。管理インターフェースの SASL 設定は exampleSaslAuthFactory を使用するよう設定されています。

以下のユーザーが exampleRealm に追加されています。

起動時、JBoss EAP はコアサービスをロードし、undertow および elytron サブシステムを起動します。これにより、管理インターフェースをセキュアにし、JBoss EAP にデプロイされたアプリケーションに対して basicExampleDomain、digestExampleDomain、および digestMD5ExampleDomain を公開します。

sampleApp2.war がロードされると、basicExampleDomain を検索し、セキュアな URL の認証および承認を提供します。/hello.html と /secure/hello.html の 2 つの HTML ファイルがあり、BASIC 認証を使用してパス /secure/* をセキュア化します。セキュアな URL にアクセスするには、sample ロールが必要です。

ユーザーの認証時、JBoss EAP へのアクセス方法に応じて、特定のメカニズムを使用してクレデンシャルが提出されます。たとえば、ユーザーが DIGEST 認証で HTTP を使用する管理コンソールにアクセスしようとすると、digestExampleDomain として公開される DIGEST 認証を使用して認証されます。BASIC 認証で HTTP を使用する sampleApp2.war にアクセスしようとすると、basicExampleDomain として公開される BASIC 認証を使用して認証されます。DIGEST 認証で SASL を使用する管理 CLI にアクセスしようとすると、digestMD5ExampleDomain として公開される DIGEST-MD5 を使用して認証されます。HTTP 認証は exampleHttpAuthFactory を使用し、SASL 認証は exampleSaslAuthFactory を使用します。両方の認証ファクトリーは、exampleDomain で認証とロールマッピングに対処します。

Vincent または Issac が管理インターフェースにアクセスしようとすると、ユーザー名とパスワードの入力を要求されます。正常にログインした後、各ユーザーは管理操作を実行できます。

Vincent または Issac が /hello.html をリクエストすると、そのページを認証なしで閲覧できます。Vincent または Issac が /secure/hello.html をリクエストすると、ユーザー名とパスワードの入力を要求されます。正常にログインした後、Vincent は sample ロールを持っているため /secure/hello.html を閲覧できますが、Issac は guest ロールを持っているため /secure/hello.html を閲覧できません。その他すべてのユーザーはログインせずに /hello.html にアクセスできますが、exampleRealm に存在するユーザーは Vincent と Issac のみであるため、/secure/hello.html にはアクセスできません。

JBoss EAP では、管理インターフェースで RBAC を使用できます。RBAC の概念については、RBAC の説明を参照してください。この例では、exampleRealm というセキュリティーレルムを使用します。ロールデコーダー、セキュリティードメイン、認証ファクトリーなどの残りのセキュリティー設定は、新しいアイデンティティーストアを用いた管理インターフェースおよびアプリケーションのセキュア化 と同じになります。RBAC は、管理インターフェースに対して provider 属性を rbac に設定し、希望のユーザーとロールで exampleRealm を更新すると有効になります。

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

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

起動時、JBoss EAP はコアサービスと、セキュリティーおよび RBAC 設定をロードする elytron サブシステムをロードします。RBAC が有効になっていない場合、exampleRealm のユーザーはすべて 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 は、SPNEGO 認証を使用した Kerberos での認証を提供します。Kerberos と SPNEGO に特化した情報は、「サードパーティーの SSO 実装」を参照してください。JBoss EAP とデプロイされた web アプリケーションが認証に Kerberos を使用するようにするには、kerberos-security-factory を作成して Kerberos サーバーに接続します。Kerberos サーバーからユーザーにロールを割り当てるために、セキュリティーレルム、ロールマッパー、およびセキュリティードメインも作成されます。kerberos-security-factory を使用し、認証とロールの割り当てにセキュリティードメインを使用する http-authentication-factory が作成されます。認証方法は SPNEGO 認証を使用し、exampleSpnegoDomain として公開されます。また、undertow サブシステムは、認証に http-authentication-factory を使用するよう設定されます。

sampleAppA と sampleAppB の両方は、認証の実行に exampleSpnegoDomain を使用するよう設定され、承認にユーザーのロールを取得します。セキュリティートークンをオペレーティングシステムからブラウザーに渡すことができない場合のために、FORM 認証をフォールバック認証として両方のアプリケーションに設定することもできます。FORM 認証がフォールバックとして設定された場合、追加の認証方法とサポートするセキュリティードメインを設定する必要があります。認証方法は Kerberos と SPNEGO には依存せず、FORM 認証のみをサポートする必要があります。この場合、追加の認証とサポートするセキュリティードメインを FORM 認証に対して設定し、 exampleFormDomain として公開する必要があります。各アプリケーションは exampleFormDomain を使用し、FORM 認証をフォールバックとして提供するよう、設定されます。また、各アプリケーションはパス /secure/* をセキュアにするよう設定され、承認を処理するために独自のロールリストを提供します。

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

セキュリティードメインを使用して以下のロールがユーザーにマップされます。

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

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

Sande は Kerberos でセキュア化されたコンピューターにログインしています。Sande はブラウザーを開き、sampleAppA/secure/hello.html へのアクセスを試みます。このページはセキュアであるため、認証が必要になります。EAP1 は、Sande のコンピューターに設定されている Kerberos Key Distribution Center (Kerberos サーバー) へのキーを要求するリクエストを送信するよう、ブラウザーに指示します。ブラウザーがキーを取得した後、sampleAppA に送信されます。sampleAppA は exampleSpnegoDomain を使用してチケットを JBoss EAP に送信します。そこでチケットがアンパックされ、kerberos-security-factory の設定済みの Kerberos サーバーとともに認証が実行されます。チケットが認証されたら、Sande のロールは sampleAppA に戻され、承認が実行されます。Sande は all ロールを持っているため、sampleAppA/secure/hello.html にアクセスできます。Sande が sampleAppB/secure/hello.html にアクセスする場合も同じ処理が発生します。 all ロールを持っているため、アクセスが許可されます。Andrea と Betty にも同じ処理が発生しますが、Andrea は sampleAppA/secure/hello.html のみにアクセスでき、sampleAppB/secure/hello.html にはアクセスできません。Betty はこの逆で、sampleAppB/secure/hello.html のみにアクセスでき、sampleAppA/secure/hello.html にはアクセスできません。Chuck は sampleAppA/secure/hello.html または sampleAppB/secure/hello.html の認証に成功しますが、ロールを持たないためどちらにもアクセスできません。

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