Resource Object Types
By resource object we understand any object on the resource that is visible to midPoint. These are usually account objects but may also be a wide variety of group types, resource-specific low-level roles, privileges, organizational units, configuration objects, etc. The handling of each type of these objects has to be carefully defined.
Kind, Intent and Object Class
MidPoint identifies each type of resource object by using a (kind, intent) tuple. I.e. each resource object has a kind and an intent. Kind defines what the object is, intent specified how the object behaves.
On the other hand, 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 presented to midPoint by the connector.
But midPoint usually does not know what to do with a specific object class, e.g. an LDAP objectclass inetOrgPerson.
Therefore, midPoint sorts out the object class to kind and intent as specified above.
MidPoint then known quite well what to do with (e.g.) default account.
See Kind, Intent and ObjectClass page for more details.
The Definition
Object type definition specifies how a given object type on the resource should look like and how it should behave.
The definition is identified by the (kind, intent) tuple.
E.g. there is usually at least one definition for default account object type (kind account, intent default).
The definition specifies what Object Class to use for such objects, how to handle the attributes, how to determine attribute values, etc.
The resource object definition specified using the objectType element in schemaHandling section.
Identification and General Properties
The following items identify the object type and provide its general description.
| Item name | Description | Default | Further information |
|---|---|---|---|
|
Kind of the resource object. |
|
|
|
Intent of the resource object. |
|
|
|
Display name of the resource object type. This human-readable string is used in GUI and other tools when displaying information about resource objects. |
||
|
Free-form textual description of the object type. |
||
|
Technical documentation of the object type. |
||
|
Lifecycle state of the object type definition: whether it is only a draft, or proposed, active, deprecated, archived, and so on. |
|
|
|
An indication whether the resource object type is the default type for the given object kind and for the given object class on the resource. |
|
|
|
These are used to define object type inheritance. |
||
|
Frequently Used Type-Level Configuration Features
The following are the most-often used configuration items that are relevant for the whole object type.
| Item name | Description | Further information |
|---|---|---|
|
Delineation of the resource object type. MidPoint must know what resource objects belong to the object type and what do not. The most typical (and obligatory) criterion is the object class. Other criteria, e.g., a filter based on attributes, can be used as well. |
|
|
Focus objects (users, roles, orgs, and so on) corresponding to given resource object type.
If not specified, |
|
|
Drives automatic marking of shadows, e.g., as protected objects.
Such objects will never be touched by midPoint.
MidPoint will not synchronize them, will not reconcile them and will not modify them.
This is usually used to protect system accounts such as |
|
|
Specifies how to locate an owner (user, role, org, …) of the resource object (account, role, org. unit, …). |
|
|
Specifies how midPoint should behave in specific situations, e.g., when it encounters a newly created or recently deleted account. |
Item-Level Configuration
The following configuration items are relevant to individual parts of a resource object of given type.
| Item name | Description | Further information |
|---|---|---|
|
Attribute definitions that describe the handling of attributes that form a particular object type. The administrator can define a specific data and behavior for each attribute. |
|
|
How credentials (typically the password) are handled for this object type. |
|
|
Defines how the activation-related information, like the administrative status (enabled/disabled), time validity (from/to), or even the mere existence of the resource objects should be handled. |
|
|
Definition for different behaviors are handled for the resource. Defines how the last login timestamp synchronization is handled for the resource. (If it has the corresponding capability.) |
Other Type-Level Configuration Features
| Item name | Description | Further information |
|---|---|---|
|
Used when there are multiple objects of given type for a single focus, e.g., a user. |
|
|
Defines the parameters of iterative cycles.
Such cycles are used e.g. when determining a unique identifier values from non-unique inputs.
E.g. a iteration cycle may be used to try account identifiers |
|
|
Specification of dependencies of this object type on other type or types. |
|
|
Specification of the volatility of this object type. (Note that the volatility can be specified also at the attribute level.) |
|
|
Default operation policy for those operations that do not have their behavior specified explicitly via object marks. This is used to restrict some types of operations for given object type, like making it managed by midPoint solely, or the other way, managed from the resource only. |
|
|
Security policy for this object type. Used to define the required complexity of passwords (when generating or checking them) as well as the storage configuration for cached passwords. |
|
|
Capabilities specific to this object type. |
|
|
Caching configuration specific to this object type. |
|
|
Specification of the way how projections are handled on the resource. This defines the ways how assignments are enforced and so on. |
|
|
Inbound mappings and tolerance setting for auxiliary object class information. |
| The schema handling is additive to a resource schema definitions. This means that there is no need to define all the attributes from the object class in the schema handling section. The attributes that are defined in the object class and are not mentioned in schema handling are taken from the object class definition without any change. |