UserType

Last modified 15 Nov 2021 14:56 +01:00

OUTDATED

This page is outdated, it contains information that was not updated in a long time. The described functionality may or may not work. Do not rely on information provided on this page.

Description

User object represents a physical user of the system. It differs from the account, as "account" represents a data structure in a target system while "user" represents data structure in midPoint. One user typically haves many accounts. Properties of User object typically describe the user as a physical person. Therefore the user obect defines handful of properties that are commonly used to describe users in the IDM solutions (employees, customers, partners, etc.) Custom extensions are possible by utilizing the "extension" container.

UserType, as all the midPoint objects, is a subtype of ObjectType. Therefore it has all the basic properties such as name and description.

UserType is also a focal type. Therefore it can behave as a "focus" (authoritative object) in midPoint synchronization.

SchemaDoc

Following links can be used to get full an authoritative description of the user object schema:

Release	SchemDoc link
Latest stable	UserType
Development	UserType

Release

SchemDoc link

Latest stable

UserType

Development

UserType

Important Items

User object contains following frequently used items:

Property Type Description

Property	Type	Description
fullName	PolyString optional	Full name of the user with all the decorations, middle name initials, honorific title and any other structure that is usual in the cultural environment that the system operates in. This element is intended to be displayed to a common user of the system. Examples: cpt. Jack Sparrow, William "Bootstrap" Turner, James W. Random, PhD., Vladimir Iljic Lenin, Josip Broz Tito, Chuck Norris
givenName	PolyString optional	Given name of the user. It is usually the first name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was given to the user at birth or was chosen by the user. Examples: Jack, Chuck
familyName	PolyString optional	Family name of the user. It is usually the last name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was inherited from the family or was assigned to a user by some other means. Examples: Sparrow, Norris
additionalName	PolyString optional	Middle name, patronymic, matronymic or any other name of a person. It is usually the middle component of the name, however that may be culture-dependent. Examples: Walker, John, Iljic
nickName	PolyString optional	Familiar or otherwise informal way to address a person. The meaning of this property is to take part in the formatted full name of the person, e.g. William "Bootstrap" Turner. It is not intended to be used as a username or login name. This value is usually changable by the user itself and it defines how the user wants other to address him. Examples: Bootstrap, Bobby The meaning of this property is to take part in the formatted full name of the person, e.g. William "Bootstrap" Turner. It is not intended to be used as a username or login name. This value is usually changable by the user itself and it defines how the user wants other to address him. Therefore it is not ideal for use as an identifier.
honorificPrefix	PolyString optional	Honorific titles that go before the name. Examples: cpt., Ing., Sir
honorificSuffix	PolyString optional	Honorific titles that go after the name. Examples: PhD., KBE
title	PolyString optional	User’s title defining a work position or a primary role in the organization. Examples: CEO, Security Officer, Assistant
preferredLanguage	string optional	Indicates user’s preferred language, usually for the purpose of localizing user interfaces. The format is IETF language tag defined in BCP 47, where underscore is used as a subtag separator. This is usually a ISO 639-1 two-letter language code optionally followed by ISO 3166-1 two letter country code separated by underscore. The languages that do not have coutry-specific variants are usually specified by using a two-letter coutry code ("sk","cs", "tr"). Languages with coutry-specific variants have country-specific subtags ("pt_BR", "zn_CN"). If no value is specified in this property then system default locale is assumed. Examples: en, sk , _ pt_BR_
locale	string optional	Defines user’s preference in displaying currency, dates and other items related to location and culture. The format is IETF language tag defined in BCP 47, where underscore is used as a subtag separator. This is usually a ISO 639-1 two-letter language code optionally followed by ISO 3166-1 two letter country code separated by underscore. The languages that do not have coutry-specific variants are usually specified by using a two-letter coutry code ("sk","cs", "tr"). Languages with coutry-specific variants have country-specific subtags ("pt_BR", "zn_CN"). If not specified then system default locale is assumed. Examples: en, sk, pt_BR
timezone	string optional	User’s preferred timezone. It is specified in the "tz database" (a.k.a "Olson") format. If not specified then system default timezone is assumed. Examples: Europe/Bratislava
emailAddress	string optional	E-Mail address of the user. This is the address supposed to be used for communication with the user. E.g. IDM system may send notifications to the e-mail address.
telephoneNumber	string optional	Primary telephone number of the user.
employeeNumber	string optional	Unique, business-oriented identifier of the employee. Typically used as correlation identifier and for auditing purposes. Should be immutable, but the specific properties and usage are deployment-specific.
employeeType	string optional, multi	Employee type specification such as internal employee, external or partner. The specific values are deployment-specific. However it is generally assumed that this will be enumeration of several type names or codes that define "classes" of users. Even though this property is named "employeeType" due to the historical reasons it is used in a more generic way to mean general type of user. Therefore it can be used to distinguish employees from customers, etc.
costCenter	string optional	The name, identifier or code of the cost center to which the user belongs. Please note that organization objects (OrgType) also have a costCenter property. Therefore it is usual that if a user belongs to an organization the costCenter from the organization is used. Therefore this property is usually used only for users that do not belong to any organization or for users that have different cost center than the one defined by the organization.
organization	PolyString optional, multi	Name or (preferably) immutable identifier of organization that the user belongs to. The format is deployment-specific. This property together with organizationalUnit may be used to provide easy-to-use data about organizational membership of the user. This is multi-valued property to allow membership of a user to several organizations. Please note that midPoint does not maintain ordering in multi-value properties therefore this is not usable to model a complex organization hierarchies. Use OrgType instead.
organizationalUnit	PolyString optional, multi	Name or (preferrably) immutable identifier of organizational unit that the user belongs to. The format is deployment-specific. This property together with organization may be used to provide easy-to-use data about organizational membership of the user. This is multi-valued property to allow membership of a user to several organizational units. Please note that midPoint does not maintain ordering in multi-value properties therefore this is not usable to model a complex organization hierachies. Use OrgType instead.
locality	PolyString optional	Primary locality of the user, the place where the user usually works, the country, city or building that he belongs to. Deployment-specific.
credentials	CredentialsType optional	The set of user’s credentials (such as passwords). This is a container type for various credentials types: passwords, public keys, one-time password scheme identifiers, etc. However, we expect that a password will be the most widely used credential type and that’s actually also the only supported type.
activation	ActivationType optional	User’s activation. e.g. enable/disable status, start and end dates, etc. The content of this property determines if user should be regarded as active or inactive (e.g. disabled)
assignment	AssignmentType optional, multi	Set of user’s assignments. Represents objects (such as roles) or accounts directly assigned to a user. Represents a that the user should have something. See Assignment.
linkRef	ObjectReferenceType optional, multi	Reference to accounts that this user owns or embedded account object (see Object References). This property specifies the linked accounts, that means account that midPoint thinks the user really has. It may be different from what he should have as represented by assignments (see above).[NOTE] .Attention ==== in 2.1.x versions use `accountRef` instead of `linkRef` when referencing accounts ====

fullName

PolyString
optional

Full name of the user with all the decorations, middle name initials, honorific title and any other structure that is usual in the cultural environment that the system operates in. This element is intended to be displayed to a common user of the system.
Examples: cpt. Jack Sparrow, William "Bootstrap" Turner, James W. Random, PhD., Vladimir Iljic Lenin, Josip Broz Tito, Chuck Norris

givenName

PolyString
optional

Given name of the user. It is usually the first name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was given to the user at birth or was chosen by the user.
Examples: Jack, Chuck

familyName

PolyString
optional

Family name of the user. It is usually the last name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was inherited from the family or was assigned to a user by some other means.
Examples: Sparrow, Norris

additionalName

PolyString
optional

Middle name, patronymic, matronymic or any other name of a person. It is usually the middle component of the name, however that may be culture-dependent.
Examples: Walker, John, Iljic

nickName

PolyString
optional

Familiar or otherwise informal way to address a person. The meaning of this property is to take part in the formatted full name of the person, e.g. William "Bootstrap" Turner. It is not intended to be used as a username or login name. This value is usually changable by the user itself and it defines how the user wants other to address him.
Examples: Bootstrap, Bobby
The meaning of this property is to take part in the formatted full name of the person, e.g. William "Bootstrap" Turner. It is not intended to be used as a username or login name. This value is usually changable by the user itself and it defines how the user wants other to address him. Therefore it is not ideal for use as an identifier.

honorificPrefix

PolyString
optional

Honorific titles that go before the name.
Examples: cpt., Ing., Sir

honorificSuffix

PolyString
optional

Honorific titles that go after the name.
Examples: PhD., KBE

title

PolyString
optional

User’s title defining a work position or a primary role in the organization.
Examples: CEO, Security Officer, Assistant

preferredLanguage

string
optional

Indicates user’s preferred language, usually for the purpose of localizing user interfaces. The format is IETF language tag defined in BCP 47, where underscore is used as a subtag separator. This is usually a ISO 639-1 two-letter language code optionally followed by ISO 3166-1 two letter country code separated by underscore. The languages that do not have coutry-specific variants are usually specified by using a two-letter coutry code ("sk","cs", "tr"). Languages with coutry-specific variants have country-specific subtags ("pt_BR", "zn_CN"). If no value is specified in this property then system default locale is assumed.
Examples: en, sk , _ pt_BR_

locale

string
optional

Defines user’s preference in displaying currency, dates and other items related to location and culture. The format is IETF language tag defined in BCP 47, where underscore is used as a subtag separator. This is usually a ISO 639-1 two-letter language code optionally followed by ISO 3166-1 two letter country code separated by underscore. The languages that do not have coutry-specific variants are usually specified by using a two-letter coutry code ("sk","cs", "tr"). Languages with coutry-specific variants have country-specific subtags ("pt_BR", "zn_CN"). If not specified then system default locale is assumed.
Examples: en, sk, pt_BR

timezone

string
optional

User’s preferred timezone. It is specified in the "tz database" (a.k.a "Olson") format. If not specified then system default timezone is assumed.
Examples: Europe/Bratislava

emailAddress

string
optional

E-Mail address of the user. This is the address supposed to be used for communication with the user. E.g. IDM system may send notifications to the e-mail address.

telephoneNumber

string
optional

Primary telephone number of the user.

employeeNumber

string
optional

Unique, business-oriented identifier of the employee. Typically used as correlation identifier and for auditing purposes. Should be immutable, but the specific properties and usage are deployment-specific.

employeeType

string
optional, multi

Employee type specification such as internal employee, external or partner. The specific values are deployment-specific. However it is generally assumed that this will be enumeration of several type names or codes that define "classes" of users.
Even though this property is named "employeeType" due to the historical reasons it is used in a more generic way to mean general type of user. Therefore it can be used to distinguish employees from customers, etc.

costCenter

string
optional

The name, identifier or code of the cost center to which the user belongs.
Please note that organization objects (OrgType) also have a costCenter property. Therefore it is usual that if a user belongs to an organization the costCenter from the organization is used. Therefore this property is usually used only for users that do not belong to any organization or for users that have different cost center than the one defined by the organization.

organization

PolyString
optional, multi

Name or (preferably) immutable identifier of organization that the user belongs to. The format is deployment-specific. This property together with organizationalUnit may be used to provide easy-to-use data about organizational membership of the user.
This is multi-valued property to allow membership of a user to several organizations. Please note that midPoint does not maintain ordering in multi-value properties therefore this is not usable to model a complex organization hierarchies. Use OrgType instead.

organizationalUnit

PolyString
optional, multi

Name or (preferrably) immutable identifier of organizational unit that the user belongs to. The format is deployment-specific. This property together with organization may be used to provide easy-to-use data about organizational membership of the user.
This is multi-valued property to allow membership of a user to several organizational units. Please note that midPoint does not maintain ordering in multi-value properties therefore this is not usable to model a complex organization hierachies. Use OrgType instead.

locality

PolyString
optional

Primary locality of the user, the place where the user usually works, the country, city or building that he belongs to. Deployment-specific.

credentials

CredentialsType
optional

The set of user’s credentials (such as passwords). This is a container type for various credentials types: passwords, public keys, one-time password scheme identifiers, etc. However, we expect that a password will be the most widely used credential type and that’s actually also the only supported type.

activation

ActivationType
optional

User’s activation. e.g. enable/disable status, start and end dates, etc. The content of this property determines if user should be regarded as active or inactive (e.g. disabled)

assignment

AssignmentType
optional, multi

Set of user’s assignments. Represents objects (such as roles) or accounts directly assigned to a user. Represents a that the user should have something. See Assignment.

linkRef

ObjectReferenceType
optional, multi

Reference to accounts that this user owns or embedded account object (see Object References). This property specifies the linked accounts, that means account that midPoint thinks the user really has. It may be different from what he should have as represented by assignments (see above).[NOTE] .Attention ==== in 2.1.x versions use accountRef instead of linkRef when referencing accounts

====

Full list of items can be found by using the SchemaDoc links above.

User Examples

Minimal User

<user>
    <name>jack</name>
    <fullName>Jack Sparrow</fullName>
    <givenName>Jack</givenName>
    <familyName>Sparrow</familyName>
</user>

Rich User

<user>
    <name>morgan</name>
    <fullName>Admiral Sir Henry Morgan</fullName>
    <givenName>Henry</givenName>
    <familyName>Morgan</familyName>
    <nickName>Barbadosed</nickName>
    <honorificPrefix>Admiral Sir</honorificPrefix>
    <title>Privateer</title>
    <preferredLanguage>en_UK</preferredLanguage>
    <locale>en_UK.UTF-8</locale>
    <timezone>America/Jamaica</timezone>
    <emailAddress>morgan@gov.jm</emailAddress>
    <telephoneNumber>+1 876 555 5555</telephoneNumber>
    <employeeNumber>1</employeeNumber>
    <employeeType>FTE</employeeType>
    <organizationalUnit>Government</organizationalUnit>
    <organizationalUnit>Navy</organizationalUnit>
    <locality>Jamaica</locality>
    <credentials>
        <password>
            <protectedString>
                 <clearValue>shiverM3t1mb3rz</clearValue>
            </protectedString>
        </password>
    </credentials>
    <activation>
         <enabled>true</enabled>
    </activation>
</user>

Accounts and Assignments

Please see Assignment and Assigning vs Linking pages.

UserType

Description

SchemaDoc

Important Items

User Examples

Accounts and Assignments

See Also