Chapter 7. Platform-specific Configuration

Configuration relating specifically to the technology and features of Red Hat JBoss Portal is required before JBoss Portal can be used in a production environment. The following tasks detail the extra configuration required to prepare JBoss Portal for a production environments.

7.1. Configure the Portal Root Password

For security reasons, Red Hat JBoss Portal (JBoss Portal) does not ship with default user accounts. It is necessary to configure a password for the portal root user. This user is created for first-run access to the portal in order to configure an Administrator user account.

Procedure 7.1. Setting the Root Password Through the Command-line

  1. Open a terminal and execute the portal-setup.sh script.
    • For Linux, $JPP_HOME/bin/portal-setup.sh
    • For Microsoft Windows, %JPP_HOME%\bin\portal-setup.bat
  2. Type a value for the root password when prompted and press Enter. Re-type the password and press Enter.
    The password is encrypted and stored in the $JPP_HOME/standalone/configuration/gatein/configuration.properties file.
  3. Start JBoss Portal.
  4. Open the Users Management interface and create the required accounts, including an Administrator account.

Procedure 7.2. Setting the Root Password Through the Web Interface

If JBoss Portal detects there is no Root password configured, the user is redirected to a Set Root Password page.

Important

The portal-setup scripts are for single use only. After initially running the script, the password in configuration.properties has no effect.
The password generated by the script can be removed after configuring accounts in the Users Management interface.
  1. Once all configuration in this user guide has been completed, start JBoss Portal.
  2. Open JBoss Portal in a browser.
  3. In the Set Root Password page, type a Root password in the Password field, and repeat the same password in the Repeat password field.
  4. Click Setup to set the Root password.
    To modify the Root password on subsequent occasions, use the portal administration interface for Users Management.

7.2. About JBoss Portal Domain Mode

Red Hat JBoss Portal (JBoss Portal) supports standalone mode as its primary operation mode. JBoss Portal can be configured to operate in domain mode, however there are some caveats which are important to understand when considering running JBoss Portal in a managed domain.
JBoss Portal domain configuration guidance and examples are described in detail in the Domain Mode part of the JBoss Portal Administration and Configuration Guide. Read this information before deciding how to configure JBoss Portal's primary operation mode.
A general introduction to domain mode is provided in the About JBoss EAP 6 Operating Modes chapter in the Red Hat JBoss Enterprise Application Platform (JBoss EAP) Administration and Configuration Guide.

7.3. Provision JCR and IDM Databases

JCR and IDM services are configured to use a container-provided datasource, configured through Red Hat JBoss Enterprise Application Platform 6 configuration.
See the Datasource Management chapter in the Red Hat JBoss Enterprise Application Platform 6 Administration and Configuration Guide for detailed information about managing and configuring datasources for use with JBoss Portal. This chapter includes direct examples for datasource connectors
Datasource configuration is located in JPP_DIST/standalone/configuration/standalone.xml and for clustered configuration in the standalone-ha.xml file.

Procedure 7.3. Configuring the Java Content Repository (JCR)

  1. Open JPP_DIST/standalone/configuration/standalone.xml in edit mode.
  2. Bind the JCR datasource to JNDI under java:/jdbcjcr_portal.
    <datasource jndi-name="java:/jdbcjcr_portal" pool-name="JCRPortalDS" enabled="true" use-java-context="true">
    
        <connection-url>jdbc:h2:file:${jboss.server.data.dir}/gatein/portal/jdbcjcr_portal;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
    
        <security>
            <user-name>sa</user-name>
            <password>sa</password>
        </security>
    
    </datasource>
  3. If additional portals are deployed, additional datasources must be configured and bound in JNDI using a separate java:/jdbcjcr_PORTAL-NAME directive.
    Ensure the user has rights to create tables on jdbcjcr_portal, and to update them as they will automatically be created during the first startup.

Procedure 7.4. Configuring Identity Management (IDM)

  1. Open JPP_DIST/standalone/configuration/standalone.xml in edit mode.
  2. Bind the IDM datasource to JNDI under java:/jdbcidm_portal.
    <datasource jndi-name="java:/jdbcidm_portal" pool-name="JCRPortalDS" enabled="true" use-java-context="true">
    
        <connection-url>jdbc:h2:file:${jboss.server.data.dir}/gatein/portal/jdbcjcr_portal;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
    
        <security>
            <user-name>sa</user-name>
            <password>sa</password>
        </security>
    
    </datasource>
  3. If additional portals are deployed, additional datasources must be configured and bound in JNDI using a separate java:/jdbcjcr_PORTAL-NAME directive.
    Ensure the user has rights to create tables on jdbcjcr_portal, and to update them as they will automatically be created during the first startup.

7.4. JTA Support Configuration

7.4.1. JTA Support

Red Hat JBoss Portal uses separate Java Content Repository (JCR) and Identity Management (IDM) databases to store identity information, and portal content. If your provisioned databases are compatible, it may be advantageous to configure the Java Transaction API (JTA) to provide a distributed transaction system across the application server, the resource manager, and the transactional applications.
With JTA configured, each HTTP request to the portal is encapsulated inside a JTA transaction. The advantage of this approach is access to IDM and JCR datasources and other portal resources are managed in one request rather than multiple requests. This approach also allows local resources to participate in global transactions.

7.4.2. JDBC Driver Download Locations

The following table gives the standard download locations for JDBC drivers of common databases used with JBoss EAP 6. These links point to third-party websites which are not controlled or actively monitored by Red Hat. For the most up-to-date drivers for your database, check your database vendor's documentation and website.

7.4.3. Install a JDBC Driver as a Core Module

Prerequisites
Before performing this task, you need to meet the following prerequisites:

Procedure 7.5. Install a JDBC Driver as a Core Module

  1. Create a file path structure under the JPP_HOME/modules/system/layers/base directory. For example, for a MySQL JDBC driver, create JPP_HOME/modules/system/layers/base/com/mysql/main/.
  2. Copy the JDBC driver JAR into the main/ subdirectory.
  3. In the main/ subdirectory, create a module.xml file. The following is an example of a module.xml file:
    <?xml version="1.0" encoding="UTF-8"?>
    <module xmlns="urn:jboss:module:1.0" name="com.mysql">
      <resources>
        <resource-root path="mysql-connector-java-5.1.15.jar"/>
      </resources>
      <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
      </dependencies>
    </module>
  4. Start the Server.
  5. Start the Management CLI.
  6. Run the CLI command to add the JDBC driver module to the server configuration.
    The command you choose depends on the number of classes listed in the /META-INF/services/java.sql.Driver file located in the JDBC driver JAR. For example, the /META-INF/services/java.sql.Driver file in the MySQL 5.1.20 JDBC JAR lists two classes:
    • com.mysql.jdbc.Driver
    • com.mysql.fabric.jdbc.FabricMySQLDriver
    When there is more than one entry, you must also specify the name of the driver class. Failure to do so results in an error similar to the following:

    Example 7.1. Driver class error

    JBAS014749: Operation handler failed: Service jboss.jdbc-driver.mysql is already registered

    Note

    The value for DRIVER_NAME depends on the number of classes listed in the /META-INF/services/java.sql.Driver file located in the JDBC driver JAR. If there is only one class, the value is the name of the JAR. If there are multiple classes, the value is the name of the JAR + driverClassName + "_" + majorVersion +"_" + minorVersion. Failure to do so will result in the following error being logged:
    JBAS014775:    New missing/unsatisfied dependencies
    For example, the DRIVER_NAME value required for the MySQL 5.1.31 driver, is mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1.
    • Run the CLI command for JDBC JARs containing one class entry.
      /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)

      Example 7.2. CLI Command for Standalone Mode for JDBC JARs with one driver class

      /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)

      Example 7.3. CLI Command for Domain Mode for JDBC JARs with one driver class

      /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
    • Run the CLI command for JDBC JARs containing multiple class entries.
      /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-class-name=DRIVER_CLASS_NAME)

      Example 7.4. CLI Command for Standalone Mode for JDBC JARs with multiple driver class entries

      /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)

      Example 7.5. CLI Command for Domain Mode for JDBC JARs with multiple driver class entries

      /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)
Result
The JDBC driver is now installed and set up as a core module, and is available to be referenced by application datasources.

7.4.4. Configure Datasources for JTA Support

You can choose to configure the IDM and JCR databases to share the same datasource, or for those databases that support transactions with two-phase commits, create two separate XA datasources.

Procedure 7.6. Shared Datasource Configuration

This procedure describes how to set up the JCR and IDM datasources as a no-XA combined datasource. no-XA datasources are widely supported by most database vendors, which makes this configuration a good choice for small-scale testing requirements.
The JCR and IDM databases do not support two-phase commit because they are no-XA databases. JTA allows for one datasource of this type within one JTA transaction, and the datasources are handled as a Last Resource in a JTA transaction.
Configuring the IDM and JCR datasources in this way means that portlet applications can not use a different no-XA datasource, because they must access the JCR and IDM no-XA datasources of the portal. This approach is therefore not recommended for production environments due to scalability issues.
  1. Open JPP_HOME/standalone/configuration/standalone.xml.
  2. Comment the jdbcjcr_portal <datasource> directive to disable the JCR datasource.
    <datasources>
      <!--<datasource jndi-name="java:/jdbcjcr_portal" pool-name="JCRPortalDS" enabled="true" use-java-context="true">
      <connection-url>jdbc:h2:file:${jboss.server.data.dir}/gatein/portal/jdbcjcr_portal;DB_CLOSE_DELAY=-1</connection-url>
      <driver>h2</driver>
      <security>
        <user-name>sa</user-name>
        <password>sa</password>
      </security>
      </datasource>-->
    </datasources>
  3. Configure jdbcidm_portal <datasource> directive to use the MySQL database.
    <datasources>
      <!--<datasource jndi-name="java:/jdbcjcr_portal" pool-name="JCRPortalDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:h2:file:${jboss.server.data.dir}/gatein/portal/jdbcjcr_portal;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <security>
          <user-name>sa</user-name>
          <password>sa</password>
        </security>
      </datasource>-->
      <datasource jndi-name="java:/jdbcidm_portal" pool-name="IDMPortalDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:mysql://localhost/portal</connection-url>
        <driver>mysql</driver>
        <security>
          <user-name>portal</user-name>
          <password>portal</password>
        </security>
        <pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>100</max-pool-size>
          <prefill>true</prefill>
        </pool>
      </datasource>
    </datasources>
  4. Add the MySQL module into the list of <drivers>.
    <datasources>
      <!--<datasource jndi-name="java:/jdbcjcr_portal" pool-name="JCRPortalDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:h2:file:${jboss.server.data.dir}/gatein/portal/jdbcjcr_portal;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <security>
          <user-name>sa</user-name>
          <password>sa</password>
        </security>
      </datasource>-->
      <datasource jndi-name="java:/jdbcidm_portal" pool-name="IDMPortalDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:mysql://localhost/portal</connection-url>
        <driver>mysql</driver>
        <security>
          <user-name>portal</user-name>
          <password>portal</password>
        </security>
        <pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>100</max-pool-size>
          <prefill>true</prefill>
        </pool>
      </datasource>
      <drivers>
        <driver name="mysql" module="com.mysql">
          <xa-datasource-class>com.mysql.jdbc.Driver</xa-datasource-class>
        </driver>
      </drivers>
    </datasources>
  5. Open JPP_HOME/standalone/configuration/gatein/configuration.properties, and verify the gatein.jcr.datasource.name property has the value java:/jdbcidm. This value ensures the JCR database uses the IDM database as the datasource.
    gatein.jcr.datasource.name=java:/jdbcidm
    gatein.idm.datasource.name=java:/jdbcidm
    			

Procedure 7.7. XA Datasource Configuration

This procedure describes how to configure separate transactional JCR and IDM databases. Unlike no-XA databases, it is not necessary to share the same datasource to ensure commit integrity: JTA handles datasource synchronization using two-phase commit logic.

Important

In most cases, a separate datasource is required for the JCR and IDM database, running on separate processes (separate hosts). Some databases such as Sybase and Oracle support shared datasources using the same process. Verify the database used for the production installation supports shared XA datasources.
If both datasources use the same database, an issue with enlisting two XA resources for the same database and transaction will most likely occur and cause transactions to fail.
Customers that are restricted to using shared datasources on a supported database are recommended to use XA datasources instead of no-XA datasources. It is strongly recommended to implement a datasource solution on two separate hosts to take advantage of XA Datasource performance and remove the LRCO limitation.
  1. Open JPP_HOME/standalone/configuration/standalone.xml.
  2. Configure jdbcidm_portal <xa-datasource> directive to use the MySQL database.
    <datasources>
      <xa-datasource jndi-name="java:/jdbcidm_portal" pool-name="IDMPortalDS" enabled="true" use-java-context="true">
        <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
        <xa-datasource-property name="DatabaseName">portalidm</xa-datasource-property>
        <driver>mysql</driver>
        <xa-pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>100</max-pool-size>
          <prefill>true</prefill>
        </xa-pool>
        <security>
          <user-name>portal</user-name>
          <password>portal</password>
        </security>
      </xa-datasource>
    </datasources>
  3. Configure jdbcjcr_portal <xa-datasource> directive to use the MySQL database.
    <datasources>
      <xa-datasource jndi-name="java:/jdbcidm_portal" pool-name="IDMPortalDS" enabled="true" use-java-context="true">
        <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
        <xa-datasource-property name="DatabaseName">portalidm</xa-datasource-property>
        <driver>mysql</driver>
        <xa-pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>100</max-pool-size>
          <prefill>true</prefill>
        </xa-pool>
        <security>
          <user-name>portal</user-name>
          <password>portal</password>
        </security>
      </xa-datasource>
      <xa-datasource jndi-name="java:/jdbcjcr_portal" pool-name="JCRPortalDS" enabled="true" use-java-context="true">
        <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
        <xa-datasource-property name="DatabaseName">portaljcr</xa-datasource-property>
        <driver>mysql</driver>
        <xa-pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>100</max-pool-size>
          <prefill>true</prefill>
        </xa-pool>
        <security>
          <user-name>portal</user-name>
          <password>portal</password>
        </security>
      </xa-datasource>
    </datasources>
  4. Add the MySQL module into the list of <drivers>.
    <datasources>
      <xa-datasource jndi-name="java:/jdbcidm_portal" pool-name="IDMPortalDS" enabled="true" use-java-context="true">
        <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
        <xa-datasource-property name="DatabaseName">portalidm</xa-datasource-property>
        <driver>mysql</driver>
        <xa-pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>100</max-pool-size>
          <prefill>true</prefill>
        </xa-pool>
        <security>
          <user-name>portal</user-name>
          <password>portal</password>
        </security>
      </xa-datasource>
      <xa-datasource jndi-name="java:/jdbcjcr_portal" pool-name="JCRPortalDS" enabled="true" use-java-context="true">
        <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
        <xa-datasource-property name="DatabaseName">portaljcr</xa-datasource-property>
        <driver>mysql</driver>
        <xa-pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>100</max-pool-size>
          <prefill>true</prefill>
        </xa-pool>
        <security>
          <user-name>portal</user-name>
          <password>portal</password>
        </security>
      </xa-datasource>
      <drivers>
        <driver name="mysql" module="com.mysql">
          <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
      </driver>
      </drivers>
    </datasources>
  5. Open JPP_HOME/standalone/configuration/gatein/configuration.properties, and verify the gatein.jcr.datasource.name property has the value java:/jdbcidm. This value ensures the JCR database uses the IDM database as the datasource.
    gatein.jcr.datasource.name=java:/jdbcjcr
    gatein.idm.datasource.name=java:/jdbcidm
    			

7.4.5. Configure Hibernate and Picketlink

Hibernate and PicketLink require some configuration changes to support JTA.

Procedure 7.8. Configuring Hibernate and Picketlink for JTA

  1. Open JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/idm-configuration.xml
  2. In the hibernate.properties <init-params> group, comment the Non-JTA Setup directives, and uncomment the JTA Setup directives:
    <init-params>
      <properties-param>
        <name>hibernate.properties</name>
        <description>Default Hibernate Service</description>
        <property name="hibernate.hbm2ddl.auto" value="update"/>
        <property name="hibernate.show_sql" value="false"/>
        <property name="hibernate.connection.datasource" value="${gatein.idm.datasource.name}${container.name.suffix}"/>
        <property name="hibernate.connection.autocommit" value="false"/>
        <!--  Non-JTA setup  -->
        <!--<property name="hibernate.current_session_context_class" value="thread"/>-->
        <!--  JTA setup  -->
        <property name="hibernate.current_session_context_class" value="jta"/>
        <property name="hibernate.transaction.factory_class" value="org.hibernate.transaction.JTATransactionFactory" />
        <property name="hibernate.transaction.jta.platform" value="org.exoplatform.services.organization.idm.UserTransactionJtaPlatform" />
    
    <!-- Remaining code removed for readability-->
    
    
  3. In the org.exoplatform.services.organization.idm.Config <init-params> group, change useJTA <field> value to true.
    <field name="useJTA">
      <boolean>true</boolean>
    </field>
    This setting forces PicketlinkIDMOrganizationServiceImpl to encapsulate each HTTP request within the JTA transaction, instead of the Hibernate transaction API. The bounds of the transaction are startRequest and endRequest.

    Important

    If managed transactions are used in portlet applications (for example, using EJB with Container-Managed transactions), be aware that some changes to transaction behavior may occur in the application.
    Ensure that portlet applications do not attempt to start or commit JTA transactions from the application.
  4. Open JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/picketlink-idm/picketlink-idm-config.xml
  5. In the <stores> directives, change the lazyStartOfHibernateTransaction option to false to switch transaction management from PicketLink to JTA.

7.4.6. Last Resource Commit Optimization (LRCO)

The XA transaction protocol is designed to provide ACID properties by using a two-phase commit protocol. Sometimes it is necessary to allow a non-XA-aware resource manager to participate in a transaction. This is often the case with data stores that do not support distributed transactions.
In this situation, a technique known as Last Resource Commit Optimization (LRCO) is used. LRCO can also be referred to as the Last Resource Gambit. The one-phase-aware resource is processed last in the prepare phase of the transaction, at which time an attempt is made to commit it.
If the attempt is successful, the transaction log is written and the remaining resources go through the phase-two commit. If the last resource fails to commit, the transaction is rolled back. Although this protocol allows most transactions to complete normally, some errors can cause an inconsistent transaction outcome. For this reason, use LRCO as a last resort. When a single <datasource> is used in a transaction, the LRCO is automatically applied to it. In other situations, you can designate a last resource by using a special marker interface.
Using more than a single one-phase resource in the same transaction is not transactionally safe, and is not recommended. JBoss Transaction Service sees an attempt to enlist a second such resource as an error and terminates the transaction. Whenever possible, <datasource> must be converted to an <xa-datasource> to prevent any potential transaction issues.

7.5. Email Service Configuration

Red Hat JBoss Portal (JBoss Portal) includes an email service. The service can be used to send authentication information to users, and alert administrators to invalid authentication attempts. The service must be configured before use.

Procedure 7.9. Configuring the SMTP Email Service

The service is configured to support GMail by default. Google Accounts with two-factor authentication activated must generate an application-specific password for the email service through the Google Account Security Console.
  1. Open JPP_HOME/standalone/configuration/gatein/configuration.properties in edit mode.
  2. Specify the Google Account information as indicated in the file.
    # EMail
    gatein.email.smtp.username=[user@gmail.com]
    gatein.email.smtp.password=[password|app-specific password]
    gatein.email.smtp.host=smtp.gmail.com
    gatein.email.smtp.port=465
    gatein.email.smtp.starttls.enable=true
    gatein.email.smtp.auth=true
    gatein.email.smtp.socketFactory.port=465
    gatein.email.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory
  3. When provisioning the Email Service for a production environment, it is recommended to specify a corporate SMTP gateway and port for the smtp.host and smtp.port variables.
    If using a SMTP gateway over SSL, a certificate trust store containing the SMTP server public certificate is required. Depending on the key sizes, Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy files are required for the Java Runtime Environment (JRE).

7.6. Email Notifications Configuration

The email service can be configured to send notifications to a specified email address, typically to the portal administrators. Two types of notifications are available:
  • Notifications about new users, which are typically useful on portals that have a public registration page.
  • Notifications about invalid login attempts, which can help in identifying security attacks.
Notification emails are disabled by default. To enable the notifications, perform the following configuration procedures.

Procedure 7.10. Enabling Notifications about New User Registration

  1. Configure an SMTP account.
  2. Configure the following mandatory configuration items located in the PostRegistrationService part of the JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/admin/admin-configuration.xml configuration file.
    sendMailAfterRegistration
    Boolean value that specifies whether an email notification is sent for new user registrations.
    The default value is false. If set to true, email notifications are sent when users join.
    mailTo
    Specifies the email address to which notifications are sent.
  3. Configure optional parameters to customize the content of the notification emails:
    mailFrom
    Specifies the email address from which the notification email is sent.
    mailSubject
    Specifies the subject of the notification email.
    mailMessage
    Specifies the body of the notification email.
    The ${user.name}, ${user.firstName}, ${user.lastName} and ${user.email} macros can be used in the text to dynamically include the respective values in each notification email.
  4. Test the configuration by restarting the server and registering a new user in the JBoss Portal user interface. An email is sent to the specified email address, notifying the recipient that a user has been registered to the portal.

Procedure 7.11. Enabling Notifications about Invalid Login Attempts

  1. Configure an SMTP account.
  2. Configure the following mandatory configuration items located in the InvalidLoginAttemptsService part of the JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/admin/admin-configuration.xml configuration file.
    sendingMailsEnabled
    boolean value determining if e-mail notifications about invalid login attempts are enabled. It is false by default and needs to be changed to true for the e-mail notifications to be sent.
    mailTo
    Specifies the email address to which notifications are sent.
  3. Configure optional parameters to customize the content and policies associated with notification emails:
    mailFrom
    Specifies the email address from which the notification email is sent.
    mailSubject
    Specifies the subject of the notification email.
    mailMessage
    Specifies the body of the notification email.
    The ${user.name}, ${user.firstName}, ${user.lastName} and ${user.email} macros can be used in the text to dynamically include the respective values in each notification email.
    numberOfFailedAttempts
    Specifies the number of invalid login attempts after which an email notification is sent. The default value is 3.
    invalidLoginPolicy
    Specifies the policy used to determine that invalid login attempts are coming from same source. The available values are
    SESSION - the default, indicating that invalid login attempts must originate from the same HTTP session.
    SESSION_AND_USER - indicates that invalid login attempts must originate from the same HTTP session, and contain the same user name.
    SERVER - indicates that invalid login attempts must come from the same remote server.
  4. Test the configuration by restarting the server and attempting to login to JBoss Portal with invalid account credentials.
    Repeat the attempt for the number of times specified in the numberOfFailedAttempts parameter (the default is three attempts).
  5. An email is sent to the specified email address, notifying the recipient that an invalid login attempt has been detected.

7.7. Clustering Configuration

Before configuring a clustered environment in Red Hat JBoss Portal (JBoss Portal), read and understand the HTTP Clustering and Load Balancing chapter of the Red Hat JBoss Enterprise Application Platform Administration and Configuration Guide.
In summary, clustering can be configured one of two ways:
Using a single physical server
One physical server using two virtual IP addresses.
This configuration is used during basic clustering testing in a development environment, and can use the pre-configured Hypersonic (H2) database (which is not supported in production environments).
For assistance configuring virtual IP addresses, consult the Operating System documentation for guidance.
Using more than one physical server
This method uses two or more servers, each configured to use a JBoss Portal binary. For example, a "node1" directory available on server one and a "node2" directory available on server two.
This configuration is recommended for production environments. A supported databased documented in Tested Configurations is required for this configuration.

Configuring a Red Hat JBoss Portal Virtual Cluster for Basic Testing

Implement the following configuration to enable a cluster of JBoss Portal instances hosted on the same machine, bound to the virtual IPs 192.168.210.101 (for node1) and 192.168.210.102 (for node2).
All configuration required for basic clustering in JBoss Portal is included in standalone-ha.xml file. For this example, no modification is required to the file. For production environments, changes to this file are required and are documented in this guide.
  1. Configure two virtual IP addresses:
    1. 192.168.210.101, which is used for "node1" in this procedure.
    2. 192.168.210.102, which is used for "node2" in this procedure.
  2. Create two cluster nodes from the JBoss Portal binary:
    $ cp -r jboss-jpp-6.2/ node1 
    $ cp -r jboss-jpp-6.2/ node2
    
  3. Copy the Hypersonic database JAR into the JRE to act as the data store for the virtual servers.
    $ java -cp modules/system/layers/base/com/h2database/h2/main/h2-1.3.168.redhat-4.jar org.h2.tools.Server
    
  4. Start the servers from the node1 and node2 directories:
    From node1 directory.
    $ ./bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node1 -b 192.168.210.101 -u 239.23.42.2 -Djboss.bind.address.management=192.168.210.101
    From node2 directory.
    $ ./bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node2 -b 192.168.210.102 -u 239.23.42.2 -Djboss.bind.address.management=192.168.210.102
    Both nodes start, and can be accessed through their web interfaces:

7.8. Setting mod_jk for Cluster Configuration

Procedure 7.12. To setup the loadbalancer server which uses Apache HTTPD+Mod_jk:

  1. Install apache server and mod_jk module

    The package that contains Apache HTTP Server is known as httpd. To build and install mod_jk from source code use the package httpd-devel.
  2. Setup apache to use mod_jk

    Copy the file mod-jk.conf to /etc/httpd/conf.d and append the following line to /etc/httpd/conf/httpd.conf to load the module.
    LoadModule jk_module modules/mod_jk.so
    
    File mod-jk.conf is as follows:
    
    # Where to find workers.properties
    JkWorkersFile workers.properties
    
    # Where to put jk logs
    JkLogFile /var/log/apache2/mod_jk.log
     
    # Set the jk log level [debug/error/info]
    JkLogLevel debug
     
    # Select the log format
    JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
     
    # JkOptions indicates to send SSK KEY SIZE
    JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
     
    # JkRequestLogFormat
    #JkRequestLogFormat "%w %V %T"
     
    JkMountFile uriworkermap.properties
     
    # Add shared memory.
    # This directive is present with 1.2.10 and
    # later versions of mod_jk, and is needed for load balancing to work properly
    JkShmFile /var/log/apache2/jk.shm
     
    # Add jkstatus for managing runtime data
    <Location> /jkstatus/>
    JkMount status
    </Location>
    
  3. Setup Workers:

    Create workers.properties file in /etc/httpd/.

    Note

    The Balanced workers must have the same name as the name of jboss.node.name as shown in Section 7.7, “Clustering Configuration”. The example uses the names node1 and node2. The values for balanced workers in workers.properties file must also have the same name as node1 and node2.
    The file workers.properties is as follows:
    # Define list of workers that will be used for mapping requests
    worker.list=loadbalancer,status
     
    # modify the host as your host IP or DNS name
    worker.node1.port=8009
    worker.node1.host=192.168.210.101
    worker.node1.type=ajp13
    worker.node1.lbfactor=1
     
    ## modify the host as your host IP or DNS name
    worker.node2.port=8009
    worker.node2.host=192.168.210.102
    worker.node2.type=ajp13
    worker.node2.lbfactor=1
     
    # Load-balancing behaviour
    worker.loadbalancer.type=lb
    worker.loadbalancer.method=Session
    worker.loadbalancer.balance_workers=node1,node2
    worker.loadbalancer.sticky_session=1
     
    #worker.list=loadbalancer
    worker.status.type=status
    
    The file uriworkermap.properties is as follows:
    /portal=loadbalancer
    /portal/*=loadbalancer
    /eXo*=loadbalancer
    /eXoResources*/*=loadbalancer
    /exo*=loadbalancer
    /exo*/*=loadbalancer
    /web=loadbalancer
    /web/*=loadbalancer
    /integration=loadbalancer
    /integration/*=loadbalancer
    /dashboard=loadbalancer
    /dashboard/*=loadbalancer
    /rest=loadbalancer
    /rest/*=loadbalancer
    /jpp_branding_skin|/*=loadbalancer
    /jpp-branding-skin|/*=loadbalancer
    /jpp-branding-extension|/*=loadbalancer
    /status=status
    /status/*=status
    

Troubleshooting error "503 Service Temporarily Unavailable"

Problem Description
When accessing JBoss Portal using Apache, a "503 Service Temporarily Unavailable" response is received when trying to access JBoss Portal using Apache. The cluster is working and the individual JBoss Portal nodes can be accessed directly. The logs mod_jk.log indicates mod_jk is working, but Tomcat is reported as not running on the specified port.
Cause
In Red Hat Enterprise Linux, SELinux prevents httpd from accessing an important resource, such as jk.shm. Check SELinux alerts to verify this fact.
Solution
Temporarily disable SELinux to allow Apache to initialize the mod_jk connector properly by executing the following command:
setenforce 0

7.9. HTTPS Configuration

Red Hat JBoss Portal (JBoss Portal) runs by default in HTTP mode. For security purposes, configure a production platform to run in HTTPS mode.

Important

Understanding the fundamentals of keystore and truststore configuration is critical to the tasks in this section.
See the About SSL Encryption section in the Red Hat JBoss Enterprise Application Platform 6 Development Guide for detailed encryption theory and procedures relevant to all JBoss Middleware platforms.
There are a number of steps required to enable HTTPS on the platform. In summary, the steps are:
  1. Generate encryption keys and certificate.
  2. Export the self-signed certificate.
  3. Import the certificate to the trust store.
  4. Define the keystore and truststore details in the HTTPS connector directive file.

7.10. Enable HTTPS Communication

Generate a Keystore using the Java Keytool

Follow this procedure to create a key and certificate using the Java keytool utility.

Note

If you are using Tomcat Native Libraries, you must use openSSL to generate the key and certificate.
On Linux distributions, the Tomcat native libraries are enabled by default. To disable the libraries, set the native="false" flag on the web subsystem configuration.

Prerequisites

  • Read and understand how keypairs and certificates operate in the About SSL Encryption section of the JBoss Enterprise Application Platform 6 Development Guide.
  • Understand the command-line parameters of keytool as documented in the Oracle Java Tools documentation.
  • Obtain the JDK keystore password. For new installations, the default JDK password is "changeme".
  1. Run the command to generate a simple certificate using the keytool command (if you do not have your own X.509 certificate). The certificate is stored in the server.keystore file.
    keytool -genkey -alias serverkeys -keyalg RSA -keystore server.keystore -storepass 123456 -keypass 123456 -dname "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY"
    
  2. Import the key into the Sun JDK keystore:
    keytool -importkeystore -srckeystore server.keystore -destkeystore $JAVA_HOME/jre/lib/security/cacerts
    

    Note

    On OS X, the cacerts file is located at $JAVA_HOME/lib/security/cacerts
  3. Change the key password to match the new keystore password (in most instances this is the default JDK trustore password; changeit.
    keytool -keypasswd -alias serverkeys --keystore $JAVA_HOME/jre/lib/security/cacerts
    

Generate a Keystore using OpenSSL

Follow this procedure to create a key and certificate using openSSL.

Note

If you are using Tomcat Native Libraries, you must use openSSL to generate the key and certificate.
On Linux distributions, the Tomcat native libraries are enabled by default. To disable the libraries, set the native="false" flag on the web subsystem configuration.

Prerequisites

  • Read and understand how keypairs and certificates operate in the "About SSL Encryption" section of the JBoss Enterprise Application Platform 6 Development Guide
  • Understand the command-line parameters of openssl as documented in the command-line help.
  • Obtain the JDK keystore password. For new installations, the default JDK password is "changeme".
  1. Generate a simple key file using the openssl genrsa command:
    openssl genrsa -des3 -out server.pem 1024
    
    The above command will store the key in server.keystore .
  2. Generate a certificate signing request using the openssl -req command:
    openssl req -new -key server.pem -out server.csr
    
  3. Generate a server certificate from the server.csr key using the openssl -req command:
    openssl x509 -req -days 365 -in server.csr -signkey server.pem -out
    servercert.pem
    

Configure JBoss Portal to Use The Key

Configure JBoss Portal to accept the key, for either OpenSSL or Java keytool.
  1. Edit JPP_HOME/standalone/configuration/standalone.xml to add the HTTPS connector to the web subsystem configuration.
    Change certificate-key-file and password to values appropriate for the keystore. This procedure assumes the keystore password is the default: changeit):
    For Java keytool, as described in Generate a Keystore using the Java Keytool:
    
    <subsystem xmlns="urn:jboss:domain:web:1.2" default-virtual-server="default-host" native="false">
        ...
        <connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" secure="true">
            <ssl name="https" key-alias="serverkeys" password="changeit" certificate-key-file="${java.home}/jre/lib/security/cacerts"/>
        </connector>
        ...
    </subsystem>
    For OpenSSL, as described in Generate a Keystore using OpenSSL:
    <connector name="https" protocol="HTTP/1.1" scheme="https"
    socket-binding="https" secure="true" enabled="true">
      <ssl password="mypassword" certificate-key-file="server.pem" protocol="TLSv1"
    verify-client="true" certificate-file="servercert.pem"/>
    </connector>
  2. Save and close the file.
  3. Restart the portal.
  4. JBoss Portal can now communicate using a secure connection.

7.11. Specify White-list and Black-list Gadget Proxy Resources

To work around web browser security mechanisms, gadget consumption requires a local anonymous proxy to route access to elements used by the gadgets.
The anonymous proxy is configured to accept or refuse certain hosts by specifying a white-list (of allowed hosts) and a black-list (of denied hosts). By default, the proxy is closed to any host except the domain on which the gadget server is installed.

Task: Specify White-list and Black-list Gadget Proxy Resources

Complete this task to configure the gadget proxy filter to allow a specific list of gadget resources.

Prerequisites

  • You have installed the platform, and performed all configuration tasks up to this task.
  1. Navigate to JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/common/
  2. Open common-configuration.xml in a text editor.
  3. Append the ProxyFilterService <component> block to the file.
    <component>
       <key>org.exoplatform.web.security.proxy.ProxyFilterService</key>
       <type>org.exoplatform.web.security.proxy.ProxyFilterService</type>
        <init-params>
          <values-param>
            <!-- The white list -->
            <name>white-list</name>
            <value></value>
          </values-param>
          <values-param>
            <name>black-list</name>
            <value></value>
          </values-param>
        </init-params>
      </component>  
  4. In the <name>white-list</name> block, specify the name of the domains you want to grant access to by adding <value> directives for each domain name.

    Important

    A required resource must be explicitly defined in the white-list. Failure to do so will result in the resource being treated as black-listed.
    Wildcard characters can be used to simplify configuration. For example, *.example.com would allow all domains with example.com as the suffix.
  5. In the <name>black-list</name> block, specify the name of the domains you want to deny access to by adding <value> directives for each domain name.
    Wildcard characters can be used to simplify configuration. For example, *.example.com would deny all domains with example.com as the suffix.
  6. Save and close common-configuration.xml.
  7. You have specified the gadget domains required in your installation. This completes the procedure.

Related Information

Example 7.6. Valid Proxy Configuration

<component>
   <key>org.exoplatform.web.security.proxy.ProxyFilterService</key>
   <type>org.exoplatform.web.security.proxy.ProxyFilterService</type>
    <init-params>
      <values-param>
        <!-- The white list -->
        <name>white-list</name>
        <value>*.example.com</value>
        <value>www.example.net</value>
      </values-param>
      <values-param>
        <name>black-list</name>
        <value>forbidden.example.com</value>
      </values-param>
    </init-params>
</component>

7.12. Validator Configuration

A configurable validator can be applied to user name fields in the user account, user registration, and group membership portlets.
The validator enforces the validation mask for user name formats in these portlets, which results in consistent and valid user names.
The architecture does allow for configurable validation to be used in different contexts if needed, however this feature is not officially supported in Red Hat JBoss Portal (JBoss Portal).
The validator is configured through properties set in the JPP_HOME/standalone/configuration/gatein/configuration.properties file.

Important

Some components used in the portal depend on user names being all lowercase. Consider only accepting lowercase user names to maintain cross-compatibility.
The default validator behavior ensures a user name meets the following requirements:
  • Length must be between 3 and 30 characters.
  • Must start with a letter.
  • Must end with a letter or number.
  • Only lowercase letters, numbers, underscores (_) and period (.) can be used.
  • No consecutive underscores (_) or period (.) can be used.
To alter the default behavior, the validator supports four aspects:
gatein.validators.[username|groupmembership].length.min
Minimum length of the validated field.
gatein.validators.[username|groupmembership].length.max
Maximum length of the validated field.
gatein.validators.[username|groupmembership].regexp
Regular expression to which values of the validated field must conform.
gatein.validators.[username|groupmembership].format.message
Information message that displays when the value of the validated field does not conform to the specified regular expression.
Within each aspect, [username|groupmembership] refers to the configuration type.
The username configuration type sets how user names are validated when created by the user registration portlet, or modified by the user account portlet.
The groupmembership configuration type sets how user names are validated when created or modified by the group membership portlet.
The email configuration type sets how email fields are validated.
The displayname configuration type sets how user's display name fields are validated.
The jobtitle configuration type sets how user profile's job title fields are validated.
The grouplabel configuration type sets how group membership label is validated.

Example 7.7. Email as the User Name Mask

Use the following configuration to ensure users configure an email address as their user name.
# validators
            gatein.validators.username.regexp=^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-za-z]{2,4}$
            gatein.validators.username.format.message=Username must be a valid email address.

Example 7.8. Letter and Number Combination

Use the following configuration to ensure users configure a user name starting with the letter "u", followed by four to nine digits.
# validators

gatein.validators.username.length.min=5

gatein.validators.username.length.max=10

gatein.validators.username.regexp=^u\d{4,9}$

gatein.validators.username.format.message=Username must start with ''u'' and be followed by 4 to 9 digits.

7.13. Custom Password Policy

Red Hat JBoss Portal Platform allows to modify the password policy using the passwordpolicy property.
The passwordpolicy property is defined in the configuration.properties file.
The code below shows how the passwordpolicy property defines the format, length, and valid expression for an acceptable password.

gatein.validators.passwordpolicy.format.message=Minimum of 1 digit, 1 lower case, 1 upper case, minimum of 6 chars, max of 20.
gatein.validators.passwordpolicy.regexp=((?=.*\\d)(?=.*[a-z])(?=.*[A-Z]).{6,20})
gatein.validators.passwordpolicy.length.max=20
gatein.validators.passwordpolicy.length.min=6

Important

Restart the server after a password policy change to reload the policy.

7.14. Password Encryption

7.14.1. About Remember Me Password Encryption

The automatic login feature of Red Hat JBoss Portal (JBoss Portal) uses a cookie token mechanism to authenticate returning users. The tokens are not stored in plain text, but instead only their salted hash is stored. Due to an internal design limitation of JBoss Portal, the Remember Me feature requires that passwords are stored along with tokens. Passwords are encrypted symmetrically before they are stored.

7.14.2. Symmetric Password Encryption

The implementation is based on the Java Cryptography Architecture (JCA) library. By default, the AES algorithm is used for password encryption. All secrets needed in the process must be created, maintained, and stored securely by the Portal operator.

Example 7.9. JCA-based Configuration

The JCA-based encryption is configured in the configuration.properties file.
gatein.codec.builderclass=org.exoplatform.web.security.codec.JCASymmetricCodecBuilder
gatein.codec.config=${gatein.conf.dir}/codec/jca-symmetric-codec.properties

Note

This is an example of the directives required. There is no jca-symmetric-codec.properties file in the default JBoss Portal binary.
In this example, the builderclass configuration specifies org.exoplatform.web.security.codec.JCASymmetricCodecBuilder is used, and that it is configured in the jca-symmetric-codec.properties file.

Example 7.10. Customized Properties File

The configuration.properties values can be changed if the default settings require customization. Observe how the values in the file correspond to the keytool command parameters.
# Detailed information on JCA standard names can be found at
#
# http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#KeyStore
#
# The file key.txt is generated using the keytool utility in the JDK
#
# keytool -genseckey -alias "gtnKey" -keypass "gtnKeyPass" -keyalg "AES" -keysize 128 -keystore "key.txt" -storepass "gtnStorePass" -storetype "JCEKS"
#
#
gatein.codec.jca.symmetric.alias=gtnKey
gatein.codec.jca.symmetric.keypass=gtnKeyPass
gatein.codec.jca.symmetric.keyalg=AES
gatein.codec.jca.symmetric.keystore=key.txt
gatein.codec.jca.symmetric.storepass=gtnStorePass
gatein.codec.jca.symmetric.storetype=JCEKS

7.14.3. Customization using JCASymmmetricCodecBuilder

You can customize many aspects of the default setup, such as algorithm, key storage, key size and so on.

Example 7.11. Command to generate secret key

To generate a secret key that suits your needs, you will need to issue something like the following:
$JAVA_HOME/bin/keytool -genseckey -alias "customAlias" -keypass "customKeyPass" -keyalg "customAlgo" -keystore "customStore" -storepass "customStorePass" -storetype "customStoreType"

Note

  • The list of available algorithms can be found in Standard Algorithm Name Documentation .
  • Some extra params for keytool might be required for some algorithms.
  • In JCA, only JCEKS storetype supports symmetric encryption.
The keytool command stores the freshly generated secret key in a file named customStore . Copy this file to the gatein/conf/codec directory to be able to reference it in jca-symmetric-codec.properties file.
It remains to update the jca-symmetric-codec.properties file with parameters used in the above keytool invocation:

Example 7.12. Update jca-symmetric-codec.properties file

gatein.codec.jca.symmetric.alias=customAlias
gatein.codec.jca.symmetric.keypass=customKeyPass
gatein.codec.jca.symmetric.keyalg=customAlgo
gatein.codec.jca.symmetric.keystore=customStore
gatein.codec.jca.symmetric.storepass=customStorePass
gatein.codec.jca.symmetric.storetype=customStoreType