Open questions related to metadata processing

Last modified 12 Mar 2021 10:22 +01:00

Data derived implicitly i.e. not in context of a mapping

An example is deriving roleMembershipRef value from an assignment. We should have some rules (e.g. what to propagate and how) for this case.

In the current proposal it could be resolved like this (in e.g. user template):

<objectTemplate ...>
    <name>User template</name>
        <metadataTemplateRef oid="123456" />


<objectTemplate oid="123456">
    <name>RoleMembershipRef metadata template</name>

Metadata mappings attached to roleMembershipRef would be interpreted by the assignment evaluator, unlike metadata mappings attached to "regular" data items that are interpreted primarily by mapping evaluator.

Where normal metadata mappings get sources from input values that enter data mapping, metadata mappings for roleMembershipRef would get their sources from input values that are used to compute particular roleMembershipRef value:

  • primary assignment,

  • assignments on the path (maybe),

  • sources for all conditions that were evaluated during roleMembershipRef value computation,

  • sources for all other expressions that were evaluated (e.g. filters in target resolution) (maybe).

This is quite complex issue. But, overall, it seems that using roleMembershipRef definition in an object template looks like a good idea.

Metadata value consolidation (conflicting values)

What if we are merging two equal values (e.g. for roleMembershipRef) carrying different metadata?

Idea: use the same metadata mapping used to combine value from different items.

Note: Sometimes we want to combine the values into one value, but sometimes we do not. E.g. we want to know exactly that the same value came both from HR and we learned it from federation, we want to know all the details when that happened and so on. Therefore we would like to keep two instances of the same value with different metadata. However, we consider this to be advanced functionality. This needs to be configurable, probably separately for each item. And there may also be implementation obstacles. E.g. midPoint must not ignore metadata when comparing values, but it must still be able to consolidate the values if needed. This is very likely to complicate midPoint projector code at many places.

Metadata value consolidation (conflicting mappings)

What if different mappings provide different values for single metadata item for a given data value? (We could perhaps apply existing data consolidation practices here.)

Metadata Authorizations

Two related, but different questions:

  • How to decide which metadata show to users? We need at least a partial solution for this in midpoint 4.2.

  • How metadata content influences access control? E.g. show only items where sensitivity=public. We can solve this problem later, but it is nice to think about it now.