19.8. Web アプリケーション用に Kerberos または MicrosoftActiveDirectory デスクトップ Active Directory を設定する
はじめに
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 に使用されるクラスとそれらのクラスとの間のマッピングを示しています。
簡単な名前 | クラス名 | 目的 |
---|---|---|
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 認証を設定する
サーバーの 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>
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>
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>
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>
アプリケーションの
MANIFEST.MF
に依存関係を追加して、ネゴシエーションクラスを見つけます。Web アプリケーションにはクラスへの依存が必要ですorg.jboss.security.negotiation
JBoss 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>
結果
Web アプリケーションは、Kerberos、Microsoft Active Directory、またはその他の SPNEGO 互換のディレクトリーサービスに対してクレデンシャルを受け入れて認証します。ユーザーがすでにディレクトリーサービスにログインしているシステムからアプリケーションを実行し、必要なロールがすでにユーザーに適用されている場合、Web アプリケーションは認証のプロンプトを表示せず、SSO 機能が実現されます。