Context

Since , 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:

Starting from , 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.

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.

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.

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

From an end-user perspective

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

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 https://crossmedia.atlassian.net/wiki/spaces/WD/pages/1629978625/Setting+Up+Permissions+and+Roles#Identifying-eligible-structures to understand how those tags must be defined.

Role templates

A role template defines:

  1. A set of permissions that a role will inherit by extending the role template.

  2. A mechanism to ensure some default permissions (or lack of permissions) cannot be overridden for a role.

  3. Default available digital assets renditions for roles.

  4. 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 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:

  1. 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

  2. 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

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.