Kind, intent and ObjectClass are three terms that are very frequently used in midPoint. These terms define a type of resource object (or shadow). The kind and intent are midPoint terms. They define how midPoint is using the object, how midPoint understands its role in the system. The objectClass is a native type by which the resource recognizes the object.
Kind and Intent
MidPoint identifies useful types of resource objects by using a (kind, intent) tuple. I.e. each useful resource object has a kind and an intent. Kind defines what the object is, intent specified how the object behaves.
MidPoint supports several kinds of resource objects:
- Account resource objects represent identity of a person, either physical such as computer user or virtual such as administrator, root, daemon or similar special-purpose identities. Accounts can be linked to the User objects.
- Entitlement resource objects represent groupings or privileges of an account. Entitlement resource objects represent groups, resource-specific roles, access permissions or even organizational unit membership. Entitlements are associated to an account.
- other kinds of resource objects may be introduced later (e.g. organizational unit)
Kind of a resource object is mostly fixed and it is quite difficult to change. However the kind is usually determined by the fixed type of the object (object class) and does not need to be changed. The list of resource object kinds is not extensible as their meaning is used in the midPoint IDM logic.
Intent of a resource object describes its intended usage. E.g. users may was to have one default account for normal work, they might have another quite different admin account for system administration and yet another testing account. The "default", "admin" and "testing" are account intents. Other IDM systems use the term account types for this, but intent is more generic term and may apply to other resource objects kinds not just accounts (e.g. to entitlements).
Intents are almost entirely custom. It is expected that intents will be defined specifically for each deployment. There is only a single standard intent defined:
default. As the name suggests this is the default intent and it is used if no intent is specified.
Kind and intent are midPoint internal terms. They are not passed to the connector. They are translated to the object class which is then passed to the connector.
Object Class is a type of the object how the resource understands it. It is therefore a "technical" type of the resource object. Object classes are defined by the Resource Schema and are presented to midPoint by the connector. MidPoint has a very little control over object classes. The object classes define a reality, what types of objects the resource can handle. Object classes can reflect the real object class defined by the resource such as
inetOrgPerson LDAP object class. Or the object classes can be "virtual" and introduced by the connector such as ICF
__ACCOUNT__ object class (which is presented in midPoint as
Object class is an term used by midPoint connectors. Therefore object class definition is passed to the connector.
Kind, Intent and Object Class in MidPoint
Object class is what resource understands. When midPoint reads an object it will know its object class. If midPoint creates an object it has to define a specific object class. Therefore object class defines how the object looks like. However midPoint usually does not know what to do with a specific object class, e.g. an LDAP objectclass
inetOrgPerson. This object class usually defines an account but the details can vary from deployment to deployment. Therefore midPoint cannot provide any fixed association between object class and its usage. Therefore midPoint sorts out the object class to kind and intent as specified above. While midPoint does not know how to handle objects of object class
inetOrgPerson, midPoint knows quite well what to do with default account objects. Default account objects are presented as (kind=account, intent=default) in midPoint.
Therefore midPoint maps object classes to (kind, intent) tuples. The mapping on the outbound side is defined in Resource Schema Handling. This maps (kind, intent) to object class. In this case midPoint has a lot of information about the intended use and type of the object in this case and the information is quite reliable. This configuration can be very declarative and straightforward. The mapping on the inbound side is defined in Synchronization Configuration. This maps object class to (kind, intent) tuple.This mapping is not a very reliable and straightforward because all the midPoint really knows about the object is its object class and attributes. Therefore this configuration needs to be much more flexible and allow some kind of "guesswork" to correctly sort out the object.
|Usual LDAP account||account||default||ri:MiscInetOrgPersonObjectClass||The LDAP account that is used for most of the accounts. The account types that are by default assigned to users. "Normal" account. E.g. the mappings can place such accounts into |
|Testing LDAP account||account||test||ri:MiscInetOrgPersonObjectClass||The LDAP account used for testing purposes. As this has a different intent then a different set of mappings can be defined for this account type. E.g. the mappings may place it in a different |
|Legacy LDAP account||account||legacy||ri:MiscPersonObjectClass||The LDAP account using |
|Usual CSV account||account||default||ri:AccountObjectClass||Just a simple CSV file account. The CSV connector does not have a concept of object classes therefore the connector defines only a single virtual "__ACCOUNT__" ICF object class.|
|LDAP group||entitlement||group||ri:MiscGroupOfNamesObjectClass||LDAP group that is normally used for grouping LDAP accounts. It is using |
|LDAP group (unique)||entitlement||group-unique||ri:MiscGroupOfUniqueNamesObjectClass||Alternative LDAP group that is used by some applications. It is using |
|Custom privilege||entitlement||priv||ri:MiscPrivObjectClass||Some custom privilege defined in the resource and supported by the connector.|
- kind and intent are kept in the shadow (picture)