ResourceType (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.

• 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: dyn,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

  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.

• operationExecution

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  Description of recent operations executed on this object (or related objects, e.g. shadows in case of a focal object). The number of operations to be kept here is configurable.

• 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 assignment. (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.

• operationalState

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Structure containing metadata about operational state of the resource. E.g. if resource is up or down, when it was last checked, etc. It should not contain configuration, just the operational state.

• connectorRef

  Flags: RAM

  Multiplicity: [0,1]

  Reference to the connector that implements specified resource. Connector reference is MANDATORY. Although the schema does not enforce it (due to various JAXB reasons), exactly one of the connector or connectorRef MUST be present in the resource object.

• connectorConfiguration

  Flags: dyn,RAM,runtime

  Multiplicity: [1,1]

  Resource configuration (hostname, port, ...). Specific for each resource type. TODO This element belongs to ResourceType and should not be used elsewhere. This is a top-level element to make the implementation (JAXB marshal/unmarshal) easier.

• additionalConnector

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of additional connector(s). Additional connectors may add capabilities to this resource, e.g. scripting capability or capability for reading the exported resource content.

• namespace

  Flags: RAM,runtime

  Multiplicity: [0,1]

• schema

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Schema for resource objects. This element contains the XSD-formatted definition of resource schema. It defines data types for accounts, groups, roles, entitlements, organizational units or any other objects related to identity management that the resource supports. Resource schema is only available at run-time and can be different for every resource instance, even for resource instances of the same type. It is supposed to be dynamically interpreted in run-time. Schema defines data types (XSD types), but it does NOT define how these types are handled. E.g. it defines attributes and object class for inetOrgPerson, that it has "cn" attribute which is multi-valued string, etc.

• schemaHandling

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specification of handling details for resource schema. E.g. read-only or read-write attributes, account object classes, etc. This element belongs to ResourceType and should not be used elsewhere. This is a top-level element to make the implementation (JAXB marshal/unmarshal) easier.

• capabilities

  Flags: RAM,runtime

  Multiplicity: [0,1]

  TODO: update The capabilities supported by the resource, including both native capabilities of the connector and simulated capabilities. If this element is not present at all, the value of nativeCapabilities element is assumed. The value of this element is not generated, it should be set by the administrator. The value of this element indicates administrator decisions what connector capabilities to use, what capabilities to simulate and how to simulate them. The values of this element indicates what the connector is allowed to do.

• scripts

  Flags: RAM,runtime

  Multiplicity: [0,1]

• projection

  Flags: RAM,runtime

  Multiplicity: [0,1]

• consistency

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Configuration of consistency mechanisms. This may include configuration of high-level operation retries and similar technical configuration.

• caching

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Definition of object attribute caching policies.

• synchronization

  Flags: RAM,runtime

  Multiplicity: [0,1]

• business

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Configuration of resource "business" aspects such as workflow parameters, notifications, approvers, owners, etc.