Delivery Tier Authorization Configuration

Overview

This page explains how to configure authorization in the delivery tier of Bloomreach Content. You can control access at both the mount and sitemap item levels.

Note: The hierarchical authorization check described here was fixed in version 14.0.1. If you are using 14.0.0, the behavior differs when configuring constraints on sitemap items and mounts. However, this scenario is uncommon in practice.

For background on how delivery tier authorization works with the RepositoryAuthenticationProvider, see the Authentication and Authorization Walkthroughs.

Authorization Configuration

Authorization at the Web Application Level

You can restrict access to a Mount or a Sitemap item by setting the hst:authenticated property to true. When enabled, only authenticated users can access the mount or sitemap item.

Access to a URL is granted only if the sitemap item for the URL, all ancestor sitemap items, and the mount allow access for the user. Each ancestor sitemap item and the mount are checked independently.

You can further restrict access by specifying allowed roles or users using the hst:roles or hst:users properties on the mount or sitemap item.

For example, to restrict a mount to authenticated users with the staff role:

hst:authenticated: true
hst:roles: [staff]

• If an unauthenticated user attempts access, the response is HTTP 401 Not Authenticated and the user is redirected to the login form.
• If an authenticated user does not have the staff role, the response is HTTP 403 Forbidden.

You can also protect individual sitemap items. For example:

+ hst:sitemap
  + blog
     - hst:authenticated: true
     - hst:roles: [staff]
     + _any_.html
     + _any_

In this configuration, only authenticated users with the staff role can access /blog and its descendant URLs.

Note: If you configure hst:authenticated on the mount, you must also set it on the sitemap item if you want to apply additional constraints at that level.

Hierarchical Authorization Checks

Consider the following configuration on a mount:

hst:authenticated: true
hst:roles: [staff]

And the following sitemap structure:

+ hst:sitemap
  + blog
     - hst:authenticated: true
     - hst:roles: [uberstaff]
     + _any_.html
       - hst:authenticated: true
       - hst:roles: [superstaff]
     + _any_

This setup results in:

1. Only authenticated users with the staff role can access the mount.
2. Only authenticated users with both the staff and uberstaff roles can access /blog and its subpaths such as /blog/2019.
3. Only authenticated users with the staff, uberstaff, and superstaff roles can access deeper paths such as /blog/2019/myblog.html.

Configuring Multiple Roles

To allow access to users with either the staff or customer role, configure the mount as follows:

hst:authenticated: true
hst:roles: [staff, customer]

A user with either role is granted access. The HST container checks roles using standard Servlet or JAAS APIs, such as HttpServletRequest#isUserInRole(roleName). Only one matching role is required.

Restricting by Users or Roles

You can also specify explicit users instead of roles:

hst:authenticated: true
hst:users: [john, dick]

In this configuration, the HST container checks if the user's principal name (retrieved via HttpServletRequest#getUserPrincipal().getName()) matches any value in hst:users.

If both hst:roles and hst:users are present, access is granted if the user matches any specified role or is listed as a user. For example:

hst:authenticated: true
hst:roles: [ staff, customer ]
hst:users: [ user1, user2 ]

• user1 and user2 are authorized even if they do not have the staff or customer role.
• Any user with the staff or customer role is also authorized.

Repository-Level Authorization Integration

The HST container can integrate repository-level authorization by associating the JCR session with the authenticated user's subject. To enable this, set the following property on the mount:

hst:subjectbasedsession: true

With this configuration, the JCR session for each request is created using the authenticated user's credentials, rather than borrowing from the internal session pool. This enables content-level authorization using security domains.

For improved efficiency, you can store the JCR session in the HTTP session and reuse it for subsequent requests by setting:

hst:sessionstateful: true

Warning: Use the session stateful option only in environments with a limited number of users. Storing sessions in HTTP sessions can increase memory usage at runtime.

Info: Repository-level authorization integration is supported only with form-based authentication using org.hippoecm.hst.security.servlet.LoginServlet.
It is not supported with Basic authentication or with other authentication methods, including form-based authentication that does not use the LoginServlet.