第2章 JBoss EAP における Kerberos での SSO のセットアップ方法


2.1. 必要なコンポーネント

JBoss EAP に Kerberos による SSO を設定する場合、以下のコンポーネントが必要になります。

  • 適切に設定された Kerberos 環境
  • JBoss EAP インスタンス
  • web アプリケーション

2.1.1. JBoss Negotiation Toolkit

JBoss Negotiation Toolkit は、アプリケーションを本番環境に導入する前に認証メカニズムのデバッグおよびテストを行えるようにするデバッグツールです。これはサポート対象のツールではありませんが、SPENEGO を web アプリケーションに対して設定するのは難しいこともあるため、大変便利なツールと言えます。

JBoss Negotiation Toolkit の事前ビルドされた WAR ファイルは JBoss Negotiation Toolkit リポジトリーからダウンロードできます。JBoss EAP に含まれる JBoss Negotiation のバージョンと一致する JBoss Negotiation Toolkit のバージョンをダウンロードする必要があります。たとえば、JBoss EAP 7.1 をご使用の場合は、バージョンが 3.0.4.Final-redhat-1 の JBoss Negotiation を使用するため、jboss-negotiation-toolkit-3.0.4.Final.war を使用する必要があります。使用している JBoss Negotiation のバージョンを確認するには、EAP_HOME/modules/system/layers/base/org/jboss/security/negotiation/main/module.xml を確認します。

2.2. Kerberos 環境

JBoss EAP での Kerberos による SSO の提供」で説明したとおり、Kerberos はサードパーティーの KDC に依存して認証および承認決定を提供します。これには、KDC との認証にブラウザーなどのクライアントとそれらのホストが適切に設定されている必要もあります。本書では主に JBoss EAP とホストされる web アプリケーションを中心に取り上げるため、KDC および Kerberos ドメインの設定については本書の範囲外となります。

注記

これ以降の項では、KDC と Kerberos ドメインがすでにセットアップされ、適切に設定されていることを仮定します。

2.3. これまでのバージョンの JBoss EAP とは異なる設定

JBoss EAP 7.1 とこれまでのバージョンには顕著な違いがいくつかあります。

  • jboss-web.xml には NegotiationAuthenticator バルブが必要でなくなりましたが、引き続き <security-constraint> および <login-config> 要素を web.xml に定義する必要があります。これらの要素は、セキュアなリソースを決定するのに使用されます。
  • <login-config> 要素の auth-method 要素はカンマ区切りリストになりました。正確な値の SPNEGO が必要で、このリストの 1 番目に記載する必要があります。フォールバックに FORM 認証を希望する場合は、正確な値は SPNEGO,FORM になります。
  • elytron サブシステムを使用する場合は jboss-deployment-structure.xml ファイルは必要ありません。

2.4. JBoss EAP インスタンスの設定

JBoss EAP にデプロイされたアプリケーションが elytron またはレガシー security サブシステムのいずれかを使用するように設定することができますが、両方を使用するように設定することはできません。

2.4.1. Elytron サブシステムの設定

重要

以下の手順は、KDC、Kerberos ドメイン、およびブラウザーが設定され、動作していることを仮定しています。

  1. kerberos-security-factory を設定します。

    /subsystem=elytron/kerberos-security-factory=krbSF:add(principal="HTTP/host@REALM", path="/path/to/http.keytab", mechanism-oids=[1.2.840.113554.1.2.2, 1.3.6.1.5.5.2])
  2. Kerberos のシステムプロパティーを設定します。

    環境の設定に応じて、以下のシステムプロパティーを設定する必要があります。

    システムプロパティー説明

    java.security.krb5.kdc

    KDC のホスト名。

    java.security.krb5.realm

    レルムの名前。

    java.security.krb5.conf

    設定 krb5.conf ファイルへのパス。

    sun.security.krb5.debug

    true の場合、デバッグモードが有効になります。

    管理 CLI を使用する場合、以下のように JBoss EAP のシステムプロパティーを設定します。

    /system-property=java.security.krb5.conf:add(value="/path/to/krb5.conf")
  3. ロールを割り当てるために Elytron セキュリティーレルムを設定します。

    クライアントの Kerberos トークンはプリンシパルを提供しますが、そのプリンシパルをロールにマップする方法が必要になります。これには複数の方法がありますが、この例では filesystem-realm を作成し、Kerberos トークンからのプリンシパルと一致するレルムにユーザーを追加し、ロールをそのユーザーに割り当てます。

    重要

    filesystem-realm はテクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジプレビュー機能のサポート範囲」を参照してください。

    /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users, relative-to=jboss.server.config.dir)
    
    /subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity(identity=user1@REALM)
    
    /subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity-attribute(identity=user1@REALM, name=Roles, value=["Admin","Guest"])
  4. simple-role-decoder を追加します。

    /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)

    この simple-role-decoder は、Roles 属性からのプリンシパルのロールをデコードします。ロールが別の属性にある場合はこの値を変更できます。

  5. security-domain を設定します。

    /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm, role-decoder=from-roles-attribute}], default-realm=exampleFsRealm, permission-mapper=default-permission-mapper)
  6. kerberos-security-factory を使用する http-authentication-factory を設定します。

    /subsystem=elytron/http-authentication-factory=example-krb-http-auth:add(http-server-mechanism-factory=global, security-domain=exampleFsSD, mechanism-configurations=[{mechanism-name=SPNEGO, mechanism-realm-configurations=[{realm-name=exampleFsSD}], credential-security-factory=krbSF}])
  7. undertow サブシステムで application-security-domain を設定します。

    /subsystem=undertow/application-security-domain=app-spnego:add(http-authentication-factory=example-krb-http-auth)

2.4.2. レガシー security サブシステムの設定

JBoss EAP には、デプロイされたアプリケーションと SSO に SPNEGO および JBoss Negotiation を使用して Kerberos を使用するのに必要なすべてのコンポーネントが含まれていますが、以下の設定を変更する必要があります。

注記

ここで使用する管理 CLI コマンドは、JBoss EAP スタンドアロンサーバーを実行していることを仮定しています。JBoss EAP 管理対象ドメインの管理 CLI を使用する場合の詳細は Management CLI Guide を参照してください。

  1. サーバーアイデンティティーまたはホスト、セキュリティードメインの設定

    このセキュリティードメインは、コンテナー自体を KDC へ認証します。ユーザーではなくコンテナー自体の認証であるため、静的ログインメカニズムを受容するログインモジュールを使用する必要があります。この例では静的プリンシパルを使用し、クレデンシャルが含まれるキータブファイルを参照します。

    例: サーバーアイデンティティーセキュリティードメインの作成

    /subsystem=security/security-domain=host:add(cache-type=default)
    
    /subsystem=security/security-domain=host/authentication=classic:add()
    
    /subsystem=security/security-domain=host/authentication=classic/login-module=Kerberos:add(code=Kerberos, flag=required, module-options=[storeKey=true, refreshKrb5Config=true, useKeyTab=true, principal=host/testserver@MY_REALM, keyTab=/home/username/service.keytab, doNotPrompt=true, debug=false])
    
    reload

    IBM JDK を使用している場合、Kerberos モジュールのオプションは異なります。jboss.security.disable.secdomain.option システムプロパティーは true に設定する必要があります。詳細は、「関連するシステムプロパティーの設定」を参照してください。ログインモジュールは次のように設定する必要があります。

    例: IBM JDK

    /subsystem=security/security-domain=host:add(cache-type=default)
    
    /subsystem=security/security-domain=host/authentication=classic:add()
    
    /subsystem=security/security-domain=host/authentication=classic/login-module=Kerberos:add(code=Kerberos, flag=required, module-options=[principal=host/testserver@MY_REALM, keyTab="file:///root/keytab", credsType=acceptor])
    
    reload

    Kerberos ログインモジュールの設定オプションの完全リストは、JBoss EAP『Login Module Reference』を参照してください。

  2. web アプリケーションセキュリティードメインを設定します。

    web アプリケーションセキュリティードメインは、個別のユーザーを KDC に対して認証するために使用されます。ユーザーの認証には最低でも 1 つのログインモジュールが必要になります。また、ユーザーに適用するロールを検索する方法も必要になります。これは、手動でユーザーをロールにマップする <mapping> を追加したり、ユーザーをロールにマップする 2 つ目のログインモジュールを追加するなど、複数の方法で実現できます。

    以下は、web アプリケーションセキュリティードメインの例になります。

    例: サーバーアイデンティティーセキュリティードメインの作成

    /subsystem=security/security-domain=app-spnego:add(cache-type=default)
    
    /subsystem=security/security-domain=app-spnego/authentication=classic:add()
    
    /subsystem=security/security-domain=app-spnego/authentication=classic/login-module=SPNEGO:add(code=SPNEGO, flag=required, module-options=[serverSecurityDomain=host])
    
    reload

    SPNEGO ログインモジュールの設定オプションの完全リストは、JBoss EAP『Login Module Reference』を参照してください。

  3. 関連するシステムプロパティーの設定

    JBoss EAP は、Kerberos サーバーへの接続に関連するシステムプロパティーを設定する機能を提供します。KDC、Kerberos ドメイン、および ネットワーク設定に応じて、以下のシステムプロパティーが必要 (または不必要) になります。

    <system-properties>
      <property name="java.security.krb5.kdc" value="mykdc.mydomain"/>
      <property name="java.security.krb5.realm" value="MY_REALM"/>
      <property name="java.security.krb5.conf" value="/path/to/krb5.conf"/>
      <property name="jboss.security.disable.secdomain.option" value="true"/>
      <property name="sun.security.krb5.debug" value="false"/>
    </system-properties>
    プロパティー説明

    java.security.krb5.kdc

    KDC のホスト名。

    java.security.krb5.realm

    レルムの名前。

    java.security.krb5.conf

    設定 krb5.conf ファイルへのパス。

    jboss.security.disable.secdomain.option

    true に設定すると、jboss.security.security_domain ログインモジュールオプションのセキュリティードメインで宣言されたログイモジュールへの自動追加が無効になります。IBM JDK を使用する場合は true に設定する必要があります。

    sun.security.krb5.debug

    true の場合、デバッグモードが有効になります。

    注記

    デフォルトでは、セキュリティードメインに定義された各ログインモジュールに自動的に jboss.security.security_domain モジュールオプションが追加されている必要があります。このオプションは、既知のオプションのみが定義されるようにチェックを行うログインモジュールでは問題が発生します。IBM Kerberos ログインモジュールである com.ibm.security.auth.module.Krb5LoginModule はこのようなログインモジュールの 1 つです。このモジュールオプションを追加する動作を無効にするには、JBoss EAP の起動時に jboss.security.disable.secdomain.option システムプロパティーを true に設定します。これを行うには、管理 CLI または管理コンソールを使用して <system-properties> を設定するか、-Djboss.security.disable.secdomain.option=true を起動パラメーターに追加します。

    システムプロパティーの設定に関する詳細は、JBoss EAP『Management CLI Guide』を参照してください。

2.5. Web アプリケーションの設定

セキュリティードメインが設定されたら、Kerberos 認証を有効にするために、設定したセキュリティードメインを使用するよう web アプリケーションを設定する必要があります。アプリケーションを変更した後、JBoss EAP インスタンスにデプロイして認証に Kerberos を使用することができます。

アプリケーションに以下の更新を行う必要があります。

  1. SPNEGO 認証メソッドを使用するよう web.xml を設定します。

    web.xml ファイルには以下が含まれる必要があります。

    • セキュアな領域の URL パターンにマップする <url-pattern> が含まれる <web-resource-collection> を持つ <security-constraint>。任意で、<security-constraint> に許可されるロールを明記する <auth-constraint> を含めることもできます。
    • <auth-constraint> にロールが指定されている場合、これらのロールを <security-role> で定義する必要があります。
    • SPNEGO正確な 値を持つ <auth-method> が含まれる <login-config>

      重要

      <auth-method> 要素は特定の値のカンマ区切りリストを想定します。SPNEGO 認証を適切に設定するには、正確な値の SPNEGO が最初に <auth-method> 要素に記載される必要があります。追加の認証タイプの取り入れについては「FORM ログインをフォールバックとして追加」を参照してください。

      <security-constraint> および <security-role> 要素を使用すると、管理者は URL パターンおよびロールを基に制限された領域または無制限の領域をセットアップできます。これにより、リソースをセキュリティーで保護することができ、保護しないこともできます。

      例: web.xml ファイル

      <web-app>
        <display-name>App1</display-name>
        <description>App1</description>
        <!-- Define a security constraint that requires the Admin role to access resources -->
        <security-constraint>
          <display-name>Security Constraint on Conversation</display-name>
          <web-resource-collection>
            <web-resource-name>exampleWebApp</web-resource-name>
            <url-pattern>/*</url-pattern>
          </web-resource-collection>
          <auth-constraint>
            <role-name>Admin</role-name>
          </auth-constraint>
        </security-constraint>
        <!-- Define the Login Configuration for this Application -->
        <login-config>
          <auth-method>SPNEGO</auth-method>
          <realm-name>SPNEGO</realm-name>
        </login-config>
        <!-- Security roles referenced by this web application -->
        <security-role>
          <description>Role required to log in to the Application</description>
          <role-name>Admin</role-name>
        </security-role>
      </web-app>

  2. 設定されたセキュリティードメインを使用するよう jboss-web.xml を設定します。

    jboss-web.xml ファイルには以下が必要です。

    • 認証または承認に使用されるセキュリティードメインを指定する <security-domain>
    • 複数のロール名と照合するために web.xml の role-name 要素でアスタリスクの使用を有効にする <jacc-star-role-allow> (任意)。

      例: jboss-web.xml ファイル

      <jboss-web>
        <security-domain>app-spnego</security-domain>
        <jacc-star-role-allow>true</jacc-star-role-allow>
      </jboss-web>

  3. JBoss Negotiation の依存関係をレガシー security サブシステムのデプロイメントに追加します。

    重要

    elytron サブシステムを使用している場合は、この手順を省略できます。

    SPNEGO および JBoss Negotiation を使用する web アプリケーションでは、JBoss Negotiation クラスが見つかるようにするため、依存関係を jboss-deployment-structure.xml に定義する必要があります。JBoss EAP は必要なすべての JBoss Negotiation と関連クラスを提供するため、アプリケーションはこれらの依存関係を宣言して使用することのみが必要となります。

    jboss-deployment-structure.xml を使用した依存関係の宣言

    <jboss-deployment-structure>
      <deployment>
        <dependencies>
          <module name="org.jboss.security.negotiation"/>
        </dependencies>
      </deployment>
    </jboss-deployment-structure>

    この代わりに、依存関係を META-INF/MANIFEST.MF ファイルに定義することもできます。

    META-INF/MANIFEST.MF を使用して依存関係の宣言

    Manifest-Version: 1.0
    Dependencies: org.jboss.security.negotiation

2.6. Active Directory に関する注意点

本項では、Active Directory ドメインの一部である Microsoft Windows サーバー上で JBoss EAP が実行されている場合に、SPNEGO 認証の使用で必要となるアカウントの設定方法を説明します。

ここでは、サーバーへのアクセスに使用されるホスト名はHOST_NAME、レルムは REALM、ドメインはDOMAIN、JBoss EAP インスタンスをホストするサーバーは MACHINE_NAME を使用します。

2.6.1. Microsoft Windows ドメインの設定

  1. 既存のサービスプリンシパルマッピングを消去します。

    Microsoft Windows ネットワークでは、一部のマッピングが自動作成されます。自動的に作成されたマッピングを削除し、ネゴシエーションが適切に行われるようにサーバーのアイデンティティーをサービスプリンシパルへマップします。マッピングにより、クライアントコンピューター上の Web ブラウザーがサーバーを信頼し、SPNEGO の実行を試みます。クライアントコンピューターは、HTTP/HOST_NAME 形式のマッピングに対し、ドメインコントローラーを検証します。

    既存のマッピングを削除する手順は次のとおりです。

    以下のコマンドを使用して、コンピューターに対してドメインに登録されたマッピングをリストします。

    setspn -L MACHINE_NAME

    以下のコマンドを使用して、既存のマッピングを削除します。

    setspn -D HTTP/HOST_NAME MACHINE_NAME

    setspn -D host/HOST_NAME MACHINE_NAME
  2. ホストユーザーアカウントを作成します。

    注記

    ホスト名には MACHINE_NAME 以外の名前を使用してください。

    これ以降では、ホストユーザー名として USER_NAME を使用します。

  3. USER_NAMEHOST_NAME との間のマッピングを定義します。

    以下のコマンドを実行して、サービスプリンシパルマッピングを設定します。

    ktpass -princ HTTP/HOST_NAME@REALM -pass * [-kvno 0] -mapuser DOMAIN\USER_NAME -out jboss.keytab -ptype KRB5_NT_PRINCIPAL -crypto all

    入力を要求されたら、ユーザー名のパスワードを入力します。

    コマンド setspn -L USER_NAME を実行してマッピングを検証します。

    注記

    JRE から KrbException: Specified version of key is not available エラーを取得した場合、-kvno 0 を指定してキーバージョンを 0 に設定する必要があることがあります。REALM はすべて大文字にする必要がありますが、HOST_NAME はすべて小文字にします。また、HOST_NAME は FQDN (完全修飾ドメイン名) である必要があり、CNAME レコードではなく、解決可能な A または AAAA レコードである必要があります。

    -crypto all の使用は Windows Server 2008 およびそれ以降でのみ動作します。Windows Server 2003 では正確な設定を指定する必要があります。

  4. セキュリティードメイン内でプリンシパルを定義します。

    プリンシパルは elytron または security サブシステムで HTTP/HOST_NAME@REALM に定義または更新できます。

    重要

    オプションやパスワードの変更など、ユーザーに変更を加える場合は、keytab を再生成する必要があります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.