Chapter 3. Additional Features


3.1. Adding a FORM Login as a Fallback

JBoss EAP 6 and applications deployed to it can also configure a FORM login authentication mechanism to use as a fallback. This allows applications to present a login page for authentication in cases where a Keberos/SPNEGO tokens are not present. This authentication happens independent of the Kerberos authentication. As a result, depending on how the FORM login fallback is configured, users may require separate credentials to authenticate via this method.

The following steps are required to configure FORM login as a fallback:

Note

The fallback to FORM logic is available in the case when no SPNEGO (or NTLM) tokens are present or SPNEGO token is present but from another KDC.

3.1.1. 1. Configure Red Hat JBoss Enterprise Application Platform 6 and the Web Application to Use Kerberos and SPNEGO

Please refer to the previous section for the steps required to configure JBoss EAP 6 and web applications to use Kerberos and SPNEGO for authentication and authorization. ⁠

3.1.2. 2. Update the Security Domain for Fallback Authentication

The web application security domain must be configured to support a fallback login mechanism. This requires the following steps:

  • Add a new security domain to server as a fallback authentication method.
  • Add a usernamePasswordDomain module option to the web application security domain that points to the fallback domain.

Example Security Domain Configured with a Fallback Security Domain

<security-domain name="app-spnego" cache-type="default">
  <authentication>
    <login-module code="SPNEGO" flag="requisite">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="serverSecurityDomain" value="host"/>
      <module-option name="usernamePasswordDomain" value="app-fallback"/>
    </login-module>
    <!--login module for mapping roles -->
    <login-module code="UsersRoles" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="usersProperties"
        value="file:${jboss.server.config.dir}/users.properties"/>
      <module-option name="rolesProperties"
        value="file:${jboss.server.config.dir}/roles.properties"/>
    </login-module>
  </authentication>
</security-domain>
<security-domain name="app-fallback" cache-type="default">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="usersProperties"
        value="file:${jboss.server.config.dir}/fallback-users.properties"/>
      <module-option name="rolesProperties"
        value="file:${jboss.server.config.dir}/fallback-roles.properties"/>
    </login-module>
  </authentication>
</security-domain>

3.1.3. 3. Add the Login and Error Pages

To use FORM login, a login and error page are required. These files are added to web application and are used in the authentication process.

Example login.jsp file:

<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>

Example error.jsp file:

<html>
<head></head>
<body>
  <p>Login failed, please go back and try again.</p>
</body>
</html>

3.1.4. 4. Modify the web.xml

After adding the login and error pages to the web application, the web.xml must be updated to use these files for FORM login. A <form-login-config> element is added to <login-config> and the paths to the the login and error pages are specified as <form-login-page> and <form-error-page> elements.

Example updated web.xml file:

<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</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.2. Securing the Management Interfaces with Kerberos

In addition to providing Kerberos authentication in security domains, JBoss EAP 6 also provides the ability to secure the management interfaces using Kerberos. To enable Kerberos authentication on the management interfaces, the following steps must be performed:

Note

The CLI commands shown below were done assuming a standalone instance of JBoss EAP 6. For more details on using the CLI with JBoss EAP 6 domains, please consult The Management CLI section of the Red Hat JBoss Enterprise Application Platform 6 Administration and Configuration Guide.

3.2.1. 1. Enable Relavant System Properties

As discussed in a previous section, enable any needed JBoss EAP 6 system properties for connecting to the Kerberos server.

3.2.2. 2. Adding the Kerberos Server Identity to the Security Realm

Before Kerberos authentication can be used in a security realm, a connection to a Kerberos server must be added. The following example shows how to add a Kerberos server identity to the existing Management Realm.

Example CLI for Adding a Server Identity to a Security Realm

/core-service=management/security-realm=ManagementRealm/server-identity=kerberos:add

/core-service=management/security-realm=ManagementRealm/server-identity=kerberos/ \
keytab=host\/testserver@MY_REALM:add( \
path=/home\/username\/service.keytab, \
debug=true)
reload

Resulting XML

<security-realm name="ManagementRealm">
    <server-identities>
        <kerberos>
            <keytab principal="host/testserver@MY_REALM"
                    path="/home/username/service.keytab"
                    debug="true"/>
        </kerberos>
    </server-identities>
    ...
</security-realm>

3.2.3. 3. Updating Authentication Method in the Security Realm

Once the Kerberos server identity has been properly configured, the authentication method in the security realm needs to be updated to use it.

Example CLI for Adding Kerberos Authentication to a Security Realm

/core-service=management/security-realm=ManagementRealm/authentication=kerberos:add

reload

Resulting XML

<security-realm name="ManagementRealm">
    <server-identities>
        <kerberos>
            <keytab principal="host/testserver@MY_REALM"
                    path="/home/username/service.keytab"
                    debug="true"/>
        </kerberos>
    </server-identities>
    <authentication>
        <local default-user="$local" skip-group-loading="true"/>
        <kerberos/>
        <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
    ...
</security-realm>

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.