- 1.1 Context
- 1.2 Prerequisites
2 Understanding the big picture
- 2.1 Roles templates governance
- 2.2 From an end-user perspective
- 2.3 Concepts
  - 2.3.1 Object families
  - 2.3.2 Objects tags
  - 2.3.3 Role templates
  - 2.3.4 Roles
3 Advanced configuration
- 3.1 Role template default configuration
- 3.2 Interface configuration
4 Processes
- 4.1 Initial setup
- 4.2 Initial deployment
- 4.3 Application upgrades
- 4.4 Retrieve an environment configuration for debug

Context

Since 2021.3.0, the Wedia product provides a simple toolbox for managing permissions over the application, thanks to PACKAGED_Security plugin. While this plugin successfully simplifies permissions management by allowing to define grants without developing security rules, it has some lacks for allowing a business user to be autonomous in permissions granting:

Assigning permissions is done with generic BackOffice interfaces that does not denote the functional issue very well
Configuration of permission groups does not require programming skills, but a strong technical knowledge of the product and the application is still required.
It cannot comply to licence agreements.

Starting from 2022.5.0, the default “starter-kit” configuration provides a new user interface for managing roles and permissions. This interface extends PACKAGED_Security plugin to provide an user-friendly interface for managing roles and permissions on the Wedia product.

2023.3 changes

Prior to 2023.3, when a role was created from a role template, all permissions inherited were created in the pkgsecugroup table.

As of 2023.3, only differences between the role and the role template are stored.

Prerequisites

It is highly recommended for integrators to read and understand Setting Up Permissions and Roles to understand the concepts behind permissions management, and examples on how to extend the default behaviour with specific needs not covered.

Understanding the big picture

To ensure that our licensing scheme is respected, roles inherits from role templates. Roles templates administration is reserved to Wedia integration team.

Roles templates governance

The product team delivers default role templates configured to match standard licence agreements.
The integration team might create / update / delete role templates to meet customer-specific licence agreements.
The integration team defines “Authorised users” based on role templates.
The integration team or the customer initialises roles out of defined role templates
The integration team or the customer can tweak roles to fine tune permissions without having to deploy a NAR
The integration team can tweak role templates without having to deploy a NAR
The integration team is still able to develop specific rules and to deploy them with a NAR

From an end-user perspective

DAM Administrators cannot create new role templates. Instead, they will create roles based on a role template.
DAM Administrators are able to update a role except changing its template: once a role is created from a role template, it is not possible to change the assigned role template.
DAM Administrators can adapt inherited permissions given to a role within the limits of the role template.

Concepts

Object families

As the WEDIA product allows data structures to be classified within families, the roles and permissions interface takes advantage of this feature to group together data structures that are likely to share the same permissions for a role.

The product team delivers various data structures that have been pre-classified within the following families:

ID	Key	Name	Description

ID	Key	Name	Description
11	`dam.collection`	Dam collections	All data structures considered as a DAM object should be in this family ex: asset
12	`dam.metadata.opened`	Opened metadata	Metadata that contributors can enrich ex: keywords
13	`dam.metadata.closed`	Closed metadata	Metadata that only admin can enrich ex: usagerights
14	`dam.metadata.ai`	AI metadata	Metadata that are gathered by AI. ex: aiconcept
15	`dam.metadata.tech`	Technical metadata	Metadata that are handled by the system ex: image orientation
16	`portal.editorial`	Editorial data	All data structures used for editorial purpose on portal ex: home widget
17	`dam.import`	Import data	All data structure related to bulk import ex: massimportobject
18	`dam.metadata.static`	Static metadata	Metadata that should not change in live mode ex: rights
19	`collaborative`	Collaborative data	Data that are use for collaborating ex: comments
20	`administration.users`	User related data	Data used for users ex: user
21	`administration.process`	Process	Data for processes ex: workflow

Objects tags

Some data structures should never be created, read, updated or deleted by functional users (ex: activated, pkgroletemplate…)

Therefore, in order to allow defining permissions on a data structure, at least one tag must be added to the data structure’s configuration. Read Setting Up Permissions and Roles | Identifying eligible structures to understand how those tags must be defined.

Role templates

A role template defines:

A set of permissions that a role will inherit by extending the role template.
A mechanism to ensure some default permissions (or lack of permissions) cannot be overridden for a role.
Default available digital assets renditions for roles.
Default BackOffice menu for a role.

Roles

Roles created out of a role template cannot change the template they are extending.

Only user with the developer role can create roles without specifying a role template.

Advanced configuration

Role template default configuration

When created, a role template is initialized with a default configuration. It is defined by:

The object families that are available within the application
A static configuration contributed in PACKAGED_Security's role_template_default_permissions parameter.

The configuration is stored in the permissions field of role template as a JSON object.

The JSON object structure of both plugin parameter and role templates can be described with the following typescript type declaration:

type DataStructuresSelector = string; // An object selector
type Action = string; // a lower-cased security action name

interface ActionConfiguration {
  enabled: boolean
  permissions: Array<string> // each item is a PACKAGED_Security plugin permission
}

interface IPermission {
  v1: {
    applications: Record<Action, ActionConfiguration>
    boards: Record<Action, ActionConfiguration>
    objectdata: Record<DataStructuresSelector, Record<Action, ActionConfiguration>>
  }
}

This structure reflects permissions that can be granted to roles (<version>/<domain>/<action>/<modifiers>) but in an object structure. Note that objectdata gets an extra layer for holding structures selectors names.

Structures selector obey the same rules as regular selectors, but allow an additional pattern: @<objectFamilyName>~<workflowName>

Interface configuration

As a default, the interface provides for roles and role templates menu items entries to define permissions for assets, metadata, global permissions and Back Office permissions.

Those items are driven from children of routes with path /role/:id and /roletemplate/:id:

Assets permissions menu entry is defined as follows:

{
  name: 'role/assets-permissions',
  meta: {
    menu: 'WedConfSiblingsMenu',
    familyBaseI18n: 'collection',
    typeBaseI18n: 'role'
  },
  path: 'assets-permissions',
  component: 'UsersRolesFamilyPermissions',
  props: {
    preferTabsOnObjects: true,
    domain: 'objectdata',
    family: '^dam\\.collection.*$',
    entityPath: 'appsettings/data/role',
  }
},

Metadata permissions menu entry is defined as follows:

{
  name: 'role/metadata-permissions',
  meta: {
    menu: 'WedConfSiblingsMenu',
    familyBaseI18n: 'metadata',
    typeBaseI18n: 'role'
  },
  path: 'metadata-permissions',
  component: 'UsersRolesFamilyPermissions',
  props: {
    disableTabsOnObjects: false,
    domain: 'objectdata',
    family: '^dam\\.metadata\\..*',
    entityPath: 'appsettings/data/role',
  }
}

As you can see, both routes uses the same components and only differs by props given to the UsersRolesFamilyPermissions component.

The family prop defines which object families we want to manage from this route. For assets, it is defined to ^dam\.collection.*$ which is a regular expression to select object families we want to manage at this level. For metadata, it is defined to ^dam\.metadata\..*

If your project needs to open the ability to manage permissions for different Wedia modules (such as DMM, CPCM), you can define in the configuration additional entries to target specific objects based on the families to which they belong.

Processes

Initial setup

As of 2022.5, when restoring the WAR embed NAR file to the application, the new interfaces will be available.

You will still need to initialize default security permissions by calling the /api/packaged/admin/security/update service. This service has been updated to consider 2 cases:

The plugin parameter enable_role_type_management is set to false (plugin parameter's default value) → behaviour is unchanged: Roles are granted permissions out of embed permissions templates
The plugin parameter enable_role_type_management is set to true (delivered default plugin configuration) → Default provided roles are patched to extend default provided role templates. Permissions are initialized for roles out of role templates.

As an integrator, you can choose to stick to product provided role templates, or to duplicate them and handle them from a project perspective.

Product delivered role templates have IDs of 997, 998 and 999. This guarantees that further created templates will have IDs >= 1000. The product has comfortable provision of 996 role templates.

Initial deployment

Role permissions are initially deployed by delivering structures role, pkgroletemplate, pkgsecugroup and pkgsecupermission.

Application upgrades

Further deliveries of the application should not embed structures role, pkgroletemplate, pkgsecugroup and pkgsecupermission as production environment might differ from other environments due to client changes to permissions.

Project specific rules can still be written in the admin security module. The delivery of the specific rules is independent from the permissions granted from the interface and stored in the above mentioned structures.

Retrieve an environment configuration for debug

If you need to retrieve all permissions configuration from an environment to another, you need tor backup from source environment

all data from structures
- pkgroletemplate - role types on the source environment
- pkgsecugroup - permissions assigned to roles on the source environment
- pkgsecupermission - permissions defined on the source environment
- role - roles defined on the source environment
Security file

You can the restore data from these structures (replace all data) as well as the security file.

This procedure should not be used to deploy new roles to a production environment as you would loose configuration done on target environment.

Wedia Product Documentation

Roles & Permissions