Attribute Limitations

Last modified 10 Jan 2025 17:21 +01:00

MidPoint administrator can override various features related to an attribute.

Ignoring the Attribute

By setting the ignore flag, the attribute will effectively disappear. The attribute will still be passed between midPoint and the resource, but the GUI and other parts of midPoint logic will pretend that it is not there.

Changing Multiplicity

The multiplicity of an attribute is usually determined by the schema which is generated by the connector. However, the connector might provide a wrong schema.

Or, more commonly, the schema is used differently as is formally defined. Perhaps the most common case is LDAP. Most LDAP attributes are defined as multivalued while vast majority of systems use them as single-valued. The multiplicity override can be used to let midPoint think that these attributes are in fact single-valued.

To override multiplicity, minOccurs and/or maxOccurs property is to be used.

Changing Access

Finally, the administrator may change the access to particular attribute. This is useful again if the schema is wrong, or if the administrator wants to restrict access beyond the level provided by the connector. For example, they can make the attribute read-only even if the connector can both read and write the attribute value.

The access limitation consists of three boolean switches:

  • read: The attribute can be read.

  • add: The attribute can be set when creating a resource object. Useful for attributes that can be set only once.

  • modify: The attribute can be set when updating a resource object.

An Example

Attribute limitation example
<attribute>
    <ref>ri:cn</ref>
    ...
    <limitations>
        <minOccurs>1</minOccurs>
        <maxOccurs>1</maxOccurs>
        <access>
            <add>true</add>
            <read>true</read>
            <modify>false</modify>
        </access>
    </limitations>
    ...
</attribute>

The attribute is now mandatory, single-valued, and it can be read and provided on object creation, but not updated afterwards.

Layers

The limitations can be expressed for several layers. Currently there are two layers defined:

  • Presentation layer is aimed at the GUI and other forms of external data presentation such as an application behind a REST service.

  • Model layer defines midPoint internals. It is applied to mappings, internal schema validations, etc.

Separate set of limitations can be configured for each layer. This is often used to hide some attributes in the GUI while compute them in the model. Therefore such attribute needs to be ignored in the GUI but it has to be read-write in the model.

The following example illustrates such configuration.

A limitation that does not specify any layer applies to all the layers. The other limitations may modify that.

Attribute limitation with layers
<attribute>
    <ref>ri:cn</ref>
    ...
    <limitations>
        <minOccurs>1</minOccurs>
        <maxOccurs>1</maxOccurs>
        <access>
            <add>true</add>
            <read>true</read>
            <modify>true</modify>
        </access>
    </limitations>
    <limitations>
        <layer>presentation</layer>
        <ignore>true</ignore>
    </limitations>
    ...
</attribute>
Was this page helpful?
YES NO
Thanks for your feedback