Identity server

GateIn Portal 3.8 comes with a component named PicketLink IDM, which is there to store and retrieve users and groups from various identity servers. PicketLink IDM supports three general options:

1. Database: users, groups and their relationships are stored in a RDBMS database. Table names and column names can be changed, but the overall relationship between tables remains the same. This solution suits identity servers built from scratch that will handle thousands of users.

2. LDAP: users, groups and their relationships are stored in an LDAP (or ActiveDirectory) server, the directory structure can be adapted to the most common scenarios by configuration. This solution is particularly suited to environments where an LDAP server is already available, environments where the identity server will be shared among multiple services (the website being one of them) or for very large number (millions) of users. When using LDAP with large number of users, it is recommended to use LDAP tools to do the provisioning of users.

3. Custom: when retrieving users, groups and their relationships cannot be done by configuration, it is possible to use the Picketlink IDM SPI to implement custom methods which control retrieving and storing user information.

Picketlink IDM also supports mixed environments, which is very useful when an LDAP infrastructure is provided in a read-only mode. Since a website may need to store additional information about users (such as their preferred language or skin), it can combine LDAP and database services to retrieve users from LDAP and store additional properties in a database. During the calls to the identity API, the information from both sources will be transparently merged.
For more information about PicketLink IDM, please check the GateIn Portal 3.8 Reference Guide and the PicketLink IDM documentation.

Storage

The portal framework stores page compositions, portlet preferences, gadget code in a database through a Java Content Repository (JCR) API. A set of database servers and JDBC connectors are part of our quality assurance cycles and the certified configurations are listed in the Supported Configurations document.

It is important to choose one of the combinations or check with a Red Hat contact for specific environments that would differ from this list.

The database schema will be automatically created during the very first start up of the portal. Therefore, it is required that the database users have sufficient rights to create tables. This privilege can be revoked after the initial start up. Also the database content can be exported and imported without CREATE TABLE permission. This makes the installation of the product very easy in most cases.

We do not provide additional recommendation to choose one database server over another as long as it is one of the certified ones.

As said earlier, content is stored through a JCR API. RDBMS are not ideally suited for storing large files. To overcome this, it is possible to configure eXo JCR to store such files in a filesystem rather than in the database. With this configuration, metadata about the files would still be stored in the database. Note that if the website is running on a cluster, the filesystem will need to be accessible from all the nodes and a NFS solution needs to be set up. For more details see the notion of "value storage" in the eXo JCR Reference Guide.

Cluster

Clustering for failover or load-balancing requirements requires spending more time configuring it for your environment, we made it easy to handle common situations though. There is a cost associated with clustering (GateIn Portal 3.8 has some optimizations when running on a single node), but the product is designed to linearly scale up so that the same performance is added every time a new node is added. All critical parts are kept in sync among nodes and the less critical ones are left aside to achieve better performance. It will be equally critical that applications developed for the final websites pay the same attention when it comes to replicating data across a cluster of nodes.

The number of nodes will vary a lot depending on the applications developed and used on the final website. We recommend to do early performance analysis with tools such as JMeter, Grinder or similar to measure the impact of heavy loads.

It is usually recommended to run a cluster to achieve high availability.

Single-Sign-On (SSO)

If a website is a part of a wider enterprise infrastructure, a deployment of Single-Sign-On (SSO) may bring substantial usability benefits to end users. SSO solutions supported by GateIn Portal 3.8 are listed in the Supported Configurations document. In some cases it can be better to have the token manager service on a dedicated server.

Summary

By now you should know what infrastructure you will need:

1. A database

2. Optionally LDAP, depending on your choice

3. Optionally NFS, depending on the configuration (mandatory on a cluster with default settings)

4. Optionally an SSO token service

5. Optionally a cluster of nodes

Here is an example of the simplest set-up:

simpleinfra

Here is an example of a more complex setup:

complexinfra