Kerberos はチケットと呼ばれるセキュリティートークンを使用します。セキュアなサービスを使用するには、ユーザーはネットワークのサーバーで実行されるサービスであるチケット付与サービス (TGS: Ticket Granting Service) からチケットを取得する必要があります。チケットの取得後、同じネットワークで実行される別のサービスである認証サービス (AS) からサービスチケット (ST) を要求します。その後、ユーザーは ST を使用して希望のサービスに対して認証されます。TGS と AS は、キー配布センター (KDC) と呼ばれるエンクロージングサービス内で実行されます。

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

web ブラウザーなどのクライアントコンピューター上のアプリケーションが web サーバーの保護されたページにアクセスしようとすると、サーバーは承認が必要であることを伝えます。アプリケーションは KDC から ST を要求します。アプリケーションはチケットを SPNEGO 用にフォーマットされたリクエストにラップし、ブラウザー経由で web アプリケーションに返信します。デプロイされた web アプリケーションを実行している web コンテナーはリクエストをアンパックし、チケットを認証します。認証が正常に行われると、アクセスできるようになります。

SPNEGO は、Red Hat Enterprise Linux 内の Kerberos サービスや、Microsoft Active Directory の不可欠な要素である Kerberos サーバーなど、すべてのタイプの Kerberos プロバイダーと動作します。

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

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

小さいコンポーネントを使用して完全なセキュリティーポリシーを組み立てるのが、elytron サブシステムのアーキテクチャーやデザインの背後にある概念です。デフォルトでは、JBoss EAP は多くのコンポーネントの実装を提供しますが、elytron サブシステムは特殊なカスタム実装の提供も可能にします。

elytron サブシステムのコンポーネントの各実装は、個別の性能として処理されます。そのため、異なるリソースを使用して異なる実装を組み合わせ、モデル化できます。

複数のプリンシパルトランスフォーマー、レルムマッパー、およびプリンシパルデコーダーは、elytron サブシステム内に定義できます。以下のセクションでは、認証プロセス中にこれらのコンポーネントどのように機能するかを説明し、さらにプリンシパルが適切なセキュリティーレルムにマップされる方法についても説明します。

プリンシパルが認証されると、以下の手順が順番に実行されます。

以下の図は上記の手順を表しています。左側の緑の部分は各手順を示し、右側は各段階で使用されるコンポーネントを表しています。

図2.1 Elytron 認証プロセス

レルムの前のマッピング

レルムの前のマッピングが行われる間、認証されたプリンシパルは SecurityIdentity にマップされます。SecurityIdentity は使用されるセキュリティーレルムを特定できるフォームで、認証された情報を表す単一の Principal を含みます。プリンシパルトランスフォーマーとプリンシパルデコーダーは次の順番で呼び出されます。

この手順によって null プリンシパルが発生した場合、エラーが発生し、認証は強制終了されます。

図2.2 レルムの前のマッピング

レルム名マッピング

マップされたプリンシパルが取得されると、アイデンティティーのロードに使用されるセキュリティーレルムが特定されます。この時点では、レルム名はセキュリティードメインによって参照され、セキュリティーレルムによって定義される名前で、メカニズムレルム名ではありません。設定は、セキュリティーレルム名を次の順序で検索します。

RealmMapper が null を返す場合や、利用できるマッパーがない場合、セキュリティードメインの default-realm が使用されます。

図2.3 レルム名マッピング

レルムの後のマッピング

レルムの特定後、プリンシパルに対して次の変換が実行されます。変換は次の順番で呼び出しされます。

この手順によって null プリンシパルが発生した場合、エラーが発生し、認証は強制終了されます。

図2.4 レルムの後のマッピング

最終のプリンシパル変換

最後に、メカニズム固有の変換がドメイン固有の変換の前および後に適用されるようにするため、最後のプリンシパル変換が発生します。これが必要でない場合、レルムの後のマッピング の段階で同じ結果が得られます。変換は次の順序で呼び出しされます。

この手順によって null プリンシパルが発生した場合、エラーが発生し、認証は強制終了されます。

図2.5 最終のプリンシパル変換

レルムアイデンティティーの取得

最終のプリンシパル変換の後、認証の継続に使用されるレルムアイデンティティーを取得するため、レルム名マッピング で特定されたセキュリティーレルムが呼び出しされます。

Elytron は、BASIC、FORM、DIGEST、SPNEGO、および CLIENT_CERT を含む完全な HTTP 認証メカニズムを提供します。HTTP 認証は、HttpAuthenticationFactory を使用して処理されます。HttpAuthenticationFactory は HTTP 認証メカニズムを使用するための認証ポリシーであり、設定された認証メカニズムのファクトリーでもあります。

HttpAuthenticationFactory は以下を参照します。

SASL は、認証メカニズム自体を使用するプロトコルから分離するフレームワークです。また、DIGEST-MD5、GSSAPI、OTP、SCRAM などの追加の認証メカニズムも使用できます。SASL 認証は Java EE 7 の一部ではありません。SASL 認証は、SaslAuthenticationFactory を使用して処理され、SaslAuthenticationFactory は SASL 認証メカニズムを使用するための認証ポリシーであり、設定された認証メカニズムのファクトリーでもあります。

SaslAuthenticationFactory は以下を参照します。

レガシー security サブシステムコンポーネントおよびレガシーコア管理認証両方の主なコンポーネントの一部を Elytron の性能にマップできます。これにより、これらのレガシーコンポーネントを Elytron ベースの設定で使用でき、レガシーコンポーネントから増分移行を行うことができます。

JBoss EAP は、elytron サブシステムで以下のリソースを提供します。

ファクトリー

プリンシパルトランスフォーマー

プリンシパルデコーダー

レルムマッパー

レルム

パーミッションマッパー

ロールデコーダー

ロールマッパー

SSL コンポーネント

その他

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

ダイジェストは認証のメカニズムで、プロパティーファイルをマッピングするユーザー名およびパスワードに格納された情報など、さまざまな情報で構成される 1 度限りの一方向ハッシュを使用してユーザーを認証します。これにより、JBoss EAP はネットワーク上でプレーンテキストのパスワードを送信せずに認証を行うことができます。

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

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

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

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

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

管理インターフェースや認証および承認方法のデフォルト設定を変更する方法は複数あります。

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

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

また、cache-type 属性を使用して、セキュリティードメインによって使用される認証キャッシュのタイプを設定することもできます。この属性を削除するとキャッシュは使用されません。このプロパティーに使用できる値は default または infinispan です。

Elytron セキュリティードメインと PickeBox セキュリティードメインの比較

デプロイメントを単一の Elytron セキュリティードメインか、1 つ以上のレガシー PicketBox セキュリティードメインと関連付ける必要があります。デプロイメントを Elytron と PicketBox の両方に関連付けしてはなりません。これは無効な設定です。

デプロイメントを複数の Elytron セキュリティードメインと関連付けると例外が発生しますが、レガシーセキュリティードメインの場合は複数関連付けることが可能です。

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

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

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

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

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

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

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

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

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

1 つの SP で開始されるグローバルログアウトは、IDP およびすべての SP からユーザーをログアウトします。グローバルログアウトの実行後に、SP または IDP のセキュアな部分にアクセスするユーザーは再認証が必要になります。

アプリケーションをセキュアにするため、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 のクレデンシャルはフォールバックの認証を使用して認証され、承認の処理が続行されます。

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/* をセキュアにするよう設定され、承認の処理に独自のロールリストを提供します。