検索

19.8. Web アプリケーション用に Kerberos または MicrosoftActiveDirectory デスクトップ Active Directory を設定する

download PDF

はじめに

Microsoft Active Directory などの組織の既存の Kerberos ベースの認証および承認インフラストラクチャーを使用して Web または EJB アプリケーションを認証するには、JBoss EAP 6 に組み込まれている JBoss ネゴシエーション機能を使用できます。Web アプリケーションを適切に設定した場合、デスクトップまたはネットワークへのログインが成功すれば、Web アプリケーションに対して透過的に認証できるため、追加のログインプロンプトは必要ありません。

プラットフォームの以前のバージョンとの違い

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

  • セキュリティードメインは、管理対象ドメインの各プロファイル、またはスタンドアロンサーバーごとに設定されます。これらはデプロイメント自体には含まれません。デプロイメントが使用するセキュリティードメインは、デプロイメントの jboss-web.xml ファイルまたは jboss-ejb3.xml ファイルで指定されます。
  • セキュリティープロパティーはセキュリティードメインの一部として設定されます。これらはデプロイメントには含まれません。
  • デプロイメントの一部としてオーセンティケーターをオーバーライドすることはできなくなりました。ただし、jboss-web.xml 記述子に NegotiationAuthenticator バルブを追加して、同じ効果を実現することができます。バルブを使用するには、<security-constraint> および <login-config> 要素を web.xml に定義する必要があります。これらの要素は、セキュアなリソースを決定するのに使用されます。しかし、選択した auth-method は jboss-web.xml の NegotiationAuthenticator バルブによって上書きされます。
  • セキュリティードメインの CODE 属性は、完全修飾クラス名ではなく、単純な名前を使用するようになりました。以下の表は、JBoss Negotiation に使用されるクラスとそれらのクラスとの間のマッピングを示しています。
表19.1 ログインモジュールコードとクラス名
簡単な名前 クラス名 目的
Kerberos
com.sun.security.auth.module.Krb5LoginModule
com.ibm.security.auth.module.Krb5LoginModule
Oracle JDK を使用する場合の Kerberos ログインモジュール
IBMJava 開発キットを使用する場合の Kerberos ログインモジュール
SPNEGO org.jboss.security.negotiation.spnego.SPNEGOLoginModule Web アプリケーションが Kerberos 認証サーバーに対して認証できるようにするメカニズム。
AdvancedLdap org.jboss.security.negotiation.AdvancedLdapLoginModule Microsoft Active Directory 以外の LDAP サーバーで使用されます。
AdvancedAdLdap org.jboss.security.negotiation.AdvancedADLoginModule Microsoft Active Directory LDAP サーバーで使用されます。

JBoss Negotiation Toolkit

JBoss Negotiation Toolkit は、から https://community.jboss.org/servlet/JiveServlet/download/16876-2-34629/jboss-negotiation-toolkit.war ダウンロードできるデバッグツールです。これは、アプリケーションを実稼働環境にデプロイする前に認証メカニズムのデバッグおよびテストに役立つ追加ツールとして提供されます。これはサポート対象のツールではありませんが、SPENEGO を web アプリケーションに対して設定するのは難しいこともあるため、大変便利なツールと言えます。

手順19.1 Web または EJB アプリケーションの SSO 認証を設定する

  1. サーバーの ID を表す 1 つのセキュリティードメインを設定します。必要に応じてシステムプロパティーを設定します。

    最初のセキュリティードメインは、コンテナー自体をディレクトリーサービスに対して認証します。実際のユーザーは関与しないため、ある種の静的ログインメカニズムを受け入れるログインモジュールを使用する必要があります。この例では静的プリンシパルを使用し、クレデンシャルが含まれるキータブファイルを参照します。
    XML コードはわかりやすくするためにここに示されていますが、セキュリティードメインを設定するには管理コンソールまたは管理 CLI を使用する必要があります。
    <security-domain name="host" cache-type="default">
       <authentication>
          <login-module code="Kerberos" flag="required">
             <module-option name="storeKey" value="true"/>
             <module-option name="useKeyTab" value="true"/>
             <module-option name="principal" value="host/testserver@MY_REALM"/>
             <module-option name="keyTab" value="/home/username/service.keytab"/>
             <module-option name="doNotPrompt" value="true"/>
             <module-option name="debug" value="false"/>
          </login-module>
       </authentication>
    </security-domain>
  2. 1 つまたは複数の Web アプリケーションを保護するために、2 番目のセキュリティードメインを設定します。必要に応じてシステムプロパティーを設定します。

    2 番目のセキュリティードメインは、Kerberos または SPNEGO 認証サーバーに対して個々のユーザーを認証するために使用されます。ユーザーを認証するために少なくとも 1 つのログインモジュールが必要であり、ユーザーに適用するロールを検索するために別のログインモジュールが必要です。次の XML コードは、SPNEGO セキュリティードメインの例を示しています。これには、ロールを個々のユーザーにマップするための承認モジュールが含まれています。認証サーバー自体でロールを検索するモジュールを使用することもできます。
    <security-domain name="SPNEGO" cache-type="default">
       <authentication>
          <!-- Check the username and password -->
          <login-module code="SPNEGO"  flag="requisite">
             <module-option name="password-stacking" value="useFirstPass"/>
             <module-option name="serverSecurityDomain" value="host"/>
          </login-module>
          <!-- Search for roles -->
          <login-module code="UsersRoles" flag="required">
             <module-option name="password-stacking" value="useFirstPass" />
             <module-option name="usersProperties" value="spnego-users.properties" />
             <module-option name="rolesProperties" value="spnego-roles.properties" />
          </login-module> 
       </authentication>
    </security-domain>
  3. web.xml で security-constraint と login-config を指定します

    web.xml 記述子には、セキュリティーの制約とログイン設定に関する情報が含まれています。以下は、それぞれの値の例です。
    <security-constraint>
       <display-name>Security Constraint on Conversation</display-name>
       <web-resource-collection>
          <web-resource-name>examplesWebApp</web-resource-name>
          <url-pattern>/*</url-pattern>
       </web-resource-collection>
       <auth-constraint>
       <role-name>RequiredRole</role-name>
       </auth-constraint>
    </security-constraint>
    
    <login-config>
       <auth-method>SPNEGO</auth-method>
       <realm-name>SPNEGO</realm-name>
    </login-config>
     
    <security-role>
       <description> role required to log in to the Application</description>
       <role-name>RequiredRole</role-name>
    </security-role>
  4. jboss-web.xml 記述子でセキュリティードメインおよびその他の設定を指定します。

    デプロイメントの jboss-web.xml 記述子でクライアント側のセキュリティードメイン (この例では 2 番目) の名前を指定して、このセキュリティードメインを使用するようにアプリケーションに指示します。
    オーセンティケーターを直接オーバーライドすることはできなくなりました。代わりに、必要に応じて、NegotiationAuthenticator をバルブとして jboss-web.xml 記述子に追加できます。<jacc-star-role-allow> を使用すると、アスタリスク (*) 文字を使用して複数のロール名と一致させることができます。これはオプションです。
    <jboss-web>
       <security-domain>SPNEGO</security-domain>
       <valve>
          <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
       </valve>
       <jacc-star-role-allow>true</jacc-star-role-allow>
    </jboss-web>
  5. アプリケーションの MANIFEST.MF に依存関係を追加して、ネゴシエーションクラスを見つけます。

    Web アプリケーションにはクラスへの依存が必要ですorg.jboss.security.negotiationJBoss Negotiation クラスを見つけるために、デプロイメントの META-INF/MANIFEST.MF マニフェストに追加されます。以下に、適切にフォーマットされたエントリーを示します。
    Manifest-Version: 1.0
    Build-Jdk: 1.6.0_24
    Dependencies: org.jboss.security.negotiation
    • 別の方法として、META-INF/jboss-deployment-structure.xml ファイルを編集して、アプリケーションに依存関係を追加します。
      <?xml version="1.0" encoding="UTF-8"?>
      <jboss-deployment-structure>
        <deployment>
          <dependencies>
      	<module name='org.jboss.security.negotiation'/>
          </dependencies>
        </deployment>
      </jboss-deployment-structure>
注記
セキュリティードメインで使用できる Kerberos ログインモジュールは 1 つだけです。

結果

Web アプリケーションは、Kerberos、Microsoft Active Directory、またはその他の SPNEGO 互換のディレクトリーサービスに対してクレデンシャルを受け入れて認証します。ユーザーがすでにディレクトリーサービスにログインしているシステムからアプリケーションを実行し、必要なロールがすでにユーザーに適用されている場合、Web アプリケーションは認証のプロンプトを表示せず、SSO 機能が実現されます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.