Delivery Tier Authorization Configuration

Introduction

Goal

Configure authorization in Bloomreach Experience Manager's delivery tier.

Background

Bloomreach Experience Manager's delivery tier supports authorization at mount and sitemap item levels out-of-the-box. This page describes how to configure authorization at mounts and sitemap item levels as well as at content level.

For a worked out example see Limit Access to Certain Pages and Documents to Certain User Groups.

Authorization Configuration

Web Application Level Authorization

You can secure a mount or sitemap item by setting the hst:authenticated boolean property to true, and specifying the authorized roles or users in the multi-valued string properties hst:roles or hst:users.

For example, if you set the following properties for either a mount or a sitemap item:

hst:authenticated: true
hst:roles: [ editor, member ]

then, the mount will be accessible to users in 'editor' role or users in 'member' role. If an unauthenticated user accesses this resource, the response is an HTTP Not Authenticated (401) error and the user is redirected to the login form. Or if the user is authenticated but in neither 'editors' nor 'approvers' role, then the response will be an HTTP Forbidden error (403).

HST Container checks the user's roles by the Servlet / JAAS standard APIs such as HttpServletRequest#isUserInRole(roleName). So, with the example above, HST Container will invoke request.isUserInRole("editor") and request.isUserInRole("member") at least.

Also, you can use the hst:users property like this:

hst:authenticated: true
hst:users: [ editor1, member1 ]

With the example configuration above, HST Container checks if the user's principal name is included in the hst:users property values. HST Container will retrieve the user's principal name using HttpServletRequest#getUserPrincipal().getName().

Finally, if both hst:roles and hst:users are present, then HST Container will look up both property values in order to see if the user can access the resource. If the user has any role or the user's principal name is included, then the user will be authorized.

Repository Level Authorization Integration

HST also provides repository-level authorization integration, meaning the JCR session used during the request will be tightly integrated with the authenticated user's subject.

To use this option, set the following boolean property for a mount:

hst:subjectbasedsession: true

With the configuration above, the JCR session during the request processing is created with the JCR credentials of the authenticated user's subject per each request. In this case, the JCR session is not borrowed from the internal JCR session pool. This allows authorization in the delivery tier at content level using security domains.

Optionally, the JCR session with this option can be stored in the HTTP session and reused in the following requests for more efficiency. To use this session stateful JCR session usage option, configure the following boolean property for a mount:

hst:sessionstateful: true

Note that this option should be used in limited environments, such as applicatiosn with limited users, because it can increase memory size at runtime when used without caution!

Security Domain Configuration in the Repository

To configure security domains and roles, please refer to the page Repository Authorization and Permissions.

The Bloomreach Experience Manager content repository provides security domain based authorization, meaning security roles can be differently configured per each security domain.

Therefore, Bloomreach Experience Manager's JAAS Login Module uses only one security domain for authentication. By default, the security domain used is everywhere.

To use another security domain, you can configure the following property in /WEB-INF/hst-config.properties:

# Login Module Authentication Provider configurations
security.authentication.role.domain = everywhere

Example

Consider a standard implementation project created using Bloomreach Experience Manager's Maven archetype.

Let's say the entire website should only be accessible to logged-in 'members'.

In the Console, create a new role node called member:

/hippo:configuration/hippo:roles:
  /member:
    jcr:primaryType: hipposys:role

In the CMS, create a user group called 'members' and assign it the following permissions:

• Domain everywhere: role member
• Domain live-documents': role readonly
• Domain webfiles: role readonly

In the Console, protect the root mount by adding the hst:authenticated and hst:roles properties as follows:

/hst:hst/hst:hosts/dev-localhost/localhost/hst:root:
  hst:authenticated: true
  hst:roles: [ member ]