ShadowType (Object Definition)

Items

• name

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Human-readable, mutable name of the object. It may also be an identifier (login name, group name). It is usually unique in the respective context of interpretation. E.g. the name of the UserType subtype is usually unique in the whole system. The name of the ShadowType subtype is usually unique in the scope of resource (target system) that it belongs to.

  The name may not be human-readable in a sense to display to a common end-user. It is intended to be displayed to IDM system administrator. Therefore it may contain quite a "ugly" structures such as LDAP DN or URL.

  Name is mutable. It is considered to be ordinary property of the object. Therefore it can be changed by invoking usual modifyObject operations. However, change of the name may have side effects (rename process).

  Although name is specified as optional by this schema, it is in fact mandatory for most object types. The reason for specifying the name as optional is that the name may be generated by the system instead of supplied by the clients. However, all objects stored in the repository must have a name.

• description

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Free-form textual description of the object. This is meant to be displayed in the user interface.

• documentation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  AsciiDoc-formatted technical documentation of the object.

• subtype

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Type of the object. It is used to distinguish what a specific object represents. Whether it is a different kind of organizational unit, project, team, or different kind of user, etc.

• fetchResult

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Result of the operation that fetched this instance of the object. It is mostly used to indicate that the object is not complete or there is some problem with the object. This is used instead of exception if the object is part of larger structures (lists as in list/search operations or composite objects). If not present then the "SUCCESS" state is assumed.

  This field is TRANSIENT. It must only be used in runtime. It should never be stored in the repository.

• extension

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Extension container that provides generic extensibility mechanism. Almost any extension property can be placed in this container. This mechanism is used to extend objects with new properties. The extension is treated exactly the same as other object properties by the code (storage, modifications, etc), except that the system may not be able to understand their meaning.

• parentOrgRef

  Flags: RAM,oper

  Multiplicity: [0,-1]

  Set of the orgs (organizational units, projects, teams) that the object relates to. This usually means that the object belongs to them but it may have other meanings as well (e.g. user manages an organizational unit).

• trigger

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  Triggers for this object. They drive invocations of corresponding trigger handlers at specified time.

• metadata

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Meta-data about object creation, modification, etc.

• tenantRef

  Flags: RAM,oper

  Multiplicity: [0,1]

  Reference to the tenant to which this object belongs. It is a computed value set automatically by midPoint. It is determined from the organizational structure. Even though this value is computed it is also stored in the repository due to performance reasons.

• lifecycleState

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Lifecycle state of the object. This property defines whether the object represents a draft, proposed definition, whether it is active, deprecated, and so on.

  There are few pre-defined lifecycle states. But custom lifecycle states may also be defined. Pre-defined lifecycle states are:

  • draft: Definition of the new object in progress. The object is NOT active. The definition may change at any moment. It is not ready yet.
  • proposed: Definition of a new object is ready for use, but there is still a review process to be applied (e.g. approval). The object is NOT active. However the definition should not change in this state.
  • active: Active and working definition. Ready to be used without any unusual limitations.
  • deprecated: Active definition which is being phased out. The definition is still fully operational. But it should not be used for new assignments. E.g. it should not be requested, it should not be approved, etc.
  • archived: Inactive historical definition. It is no longer used. It is maintained only for historical, auditing and sentimental reasons.
  • failed: Unexpected error has occurred during object lifecycle. Result of that event is that the object is rendered inactive. The situation cannot be automatically remedied. Manual action is needed.
  TODO adapt this definition regarding the "simulations" feature.

• operationExecution

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  Description of recent operations executed on this object (or related objects in special cases). The number of operations to be kept here is configurable.

• lensContext

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Model context describing executed operation

• policySituation

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  The policy situation(s) of this object. The situations are result of evaluation of the policy rules. This property is recorded for each object and can be used for reporting, diagnostics, target selection in certification campaigns, etc.

• triggeredPolicyRule

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  Triggered policy rules for this object. (Not necessarily complete; subject to specified storage strategy.) This is EXPERIMENTAL functionality. It is possibly to change in the near future.

• policyException

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Recorded exception from a policy rule. The exceptions that are approved are recoded here to avoid re-evaluating and re-approving them all the time. This is EXPERIMENTAL functionality. It is likely to change in the near future.

• diagnosticInformation

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Diagnostic information attached to this object.

• indestructible

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Protection against accidental deletion. If set to true then this object cannot be deleted. If the object needs to be deleted then it has to be modified first to reset this flag.

• effectiveMarkRef

  Flags: RAM

  Multiplicity: [0,-1]

  Object marks assigned to the shadow.

• policyStatement

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Policy statements to manually add or exclude effective marks of shadow.

• effectiveOperationPolicy

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Effective provisioning policy derived from Shadow marks and resource configuration.

• resourceRef

  Flags: RAM

  Multiplicity: [0,1]

  Reference to a resource that this resource object shadow belongs to.

• shadowLifecycleState

  Flags: RAM,runtime,AVals:7

  Multiplicity: [0,1]

  The state in the shadow lifecycle. Always related to the current point of time, regardless of the point-in-time setting in get/search operation options. (E.g. an account retrieved with the point-in-time = future that has a pending DELETE operation will be returned with dead=true, but shadowLifecycleState will be reaping.) Currently TRANSIENT, i.e. it is not stored in the repository.

• dead

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Description of operation during the processing of account failed.

• deathTimestamp

  Flags: RAM,runtime

  Multiplicity: [0,1]

  When we learned about the fact that the shadow is dead? The reason behind this property is to be able to distinguish "freshly dead" shadows so that full synchronization may be invoked if this timestamp is after fullSynchronizationTimestamp. (In the future, though, we should make synchronization reactions more "declarative" so that all dead shadows could be synchronized. But that is a longer-term plan.)

• pendingOperation

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Description of an operation which execution is pending for this shadow. This may be asynchronous operation in progress. E.g. operation that has to be manually completed by human operator. It may also be operation that could not be completed because there was a temporary error while communicating with the resource. There may be also operations that are in fact already executed, but we have not yet received the feedback. Or operations that are executed but are still kept in the shadow for review by midPoint administrator.

• synchronizationSituation

  Flags: RAM,runtime,AVals:5

  Multiplicity: [0,1]

  The most recent synchronization situation. Regardless of the channel. This simple enumeration property is used for (indexed) search of shadows in certain situation. It does not provide any further details. More details can be found in the "synchronizationSituationDescription" property.

• synchronizationTimestamp

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The timestamp of the most recent synchronization. Regardless of the channel or result. It does not provide any further details. More details can be found in the "synchronizationSituationDescription" property.

• fullSynchronizationTimestamp

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The timestamp of the most recent full synchronization. Regardless of the channel or result. It does not provide any further details. More details can be found in the "synchronizationSituationDescription" property.

• synchronizationSituationDescription

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Complex description of synchronization situations. This is multi-valued property and it should store only a single value for each channel (the most recent one). All the older values should be removed on each update.

• correlation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  State of the shadow correlation process. It contains statistical data (e.g. start/end timestamps), result of the (last) correlation - determined situation, candidate owner(s), performer OIDs and their comments - as well as correlator-specific data, like ID Match request and reference IDs. Relevance of the data: The data are deleted when the new correlation process starts after the previous one ended. This fact is determined by checking that the correlationEndTimestamp (set by the previous correlation process) has a non-null value. However, until that time, we must keep the data intact. For example, ID Match correlation typically uses correlatorState/referenceId property as a kind of unique user identifier that is to be used in an inbound mapping.

• objectClass

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The reference to a type definition for this object. The reference should point to the object class definition (complex type definition in resource schema). The attributes contained in the "attributes" element below are expected to comply with the type definition specified in this element (with addition of auxiliary object class definitions). Formally, minOccurs is 0 here but unless a reasonable default is provided, the value must be present.

• primaryIdentifierValue

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Value of the primary (unique) identifier; converted to a string if it's of a different type.

• auxiliaryObjectClass

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  The reference to additional type definitions for this object. The reference should point to object class definition (complex type definition in resource schema) and this definition should be marked as auxiliary. The attributes contained in the "attributes" element below are expected to comply with the type definition specified in the objectClass element merged with definitions specified in this element.

• kind

  Flags: RAM,runtime,AVals:4

  Multiplicity: [0,1]

  Kind of a shadow. This means the type of shadow use. E.g. an account, entitlement, etc.

• intent

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The intended usage type or purpose of the object. E.g. for accounts it may be "user", "admin", "test".

• tag

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Tag value used to discriminate multiple accounts that have the same resource+kind+intent combination.

• protectedObject

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Protected shadows cannot be changed. They are out of IDM control. This is only informational property. Changing it will have no effect on whether object is protected or not. Object protection is a strict policy that cannot be easily overridden. This is "virtual" property. It is not stored in the repository.

• ignored

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Ignored shadows will not be processed during synchronization.

• assigned

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Set to true if the object is "legally" assigned, i.e. if there is a valid assignment for this object. It shows the value from the last recompute of the object.

• exists

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Set to true if the object is known to exist on the resource. There may be shadows for objects that do not exist yet (e.g. create operations in progress) or shadows for objects that we known nothing about yet.

• iteration

  Flags: RAM,runtime

  Multiplicity: [0,1]

• iterationToken

  Flags: RAM,runtime

  Multiplicity: [0,1]

• attributes

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Attribute values from the resource. The values may be freshly fetched from the resource or cached. The set of attributes may be empty, may provide a complete copy of the resource object or anything in between. This depends on the implementation of the caching and fetching strategy, configuration of the provisioning subsystem or operation that was invoked. When this object is stored, attribute set will contain attribute values that are (persistently) cached from the resource. In the normal case, there should be at least attributes that identify the resource object on the resource (identifiers). This will be a single attribute in a normal case, something like uid, username, DN, etc. But if a single attribute is not enough to identify the account, more than one attribute may be present. There also may be no attributes. This can happen e.g. if IDM system knows that user should have account on the resource, but the account is not yet created and no identifier is yet assigned to it. This schema does not distinguish which attributes are identifiers and which are ordinary attributes. That can be learned from the resource schema provided by resource or resource connector. Motivation: Resource schema is dynamic, the attribute that is identifier for a specific object may be different for different resources, even if the resources are of the same type (e.g. directory servers with different LDAP schema). And we do not really need to know which of the attributes is identifier in the compile-time. Knowing that in run-time is enough. Please note that this may be out of sync with regard to the resource. In some operations (e.g. lookup) it will be only milliseconds old, but in case of stored cached values this may be days or even weeks old value. Even though there is a single extensible element "attributes", we do not want to put its content directly to the body of resource object. Doing so will cause problems with UPA rule and it will effectively prohibit the the of type replacement extensibility on this object.

• association

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  TODO

• activation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  TODO For more details see the ActivationType documentation.

• credentials

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The set of account credentials (such as passwords).

• cachingMetadata

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The shadow is essentially a bunch of metadata and cached data about the actual resource object. This caching metadata structure describes when the cached data were retrieved - therefore how fresh they are. For now the cachingMetadata are not stored in the repository. This is now a "virtual" and "transient" property filled in when the full shadow is retrieved from the resource. Later on this can get a more proper meaning when we implement full attribute caching.