Activation
The term activation is used in midPoint to denote a set of properties that describe whether the user is active. This includes properties that describe whether the user is enabled, disabled, archived, since when he should be enabled, to what date he should be active and so on.
|
Activation is a generic and powerful concept
The activation is a concept that usually applies to users and accounts. But in midPoint the term has much wider applications. Also roles, organizational units and even individual assignments can have individual activation properties. E.g. a role may be valid until the end of year (when next role review is scheduled). Or the user may get a role just for two weeks while his colleague is on vacation. There are many possibilities how to use this concept to create a very dynamic configuration. |
The activation in itself is multi-dimensional and quite complex. It is composed from several properties that may change in somehow independent and somehow inter-dependent way. The best way to explain this is to describe the meaning and behavior of individual properties.
Administrative Status
Administrative status defines the "administrative state" of the object (user). I.e. the explicit decision of the administrator.
If administrative status is set, this property overrides any other constraints in the activation type. E.g. if this is set to "enabled" and the user is not yet valid (according to validity below), the user should be considered active. If set to "disabled" the user is considered inactive regardless of other settings.
Therefore this property does not necessarily define an actual state of the object. It is a kind of "manual override". In fact the most common setting for this property is to leave it unset and let other properties determine the state.
If this property is not present then the other constraints in the activation type should be considered (namely validity properties, see below).
If the administrative status is not present and there are no other constraints in the activation type or if there is no activation type at all then the object is assumed to be "enabled", i.e. that the described concept is active. Unless the activation is constrained by the object lifecycle (see below).
| Value | Icon example | Description |
|---|---|---|
no value |
No explicit override. Other activation properties determine the resulting status. |
|
|
|
The entity is active. It is enabled and fully operational. |
|
|
The entity is inactive.
It has been disabled by an administrative action. |
|
|
The entity is inactive.
It has been disabled by an administrative action. |
Since 4.8, the archived state is deprecated.
It will be no longer put into effectiveState property, and it is recommended to avoid using it in administrativeStatus as well.
It is replaced by the lifecycle state.
Its removal is planned for 4.9.
|
Validity
Validity refers to state when the object is considered legal or otherwise usable.
In midPoint the validity is currently defined by two dates: the date from which the object is valid (validFrom) and the date to which an object is valid (validTo). When talking about users these dates usually represent the date when the contract with the user started (hiring date) and the date when the contract ends.
The user is considered valid (active) between these two dates.
The user is considered inactive before the validFrom date or after the validTo date.
It is perfectly OK to set just one of the dates or no date at all.
If any date is not set then it is assumed to extend to infinity.
E.g. if validFrom date is not set the user is considered active from the beginning of the universe to the moment specified by the validTo date.
The validity is overridden by the administrative status. Therefore if administrative status is set to any non-empty value then the validity dates are not considered at all.
Object Lifecycle
|
Since 3.5
This functionality is available since version 3.5.
|
Activation is also influenced by object lifecycle. The object behaves normally in active and deprecated lifecycle states.
In these states the object activation is determined by the administrative status and validity.
Object is considered to be non-active in any other lifecycle states (draft, proposed, archived, failed and any other custom state).
If the object is in any of these states then the setting of the administrative status and validity does not matter at all.
The object is always seen as effectively disabled or archived (since 4.8 only disabled).
Effective Status
Effective status defines the "effective state" of the object. Simply speaking it is a read-only property that tells whether the user should be considered active or inactive. The effective status is the result of combining several activation settings (administrative status, validity dates, etc.).
The effective status holds the result of a computation, therefore it is kind of VIRTUAL property that is recomputed every time the status changes. The effective status should not be set directly. The effective status can be changed only indirectly by changing other activation properties.
The effective status is the property that is used by majority of midPoint code when determining whether a particular object is active or inactive. This property should always have a value in a normal case. If this property is not present then the computation haven’t taken place yet.
| Value | Description |
|---|---|
no value |
Not yet computed. Should not happen under normal circumstances. |
|
The entity is active. |
|
The entity is inactive (temporary deactivation). |
|
The entity is inactive (permanent deactivation). Starting with 4.8, this value is not used here. |
There is also another virtual read-only property called validity status. This property is similar to effective status in its behavior, but it is computed only from the validity dates. It is used for internal purposed.
Lockout
Lockout status defines the state of user or account lock-out. Lock-out means that the account was temporarily disabled due to failed login attempts or a similar abuse attempt. This mechanism is usually used to avoid brute-force or dictionary password attacks and the lock will usually expire by itself in a matter of minutes.
This value is usually set by the resource or by midpoint internal authentication code. This value is mostly used to read the lockout status of a user or an account. This value is semi-writable. If the object is locked then it can be used to set it to the unlocked state. But not the other way around. It cannot be used to lock the account. Locking is always done by the authentication code.
| Value | Description |
|---|---|
no value |
No information (generally means unlocked user or account) |
|
Unlocked and operational user or account. |
|
The user or account has been locked. Log-in to the account is temporarily disabled. |
Please note that even if user of account are in the normal (unlocked) state they still be disabled by administrative status or validity which will make them efficiently inactive.
There is also an informational property lockoutExpirationTimestamp that provides information about the expiration of the lock.
However not all resources may be able to provide such information.
Operational Properties
There are several properties in the activation data structure that provide operational data:
| Property | Type | Description |
|---|---|---|
|
URI |
URL that identifies a reason for disable. This may be indication that that identity was disabled explicitly, that the disable status was computed or other source of the disabled event. |
|
dateTime |
Timestamp of last modification of the activation status to the disabled state. |
|
dateTime |
Timestamp of last modification of the activation status to the enabled state. |
|
dateTime |
Timestamp of last modification of the activation status to the archived state. |
|
dateTime |
Timestamp of last modification of the effective validity state, i.e. last time the validity state was recomputed with result that was different than the previous recomputation.
It is used to avoid repreated validity change deltas. |