第3章 その他の機能
3.1. FORM ログインをフォールバックとして追加
JBoss EAP および JBoss EAP にデプロイされたアプリケーションでは、FORM ログイン認証メカニズムを設定してフォールバックとして使用することもできます。これにより、アプリケーションは Kerberos/SPNEGO トークンが存在しない場合の認証でログインページを提示できます。この認証は、Kerberos認証とは独立して行われます。そのため、FORM ログインフォールバックの設定方法によっては、認証に個別のクレデンシャルが必要なことがあります。
SPNEGO または NTLM トークンが存在しない場合、または存在する SPNEGO トークンが他の KDC からである場合に、FORM ログインへのフォールバックが利用できます。
3.1.1. アプリケーションの更新
FORM ログインをフォールバックとして使用するには、アプリケーションの設定に以下の手順が必要になります。
Kerberos および SPNEGO を使用するよう JBoss EAP および web アプリケーションを設定します。
認証および承認に Kerberos および SPNEGO を使用するための、JBoss EAP および web アプリケーションの設定手順は、「JBoss EAP における Kerberos での SSO のセットアップ方法」を参照してください。
ログインおよびエラーページを追加します。
FORM ログインを使用するには、ログインおよびエラーページが必要です。これらのファイルは web アプリケーションに追加され、認証プロセスで使用されます。
例:
login.jspファイル<html> <head></head> <body> <form id="login_form" name="login_form" method="post" action="j_security_check" enctype="application/x-www-form-urlencoded"> <center> <p>Please login to proceed.</p> </center> <div style="margin-left: 15px;"> <p> <label for="username">Username</label> <br /> <input id="username" type="text" name="j_username"/> </p> <p> <label for="password">Password</label> <br /> <input id="password" type="password" name="j_password" value=""/> </p> <center> <input id="submit" type="submit" name="submit" value="Login"/> </center> </div> </form> </body> </html>例:
error.jspファイル<html> <head></head> <body> <p>Login failed, please go back and try again.</p> </body> </html>web.xmlを編集します。ログインおよびエラーページを web アプリケーションに追加した後、
web.xmlを更新して FORM ログインでこれらのファイルが使用されるようにする必要があります。FORMという値をそのまま<auth-method>に追加する必要があります。<auth-method>はカンマ区切りリストを想定し、順番が重要であるため、<auth-method>の値を正確にSPNEGO,FORMに更新する必要があります。さらに、<form-login-config>要素を<login-config>と、<form-login-page>および<form-error-page>要素として指定されたログインおよびエラーページへのパスに追加する必要があります。例: 更新された
web.xmlファイル<web-app> <display-name>App1</display-name> <description>App1</description> <!-- Define a security constraint that requires the All role to access resources --> <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>All</role-name> </auth-constraint> </security-constraint> <!-- Define the Login Configuration for this Application --> <login-config> <auth-method>SPNEGO,FORM</auth-method> <realm-name>SPNEGO</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config> <!-- Security roles referenced by this web application --> <security-role> <description> role required to log in to the Application</description> <role-name>All</role-name> </security-role> </web-app>
3.1.2. Elytron サブシステムの更新
http-authentication-factoryにFORM認証のメカニズムを追加します。Kerberos ベースの認証向けに設定した既存の
http-authentication-factoryと、FORM認証の追加のメカニズムを使用できます。/subsystem=elytron/http-authentication-factory=example-krb-http-auth:list-add(name=mechanism-configurations, value={mechanism-name=FORM})フォールバックプリンシパルを追加します。
Kerberos ベースの認証向けの既存の設定には、プリンシパルを Kerberos トークンからアプリケーションのロールへマッピングするために設定されたセキュリティーレルムがすでに含まれているはずです。フォールバック認証向けの追加ユーザーをそのレルムに追加できます。たとえば、
filesystem-realmを使用する場合、適切なロールを持つ新規ユーザーを作成できます。重要filesystem-realmはテクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジプレビュー機能のサポート範囲」を参照してください。
/subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity(identity=fallbackUser1) /subsystem=elytron/filesystem-realm=exampleFsRealm:set-password(identity=fallbackUser1, clear={password="password123"}) /subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity-attribute(identity=fallbackUser1, name=Roles, value=["Admin","Guest"])
3.1.3. レガシー Security サブシステムの更新
JBoss EAP でレガシー security サウシステムを使用している場合は、フォールバック認証のセキュリティードメインを更新する必要があります。
web アプリケーションセキュリティードメインを設定して、フォールバックログインメカニズムをサポートする必要があります。これには以下の手順が必要になります。
- フォールバック認証メソッドとして対応する新しいセキュリティードメインを追加します。
-
usernamePasswordDomainモジュールオプションを、フォールバックドメインを示す web アプリケーションセキュリティードメインに追加します。
例: フォールバックセキュリティードメインで設定されたセキュリティードメイン
/subsystem=security/security-domain=app-fallback:add(cache-type=default)
/subsystem=security/security-domain=app-fallback/authentication=classic:add()
/subsystem=security/security-domain=app-fallback/authentication=classic/login-module=UsersRoles:add(code=UsersRoles, flag=required, module-options=[usersProperties="file:${jboss.server.config.dir}/fallback-users.properties", rolesProperties="file:${jboss.server.config.dir}/fallback-roles.properties"])
/subsystem=security/security-domain=app-spnego/authentication=classic/login-module=SPNEGO:add(code=SPNEGO, flag=required, module-options=[serverSecurityDomain=host])
/subsystem=security/security-domain=app-spnego/authentication=classic/login-module=SPNEGO:map-put(name=module-options, key=usernamePasswordDomain, value=app-fallback)
/subsystem=security/security-domain=app-spnego/authentication=classic/login-module=SPNEGO:map-put(name=module-options, key=password-stacking, value=useFirstPass)
reload
3.2. Kerberos での管理インターフェースのセキュア化
JBoss EAP はセキュリティードメインで Kerberos 認証を提供する他に、Kerberos を使用して管理インターフェースをセキュアにする機能も提供します。
3.2.1. Elytron を使用した Kerberos での管理インターフェースのセキュア化
HTTP 管理インターフェースに Kerberos 認証を設定するには、以下を行います。
アプリケーションに Kerberos 認証を設定する手順 にしたがって、Kerberos 認証を行う
http-authentication-factoryを作成します。重要管理インターフェースに Kerberos 認証を設定するとき、JBoss EAP が KDC に対して認証行うために設定したサービスプリンシパルに注意することが大変重要になります。このサービスプリンシパルは
service-name/hostnameの形式を取ります。JBoss EAP は、web ベースの管理コンソールに対して認証を行うときはHTTP/localhostのようにHTTPがサービス名になることを想定し、管理 CLI の場合はremote/localhostのようにremoteがサービス名になること想定します。http-authentication-factoryを使用するよう、管理 HTTP インターフェースを更新します。/core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-krb-http-auth)
管理 CLI で SASL 認証に対する Kerberos 認証を設定するには、以下を行います。
-
アプリケーションに Kerberos 認証を設定する手順 にしたがって、セキュリティードメインおよび
kerberos-security-factoryを作成します。 GSSAPIをconfigurable-sasl-server-factoryに追加します。/subsystem=elytron/configurable-sasl-server-factory=configured:list-add(name=filters, value={pattern-filter=GSSAPI})セキュリティードメインおよび
kerberos-security-factoryを使用するsasl-authentication-factoryを作成します。例:
sasl-authentication-factory/subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured, security-domain=exampleFsSD, mechanism-configurations=[{mechanism-name=GSSAPI, mechanism-realm-configurations=[{realm-name=exampleFsSD}], credential-security-factory=krbSF}])sasl-authentication-factoryを使用するよう、管理 SASL インターフェースを更新します。例:
sasl-authentication-factoryの更新/core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) reload
3.2.2. レガシーのコア管理認証を使用した Kerberos での管理インターフェースのセキュア化
レガシーのコア管理認証を使用して管理インターフェースでの Kerberos 認証を有効にするには、以下の手順を実行する必要があります。
ここで使用する管理 CLI コマンドは、JBoss EAP スタンドアロンサーバーを実行していることを仮定しています。JBoss EAP 管理対象ドメインの管理 CLI を使用する場合の詳細は Management CLI Guide を参照してください。
関連するシステムプロパティーを有効にします。
前の項 で説明したとおり、Kerberos サーバーへの接続に必要な JBoss EAP システムプロパティーを有効にします。
Kerberos サーバーアイデンティティーをセキュリティーレルムに追加します。
Kerberos 認証をセキュリティーレルムで使用できるようにするには、Kerberos サーバーへの接続を追加する必要があります。以下の例は、Kerberos サーバーアイデンティティーを既存の管理レルムに追加する方法を表しています。
service-name、hostname、およびMY-REALMは適切な値に置き換える必要があります。サーバーアイデンティティーをセキュリティーレルムに追加する CLI の例
/core-service=management/security-realm=ManagementRealm/server-identity=kerberos:add() /core-service=management/security-realm=ManagementRealm/server-identity=kerberos/keytab=service-name\/hostname@MY-REALM:add(path=/home\/username\/service.keytab, debug=true) reload
重要管理インターフェースに Kerberos 認証を設定するとき、JBoss EAP が KDC に対して認証行うために設定したサービスプリンシパルに注意することが大変重要になります。このサービスプリンシパルは
service-name/hostnameの形式を取ります。JBoss EAP は、web ベースの管理コンソールに対して認証を行うときはHTTP/localhostのようにHTTPがサービス名になることを想定し、管理 CLI の場合はremote/localhostのようにremoteがサービス名になること想定します。セキュリティーレルムで認証方法を更新します。
Kerberos サーバーアイデンティティーが適切に設定された後、使用するためにはセキュリティーレルム認証メソッドを更新する必要があります。
例: Kerberos 認証のセキュリティーレルムへの追加
/core-service=management/security-realm=ManagementRealm/authentication=kerberos:add() reload
重要管理インターフェースにアクセスするとき、JBoss EAP はセキュリティーレルムで定義された認証メカニズムの順番を基に、その順番でユーザーを認証しようとします。
両方のインターフェースを Kerberos でセキュアにします。
web ベースの管理コンソールと管理 CLI の両方をセキュアする場合、 Kerberos サーバーアイデンティティーを両方に設定する必要があります。アイデンティティーを追加するには、以下のコマンドを使用します。
/core-service=management/security-realm=ManagementRealm/server-identity=kerberos/keytab=remote\/hostname@MY-REALM:add(path=/home\/username\/remote.keytab, debug=true) reload
3.2.3. 管理インターフェースへの接続
管理インターフェースに接続する前に、有効な Kerberos チケットが必要になります。レガシーのセキュリティーソリューションを使用して、セキュリティーレルムが Kerberos によるユーザーの認証に失敗すると、<authentication> 要素に指定されたその他の方法を使用してユーザーの認証を試みます。elytron サブシステムはレガシーのセキュリティーソリューションと同様に動作します。Kerberos 認証メカニズムに失敗すると、認証は管理インターフェースを保護する認証ファクトリーに定義したその他のメカニズムにフォールバックします。通常、 DIGEST または BASIC がフォールバックとして使用されます。
ブラウザーを使用して web ベースの管理コンソールに接続する場合、セキュリティーレルムはそのチケットを基にユーザーを認証しようとします。
管理 CLI に接続する場合、GSSAPI 実装がオペレーティングシステムのレベルで管理されたアイデンティティーを利用できるようにするため、 -Djavax.security.auth.useSubjectCredsOnly=false パラメーターを使用する必要があります。環境のセットアップを基にして以下のパラメーターを使用する必要もあります。
- -Djava.security.krb5.realm=REALM_NAME
- レルム名を指定します。
- -Djava.security.krb5.kdc=KDC_HOSTNAME
- KDC の場所を指定します。
- --no-local-auth
- ローカル認証を無効にします。これは、スクリプトを実行している同じマシン上で JBoss EAP インスタンスへの接続を試みる場合に便利です。
コマンド例
$ EAP_HOME/bin/jboss-cli.sh -c -Djavax.security.auth.useSubjectCredsOnly=false --no-local-auth
クライアントとサーバー間で HTTP プロキシーが使用される場合、別の認証されたクライアントと同じサーバー間で認証された接続を共有しないように注意する必要があります。これを怠った場合、サーバーはセキュリティーコンテキストの関連を簡単に認識できないようになります。クライアントとサーバー間における認証の整合性を適切に維持しているプロキシーは、プロキシーからの HTTP 応答で Proxy-support: Session- Based-Authentication HTTP ヘッダーをクライアントに提供します。プロキシーがこのヘッダーとサーバーからの 401 Unauthorized 応答を提供する場合を除き、クライアントはプロキシーを介して SPNEGO HTTP 認証メカニズムを利用してはなりません。
3.3. リモーティングの Kerberos 認証統合
Kerberos を使用して管理インターフェースと web アプリケーションをセキュアにする他に、EJB などのリモーティングでアクセスされるサービスに対して Kerberos 認証を設定することもできます。
Kerberos のシステムプロパティーを設定する必要もあります。詳細は「Elytron サブシステムの設定」を参照してください。
3.3.1. レガシーセキュリティーレルムを使用した Kerberos 認証の統合
Kerberos 認証を設定するには、以下を行う必要があります。
リモーティングおよび
RealmDirectでのセキュリティードメインの設定リモーティングによってアクセスされるサービスが使用するセキュリティードメインを設定する必要があります。このセキュリティードメインは、
RealmDirectやRealmUsersRolesなどのRemotingログインモジュールとRealmDirectログインモジュールの両方を利用する必要があります。本質的には、デフォルトで提供されるotherセキュリティードメインと大変似ています。各ログインモジュールの設定オプションの詳細は、JBoss EAP『Login Module Reference』を参照してください。例: Remoting および RealmDirect ログインモジュールが指定されたセキュリティードメイン
/subsystem=security/security-domain=krb-remoting-domain:add() /subsystem=security/security-domain=krb-remoting-domain/authentication=classic:add() /subsystem=security/security-domain=krb-remoting-domain/authentication=classic/login-module=Remoting:add(code=Remoting, flag=optional, module-options=[password-stacking=useFirstPass]) /subsystem=security/security-domain=krb-remoting-domain/authentication=classic/login-module=RealmDirect:add(code=RealmDirect, flag=required, module-options=[password-stacking=useFirstPass, realm=krbRealm]) /subsystem=security/security-domain=krb-remoting-domain/mapping=classic:add() /subsystem=security/security-domain=krb-remoting-domain/mapping=classic/mapping-module=SimpleRoles:add(code=SimpleRoles, type=role, module-options=["testUser"="testRole"]) reload
Kerberos 認証のセキュリティーレルムを設定します。
Kerberos 認証によるセキュリティーレルムのセットアップについては、「Kerberos での管理インターフェースのセキュア化」を参照してください。
例: セキュリティーレルム
/core-service=management/security-realm=krbRealm:add() /core-service=management/security-realm=krbRealm/server-identity=kerberos:add() /core-service=management/security-realm=krbRealm/server-identity=kerberos/keytab=remote\/localhost@JBOSS.ORG:add(path=\/path\/to\/remote.keytab, debug=true) /core-service=management/security-realm=krbRealm/authentication=kerberos:add(remove-realm=true) reload
remotingサブシステムに HTTP コネクターを設定します。さらに、新規作成されたセキュリティーレルムを使用するために
remotingサブシステムで HTTP コネクターを設定する必要があります。例: remoting サブシステム
/subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=security-realm, value=krbRealm)
サービスのセキュリティーを設定します。
securedへのリモーティングインターフェースを使用してアクセスされるサービスを設定する必要もあります。この設定はサービスによって異なります。たとえば、EJB の場合、@SecurityDomainおよび@RolesAllowedアノテーションを使用できます。
3.3.2. Elytron を使用した Kerberos 認証の統合
Kerberos または GSSAPI SASL 認証の Elytron セキュリティードメインをリモーティング認証に対して定義できます。
アイデンティティーのロード元となるセキュリティーレルムを定義します。これは、ロールの割り当てに使用されます。
/path=kerberos:add(relative-to=user.home, path=src/kerberos) /subsystem=elytron/properties-realm=kerberos-properties:add(users-properties={path=kerberos-users.properties, relative-to=kerberos, digest-realm-name=ELYTRON.ORG}, groups-properties={path=kerberos-groups.properties, relative-to=kerberos})サーバーのアイデンティティーの Kerberos セキュリティーファクトリーを定義します。
/subsystem=elytron/kerberos-security-factory=test-server:add(relative-to=kerberos, path=remote-test-server.keytab, principal=remote/test-server.elytron.org@ELYTRON.ORG)
セキュリティードメインと SASL 認証ファクトリーを定義します。
/subsystem=elytron/security-domain=KerberosDomain:add(default-realm=kerberos-properties, realms=[{realm=kerberos-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper) /subsystem=elytron/sasl-authentication-factory=gssapi-authentication-factory:add(security-domain=KerberosDomain, sasl-server-factory=elytron, mechanism-configurations=[{mechanism-name=GSSAPI, credential-security-factory=test-server}])作成した
sasl-authentication-factoryをremotingサブシステムで使用し、リモーティングで有効にします。CLI コマンドの例
/subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory, value=gssapi-authentication-factory)
サービスのセキュリティーを設定します。
EJB でセキュリティードメインを参照する場合は、Elytron セキュリティードメインにマップする
application-security-domainを指定する必要があります。たとえば EJB の場合では、@SecurityDomainアノテーションを使用できます。CLI コマンドの例
/subsystem=ejb3/application-security-domain=KerberosDomain:add(security-domain=KerberosDomain)
新しい JBoss EAP 7.1 EJB クライアントでは、アイデンティティーアソシエーションへの JAAS Subject の使用はサポート対象外となりました。EJB 呼び出しの Kerberos アイデンティティーをプログラミングで管理するクライアントは、以下のように AuthenticationConfiguration API を直接使用するよう移行する必要があります。
// create your authentication configuration
AuthenticationConfiguration configuration = AuthenticationConfiguration.empty()
.useProvidersFromClassLoader(SecuredGSSCredentialClient.class.getClassLoader())
.useGSSCredential(getGSSCredential());
// create your authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL, configuration);
// create a callable that looks up an EJB and invokes a method on it
Callable<Void> callable = () -> {
...
};
// use your authentication context to run your callable
context.runCallable(callable);
AuthenticationConfiguration の作成時に useGSSCredential(getGSSCredential()) への呼び出しが発生します。JAAS Subject へすでにアクセス済みのクライアントコードは、以下のように GSSCredential を取得するよう簡単に変換できます。
private GSSCredential getGSSCredential() {
return Subject.doAs(subject, new PrivilegedAction<GSSCredential>() {
public GSSCredential run() {
try {
GSSManager gssManager = GSSManager.getInstance();
return gssManager.createCredential(GSSCredential.INITIATE_ONLY);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
});
}
Revised on 2018-05-20 21:57:14 EDT
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.