Interface Builder users can be granted permission to manage custom visibility categories. Such categories are based on visitor groups or teams, and enable editors to control which content logged-in users (visitors or editors) may access compared to not logged-in website visitors. You can set up visitor groups and teams in your JustRelate Console to make them available as distinctive criteria in your visibility categories. This functionality requires that the underlying app authenticates visitors with IAM.

In the context of visibility, a visitor group represents a collection of people, e.g. representatives of partner companies or vendors, who are given access to content in website areas reserved to them, however, without being able to modify this content, as opposed to team members, i.e., editors.

With non-IAM-based visitor authentication, the groups to be made available for use in custom visibility categories need to be set up in your identity provider (IdP) configuration where they can then be assigned to users. Note that for the Interface Builder, such group names are merely identifiers with configurable display texts, i.e. they don’t have any meaning. Also, the Web Interface Builder doesn’t take account of implicit group assignments (based on rules). As a consequence, such implicit assignments (like “all sales staff members are marketing members as well”) need to be made explicit. For obvious reasons, it is essential that group names are defined and used consistently.

As a user logs in to a Interface-Builder-based website, the IdP generates an OAuth ID token that the Interface Builder uses to identify the user. If groups have been set up, the ID token includes a groups claim indicating to the Interface Builder the groups that have been assigned to the user. By means of those groups, the Interface Builder can then determine the visibility categories applicable to the user, and grant or deny them access to protected content.

The structure of an ID token containing a groups claim looks like this:

The key used to identify the groups claim in the ID tokens can be either https://scrivito.com/groups or groups.

If you are using Auth0 for managing the identities of your users, there are at least two ways to assign groups to them. One way is to use roles to model groups, another one is to install the Authorization extension that promises to be suited better than roles but requires more setup. For simplicity reasons, we will be showing you here how to define the groups claim using the first method, i.e. by means of Auth0 roles. First, create the desired roles:

Note that group names must not start with an underscore character as the Interface Builder uses it internally. After setting up the roles, assign users to them or, vice versa, assign these roles to users.

Finally, create a rule (implemented as a JavaScript code snippet) that programmatically adds the groups to the ID token. For that, create a rule based on the “Empty rule” template and enter the below JS code.

To ascertain whether groups are included in the ID token, first log out from the Interface Builder (by removing all scrivito.com cookies), then log in again to have your identity provider issue a new ID token. Now, try to access a page to which a visibility category is assigned that grants your groups (and nobody else) access.