Authentication valves

Overview

Digital Experience Manager contains a set of built-in valves, organized in a pipeline, which are used to authenticate the user, making a request to the web application, and keep track of user session.

The pipeline can be easily extended with custom valves, e.g., authenticating the user against an external system.

Next sections provide an overview of the built-in valves as well as a short How-to for implementing and registering a custom valve.

This description applies to Digital Experience Manager 6.6.0.0.

Built-in valves

The authentication valves pipeline is configured in a Spring bean definition file org/jahia/defaults/config/spring/auth/applicationcontext-auth-pipeline.xml, packaged into the jahia-impl-6.6.0.0.jar file.

The pipeline is executed in a sequence (as a chain). If a valve succeeds to authenticate the user, the pipeline execution is stopped. Otherwise it is delegated to the next valve in the pipeline.

The default list of valves and their execution sequence (the most top have the precedence) is as follows:

TokenAuthValve - used by Jahia for internal requests, e.g. for e-mail newsletter content rendering, and relies on the jahiatoken HTTP request header.

LoginEngineAuthValve - implements the login form processing for provided username and password values.

SessionAuthValve - authenticates the request by looking up the valid user in the current HTTP session scope. If a non-guest user is found in the session scope the pipeline execution stops here. Otherwise a next valve is invoked.

CookieAuthValve - relies on the usage of "Remember me" feature in the login screen, when a special persistent cookie is stored in the user's Web browser. This cookie is used to lookup and authenticate the user requests, having that particular cookie.

ContainerAuthValve - utilizes the authentication scheme, provided by the Servlet container (application server itself). In such a case, the authentication is done by the server and the valid user is available to the ContainerAuthValve via request.getUserPrincipal().

CasAuthValve (*) - implements the single sign-on using an external Central Authentication Service (e.g. provided by a Jasig project.

The default pipeline can be extended or overridden completely by providing a custom Spring bean definition with id authPipeline.

Implementing custom authentication valve

Here we will show how a custom authentication valve can be implemented and registered in Digital Experience Manager 6.6 using a hypothetical example.

Let's consider that an external service (server) is doing the user authentication and upon successful "login" operation it stores a special authentication ticket (token) in the header (say, Authentication-Ticket) of HTTP request that is forwarded to Jahia.

In such a case, the valve will be added at the end of the authentication pipeline.

In most of the cases a custom valve should go after the SessionAuthValve, which uses a valid user (non-guest), found in the current HTTP session, and does not invokes the next valves in the pipeline in such a case.

In some cases, it could be needed to add the custom valve "before" a particular one, e.g. before the SessionAuthValve, for example if the authentication scheme does not imply the explicit logout mechanism and the session is not invalidated. The registration of the valve in such case can use an explicit position:

This password digester is used for all users in DX. A restart of DX is required for changes to be effective. After the changes all further user password (for new users or when password is modified for existing users) will use that new hash algorithm. The existing passwords will still continue to work. A password hash is prefix with an ID of the hashing algorithm, which was used for its encryption.

Out of the box, the following hash algorithms are available in DX (in the order of their strength: from weak to very strong):

pwdDigesterSHA1RandomSalt32x4096

pwdDigesterSHA256RandomSalt32x4096

pwdDigesterSHA512RandomSalt32x4096

pwdDigesterPBKDF2RandomSalt64Key32x8192

Their IDs are self speaking and depict the hashing algorithm used.

Note, please, the stronger the algorithm is, the slower it is in hashing and verifying the passwords (on user login). The default one (pwdDigesterSHA1RandomSalt32x4096) provides a good balance between strength and speed.

You could also define and use a custom algorithm in the following way. The example below shows how to define a new password hasher that uses SHA-384 with random 32 byte salt and 4096 iterations.

Add the following Spring been definitions into <digital-factory-config>/jahia/applicationcontext-custom.xml file:

Jahia Tool Manager password

The Jahia Tool Manager password is specified in the jahia.properties (PBKDF2 hash). Due to security considerations, this password can be only reset manually directly in the jahia.properties file. After you do that, you need to restart the server. Jahia Tools Area provides a utility JSP for encrypting clear text passwords: http://localhost:8080/tools/pwdEncrypt.jsp

Resetting root user password

Here is the procedure for resetting the password of the root user in Digital Experience Manager 7.0:

The following is the procedure for resetting the password of the root user in Jahia 6.6:

Create a plain text file <jahia-web-app-root>/WEB-INF/etc/config/root.pwd with a new root user password in clear text

Restart the server

You can now login with your new password as root

Locking a user account

User account can be locked in Jahia 6.6 either using a User Management UI in Jahia Administration or using the Content Manager and setting the j:accountLocked property on the corresponding user node to true.

Sensitive user data

Enabling SSL for logged in users

There is an option for "forcing" a switch to an SSL (HTTPS protocol) for a user session, from login to logout. This allows sites with higher security concerns to force secured connections for logged in users.

In order to enable it, please:

Rename the file <jahia-web-app-root>/WEB-INF/etc/config/urlrewrite-ssl.xml.disable into urlrewrite-ssl.xml

Go into Jahia Administration UI and flush output HTML caches

Restart you server

Now the login forms will contain a URL, leading to HTTPS and logout links will do a redirect back to HTTP.

The behavior could be adjusted by changing the URL rewrite rules in the urlrewrite-ssl.xml file.

Template and action protection

Module resources

In all Digital Experience Manager modules, the following sensitive resources are protected from a direct access via web browser:

content definition files (*.cnd)

rule files (*.drl and *.dsl)

I18N resource bundles and template properties (*.properties)

scripting templates for mail notifications (/mails/*.*)

all resources under META-INF and WEB-INF folders

JSP templates (*.jsp)

So, when developing new modules take care, please, of protecting sensitive files by e.g. placing them into the META-INF folder, which is protected by default.

META-INF is also the default folder for content and rule definition files.

XSS vulnerabilities

When developing custom JSP templates, especially those, requiring user interaction, the following rules of thumb can be used to reduce the risk of simple cross-site scripting XSS attacks, such as JavaScript code injection.

when using values of request parameters in templates markup, they need to be escaped, e.g.:

expect that values, coming from request parameters can be not well-formed or malicious. For example, if your template expects a JCR node path as a request parameter path, you should take care of checking if the path value really corresponds to a node, i.e.:

Protecting render actions

Render actions, which are subclasses of org.jahia.bin.Action, can be protected in several ways from execution by a unauthorized user or in the wrong context.

Valid authenticated user

An execution of an action can require a valid authenticated user. This is the default level of protection for all render actions.

If your action should be "available" for non-authenticated users or a protection is done in a different manner, you can "relax" this constraint by specifying a false value for action's requireAuthenticatedUser property in its Spring bean definition file.