Authorization Model Concepts
Introduction
Security Authorization Management (aka Information Access Management, IAM) is all about answering the following question: Who is allowed to do What, Where?
For the Bloomreach Experience Manager (brXM) the information which is used to answer this question is all managed through the following high-level authorization model:
The items Userrole and Feature & Functional Access are new in brXM v14!
Each of these items of the model are explained on high-level in the following sections. More (technical) details for each of these items are available through separate pages.
Who
The Who part of the authorization question typically needs to be answered with a specific user or set (group) of users.
The brXM model provides three ways to define, and then select or reference a specific user or sets of users:
- directly: as User
- by aggregation: as member of a Group
- by granted user privilege: having a specific Userrole, directly or indirectly as member of a Group
Users
Users can either be a 'regular' human user or as a 'system' user. System users are used for internal or background/integration processes, and are not allowed to login interactively in brXM.
For each user a basic (minimal) set of data can be stored, like the mandatory username, first name, last name, email, password, etc, as well as the flag to indicate a system user. Another important property of a user is the 'active' flag, which can be used to enable or disable login for a user.
Users can be managed by the CMS or automatically imported and synchronized from an external provider like LDAP.
While a few builtin system and default regular users are automatically provided by brXM, and developers may add more predefined users as well, users are otherwise considered to be environment specific and treated as category system data in the repository.
Groups
Groups are used for organizing sets of users with a common organizational or functional responsibility. Groups, like users, can be granted specific roles within repository security domains, and/or specific userroles (see below). Users which are member of a group automatically inherit all its userroles and the roles granted to it within specific security domains.
Userroles
Userroles represent a functional privilege (aka Functional Role) which can be granted to Users directly or indirectly via Groups they are member of. Userroles, and the functional privilege they represent, are global and granted for the duration of a user's logged in session.
Some of these privileges are effective globally, for example the privilege to login into the CMS (userrole xm.cms.user) or having access to the Channels application (xm.channel.user). Other Userroles may only be effective within the context of one or more security domains, for example the privilege to administrate one or more channels (userrole xm.channel.admin), which obviously requires both the xm.cms.user and xm.channel.user Userroles to be granted for usage within the CMS.
Userroles, similar to the Roles used for security domains and described further below, also can include or imply other userroles, recursively and thereby automatically inheriting the privileges of those implied userroles. For example the userrole xm.content.admin implies the xm.content.editor userrole, thus a user only needs to be granted the xm.content.admin userrole to also gain (inherit) the xm.content.editor userrole as well.
The usage and purpose of Userroles lies somewhat between Who and What, and between the functional and feature access toggles for the CMS and Delivery and context specific privileges for Repository security domains.
The diagram therefore places the Userrole element in the crosshair between these 4 dimensions.
The brXM product and its default provided security domains now primarily uses Userroles for answering the Who question and no longer uses, nor requires, the default provided (regular) Users and Groups!
What
What a user is allowed to do is determined by which privilege(s) that user has, either directly and globally as a Userrole privilege, or via a Role granted within a specific security domain (the Where part, described further below).
Feature & Functional Access
A new security feature introduced in brXM v14 is making direct use of the Userroles granted to a logged in user for determining access to specific features and functionality. This is useful in cases where the Where question, with respect to repository content, is not relevant or applicable.
For example to check if a user is allowed to login into the CMS (has userrole xm.cms.user: yes/no) or allowed to manage user security (has userrole xm.security.user-admin: yes/no).
Or if a Delivery Tier Authenticated user has a (custom) userrole intranet.staff required to access a (more) secured section of an intranet site.
If a logged in user has a specific userrole can be checked programatically through the new HippoSession.isUserInRole(<userRoleName>) API, and in the delivery tier also through the standard Java Servlet / JAAS HttpServletRequest.isUserInRole(<userRoleName>) method. Or more declaratively through specific configuration. For more details see the Userroles and Delivery Tier Authorization documentation.
Roles, privileges and Authrole
Roles define sets of repository privileges (what) which can be granted to Users, Groups or users having a specific Userrole (who), within security domains (where). Such a grant is configured through an Authrole.
And because an authrole is always defined for a specific security domain, it effectively "glues" together the Who, What, and Where for repository content authorization.
There are two kinds of repository role privileges: the standard JCR privileges and custom privileges.
The JCR privileges are specified in the JSR 283 specification, section 16.2.3 Standard Privileges, like jcr:read, jcr:write, jcr:all, etc.
brXM provided custom privileges are used to grant access to specific operations or tasks for content workflow or other features like hippo:editor, hippo:channel-viewer, hippo:rest, etc.
Roles, similar to userroles, also can include or imply other roles. A role will inherit all privileges from its included or implied roles, recursively.
For each security domain at least one authrole (node) must be configured, and typically are (should be) named after the (one) role they grant (a single value role name property).
Who the authrole is granting its repository role can be specified as a set of specific users (multi-value user name property), a set of specific groups (multi-value group name property), or for users having a specific userrole (single value userrole name property). Or a combination thereof.
Multiple authroles may be configured for a security domain, granting different repository roles for different users.
Or for granting the same repository role for different userroles as an authrole (intentionally) can only reference a single userrole. In which case the authrole typically will be named after the userrole it references instead of the repository role it grants.
Where
Security Domains
A Security Domain defines a set of repository nodes, for example documents, for which specific access privileges can be configured, using authroles (see above).
A security domain is defined in a query-like manner based on facets (properties). This allows the repository to return the correct nodes in queries and faceted views, like facet select, without having to evaluate the access rules for all the nodes individually.
This keeps query execution very fast, even when the amount of nodes is in the millions and the user is only allowed to see (read) just a few of them, because no filtering of the result set is needed afterwards.
Furthermore, as a major improvement since brXM v14, practically all standard provided facets rules are now using the hierarchical jcr:path or jcr:uuid facets, which further simplifies and optimizes both the acces rule evaluation and query execution.
Practically, a security domain consists of one or more domain rules, and each domain rule consists of one or more facet rules. The selection or query of the nodes for a security domain works as follows: a repository node belongs to the security domain if it matches one or more of the domain rules, and a node matches a domain rule if it matches all of the facet rules for that domain rule.
At login all the repository roles for the security domains the user has are parsed. This makes evaluating the rules faster in the access manager. When the effective domain security configuration for a user has changed, the user has to logout and login back again to effectuate the new authorization rules.
Domain Rules
A Domain Rule is a container for one or more facet rules.
Facet Rules
A Facet Rule defines the rules for which a repository node is tested whether it belongs to the security domain. For more technical details on the type of facet rules available and how to configure them, see the dedicated Domains documentation page.
Security Domain Folders
Security Domains are all defined under a Security Domain Folder parent node.
brXM v14 now supports additional federated security domain folders, besides the common/general folder located at /hippo:configuration/hippo:domains.
Federated security domain folders can be (and are) used within a specific section (path) of the repository, and provide a hierarchically restricted and relative scope for the security domains within that section (path) of the repository.
This simplifies the definition and standardization of common and repeated security domains in different paths of the repository, for example for multiple hst site configurations. And it separates and simplifies the definition of security domains only applicable for specific optional features, for example for the (enterprise) relevance or projects features.
This also means that with brXM v14 the standard provided security domains for such features now have moved to dedicated federated security domain folders. More technical details and the usage and configuration of security domain folders is provided on the Domains documentation page.