Skip to end of metadata
Go to start of metadata

Matching rules are short expressions that can normalize and match attribute values. Attributes values are normally compared literally, e.g. strings are compared as they come from the resource in a case-sensitive manner. But this is not appropriate for all resources. Some resources use case-insensitive attributes, attributes that can have several equivalent representations (such as URL or LDAP DN) and so on. While this is usually not a problem for ordinary attributes it can be problematic when dealing with identifiers. Failure to detect that two strings match can cause problems during evaluation of identifier uniqueness and identifier allocation. This may undermine significant part of the provisioning logic.

MidPoint allows to optionally specify a matching rule for resource attribute.

Matching rule specification

The matching rule will be used to match individual values of the attribute. E.g. in this case the values of ICF UID attribute will be matched in case-insensitive way.

Matching rules are identified by QName. The design of the matching rules implementation is extensible and it may be possible to add custom matching rules in the future. However currently the set of matching rules is built-in in midPoint product.

Query matching

Note that besides in attribute definitions, matching rules can also be used in queries using the tag <matching>. An example:

Matching rule specification

There are some differences, though. Some matching rules are universally applicable - in attribute definitions as well as in repository queries. Others are usable only in the definitions (like distinguishedName), because there are no suitable normalization algorithms that could be used directly in SQL queries. Yet other ones exist only for the purpose of querying the repository (like the last three in the table below).

Known matching rules

Existing matching rules are summarized in the following table.

All of them have a namespace of http://prism.evolveum.com/xml/ns/public/matching-rule-3.

NameApplicable toUsable in attribute definitionUsable in repository queryDescription
defaultall typesyesyesDefault matching rule compares the values in the default way appropriate for the data type. E.g. strings are compared in a case-sensitive way.
stringIgnoreCaseStringyesyesCase-ignore matching (case-insensitive).
distinguishedNameStringyesnoMatching rule for LDAP distinguished name (DN).
exchangeEmailAddressesStringyesnoA specific matching rule for Microsoft Exchange EmailAddresses attribute consisting of SMTP:/smtp: prefix and email address. It considers the case in the prefix but ignores the case in the email address.
uuidStringyesnoMatching rule for universally unique identifier (UUID). Currently it is (almost) simple case ignore matching.
xmlStringyesnoString matching rule that compares strings as XML snippets. The XML comparison is not schema aware. It will not handle QNames in values correctly. The comparison ignores XML formatting (whitespaces between elements).
polyStringStrictPolyStringN/A (attributes are never PolyString)

yesStrict PolyString matching. Both the original part and the normalized parts are compared.
polyStringOrigPolyStringyesNon-strict PolyString matching. Only the original part is compared.
polyStringNormPolyStringyesNon-strict PolyString matching. Only the normalized part is compared.
strictIgnoreCasePolyStringyes; in repo onlyCase-insensitive version of polyStringStrict. I.e. both original and normalized parts are compared in a case-insensitive way.
origIgnoreCasePolyStringyes; in repo onlyCase-insensitive version of polyStringOrig. May not follow DB indexes.
normIgnoreCasePolyStringyes; in repo onlyCase-insensitive version of polyStringNorm. (Note that because polyStringNorm is itself case insensitive, normIgnoreCase is the same as polyStringNorm.

Applicable to describes to which data types this matching rule can be used. Usable in columns provide information about applicability of the rule.

Note: "yes; in repo only" means that this matching rule is quite special, and can be used really in repository queries. (Technically, there are no corresponding MatchingRule classes.)

  • No labels