Common supertype for all identity objects. Defines basic properties that each object must have to live in our system (identifier, name).
Objects consists of identifier and name (see definition below) and a set of properties represented as XML elements in the object's body. The properties are represented as first-level XML elements (tags) of the object XML representation and may be also contained in other tags (e.g. extension, attributes) that are marked by a propertyContainer annotation. The QName (namespace and local name) of the element holding the property is considered to be a property name.
Single-value properties must appear as a none or one instance of the XML element holding the value.
Multi-value properties must appear as none or more instances of the same XML element. Multi-valued properties are regarded as unordered sets. Duplicate values are allowed, but duplicates should not be preserved by the implementations. The implementations should reduce duplicate values to a single value if it is possible and efficient.
If an element for a specific property does not appear in the object it means that the property value is undefined (property does not exists). This is a different state as compared to passing an empty XML element. Empty XML element means that the property exists, but has an empty (null) value. Implementations must be able to handle undefined (non-existent) properties, but may NOT be able to handle empty (null) values. The use of empty (null) values is DISCOURADGED.
It is not mandated by this specification how to pass ordered lists and multi-value properties with duplicates. However it is recommended to use single value properties with appropriate complex XML data structures to hold such data.
The following XML snippet is an example of the object (omitting namespace definitions, but assuming default namespace to be the target namespace of this schema definition):
<user oid="d3adm3a4" version="42"> <name>foobar</name> <extension> <foo:geekName>F00 B4r</foo:geekName> <org:guild>Societus Geekus Europeus</org:guild> <org:guild>Basset User Group</org:guild> <pet:pet><pet:species>dog</pet:species><pet:breed>basset</pet:breed><pet:name>Doggie</pet:name></pet:pet> <pet:pet><pet:species>mouse</pet:species><pet:breed>logitech</pet:breed><pet:name>Mousee</pet:name></pet:pet> <com:shoppingPreferences> <com:tShirt><com:size>XXL</com:size><com:color>#000000</com:color></com:tShirt> <com:tie><com:preference>no thanks</com:preference></com:tie> </com:shoppingPreferences> </extension> <fullName>Foo Bar</fullName> <givenName>Foo</givenName> <familyName>Bar</familyName> </user>
The above example describes an object with identifier "d3adm3a4", name "foobar" and type defined by its top-level element User that corresponds to URI "http://midpoint.evolveum.com/xml/ns/identity/1#User". The object has 7 properties. Three of them are standard properties defined by this schema:
Standard properties "fullName", "givenName" and "familyName" in default namespace. These are single-valued string properties.
All the other properties are non-standard "extended" properties, but they are considered equal to the standard attributes. They are quarantined in the <extension> tag only to avoid XSD unique particle attribution (UPA) problems. In the above example the non-standard properties are:
Property "geekName" in namespace defined by "foo" prefix. This is also single-valued string property.
Multi-valued non-standard property "guild". It is a string property with multiple values. Multiple values are represented by providing multiple instances of XML elements in the document. Such properties are typically used for roles, groups, etc.
Complex property "pet". This property is defined by complex XML type, using XML sub-elements to represent structured data. Note that the use of XML attributes is discouraged in the properties, although it might be possible in some cases. This is also multi-valued property.
Complex property "shoppingPreferences". This property is using complex XML type to form a structure of XML elements to represent data. This is a single-valued property. Note that the sub-elements "tShirt" and "tie" are NOT considered to be properties.
QName-URI mapping:
For the purpose of this schema and all components that are using it, URIs and QNames are considered equivalent. This is required by WWW architecture and also helps avoid some drawbacks and bugs in XML-related implementations that usually do not deal QNames well.
The QNames are mapped to URIs by concatenating namespace URI and a local name. If URI does not end with slash (/) or hash (#) character, slash is concatenated to the URI before adding the local name. The URI-QName mapping is the reverse process.
Name | Type | Multiplicity | Description |
---|---|---|---|
name |
property PolyStringType |
[0,1] | Human-readable, mutable name of the object. |
description |
property string |
[0,1] | Free-form textual description of the object. |
fetchResult |
property OperationResultType |
[0,1] | Result of the operation that fetched this instance of the object. |
extension |
container ExtensionType |
[0,1] | Container that provides generic extensibility mechanism. |
parentOrgRef |
reference ObjectReferenceType |
[0,-1] | Set of the orgs (organizational units, projects, teams) that the object relates to. |
trigger |
container TriggerType |
[0,-1] | Defines triggers for an object. |
metadata |
container MetadataType |
[0,1] | Meta-data about object creation, modification, etc. |
tenantRef |
reference ObjectReferenceType |
[0,1] | Reference to the tenant to which this object belongs. |
Flags: RAM
Multiplicity: [0,1]
Human-readable, mutable name of the object. It
may also be an identifier (login name, group name).
Should be unique in the respective context of
interpretation. E.g. the name of the UserType subtype
should be unique in the whole system.
The name of the AccountType subtype should be unique in the
scope of resource (target system) that it belongs to.
This 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 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).
Name is mutable. It can change any time. However, a special
handling may be needed in some cases (e.g. "rename" provisioning flow).
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.
Flags: RAM
Multiplicity: [0,1]
Free-form textual description of the object.
Flags: RAM
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 objets). 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.
Flags: dyn,RAM,runtime
Multiplicity: [0,1]
Container that provides generic extensibility mechanism.
Almost any extension property can be placed in this container.
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.
Flags: RAM
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).
Flags: RAM,runtime
Multiplicity: [0,-1]
Flags: RAM,runtime
Multiplicity: [0,1]
Meta-data about object creation, modification, etc.
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
compted it is also stored in the repository due to performance reasons.