Abstract class that conins the "essence" of a role. This is kind of "Roleable" interface when speaking in Java terms.
A role implies assignments. The role may "grant" accounts on resources, attributes and entitlements for such accounts. The role can also assign organizational units, other roles or various IDM objects that can be assigned directly to user. Role is in fact just a named set of assignments.
This is the basic building block of role-based access control (RBAC) in the provisioning system. It defines what rights (e.g. accounts) should be given to user, how they should look like (attributes) and what groups or native roles to assign to them (entitlements).
| 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] | Extension 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] | Triggers for this 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. |
| lifecycleState |
property string |
[0,1] | Lifecycle state of the object. |
| operationExecution |
container OperationExecutionType |
[0,-1] | Description of recent operations executed on this object (or related objects, e. |
| linkRef |
reference ObjectReferenceType |
[0,-1] | Set of shadows (projections) linked to this focal object. |
| personaRef |
reference ObjectReferenceType |
[0,-1] | Set of personas linked to this focal object. |
| assignment |
container AssignmentType |
[0,-1] | Set of object's assignments. |
| activation |
container ActivationType |
[0,1] | Type that defines activation properties. |
| iteration |
property int |
[0,1] | Iteration number. |
| iterationToken |
property string |
[0,1] | Iteration token. |
| roleMembershipRef |
reference ObjectReferenceType |
[0,-1] | References to abstract roles (roles, orgs, services) that this focus currently belongs to - directly or indirectly. |
| delegatedRef |
reference ObjectReferenceType |
[0,-1] | References to objects (abstract roles as well as users) obtained via delegation. |
| roleInfluenceRef |
reference ObjectReferenceType |
[0,-1] | References to abstract roles (roles and orgs) that this focus may directly belong to. |
| jpegPhoto |
property base64Binary |
[0,1] | Photo corresponding to the user / org / role. |
| policySituation |
property anyURI |
[0,-1] | The policy situation(s) of this object. |
| displayName |
property PolyStringType |
[0,1] | Human-readable name of the role or org. |
| identifier |
property string |
[0,1] | Identifier of the role or org. |
| inducement |
container AssignmentType |
[0,-1] | Inducements define the privileges and "features" that other objects should have. |
| authorization |
container AuthorizationType |
[0,-1] | Set of role authorizations. |
| requestable |
property boolean |
[0,1] | If set to true then this role may be directly requested by the users. |
| delegable |
property boolean |
[0,1] | If set to true then this role may be delegated to a deputy. |
| idempotence |
property IdempotenceType |
[0,1] | This value indicates, whether the evaluation of this role gives the same results regardless of its position in the assignment/inducement hierarchy. |
| exclusion |
container ExclusionPolicyConstraintType |
[0,-1] | Specification of excluded roles (part of Segregation of Duties policy). |
| riskLevel |
property string |
[0,1] | Indication of the level of risk associated with the persissions that this role assigns. |
| ownerRef |
reference ObjectReferenceType |
[0,1] | Owner of this role. |
| approverRef |
reference ObjectReferenceType |
[0,-1] | Approvers for this role. |
| approverExpression |
property ExpressionType |
[0,-1] | Approvers for this role. |
| approvalSchema |
container ApprovalSchemaType |
[0,1] | More complex (multi-level) approval schema. |
| approvalProcess |
property string |
[0,1] | Name of custom approval process. |
| automaticallyApproved |
property ExpressionType |
[0,1] | Condition specifying when the assignment is automatically approved (e. |
| condition |
property MappingType |
[0,1] | |
| policyConstraints |
container PolicyConstraintsType |
[0,1] | Set of governance, risk management, compliance (GRC) and similar policy constraints that influence the identity model. |
| adminGuiConfiguration |
property AdminGuiConfigurationType |
[0,1] | Specifies the admin GUI configuration that should be used for the members of this role. |
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.
Flags: RAM,runtime
Multiplicity: [0,1]
Free-form textual description of the object. This is meant to
be displayed in the user interface.
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 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]
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.
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,oper
Multiplicity: [0,-1]
Triggers for this object. They drive invocations of corresponding trigger handlers
at specified time.
Flags: RAM,runtime,oper
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.
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:
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.
Flags: RAM
Multiplicity: [0,-1]
Set of shadows (projections) linked to this focal object.
E.g. a set of accounts linked to a user. This is the set of
shadows that belongs to the focal object in a sense
that these shadows represents the focal object on the resource.
E.g. The set of accounts that represent the same midPoint user (the
same physical person, they are "analogous").
Links define what the object HAS. The links reflect real state of things
(cf. assignment).
Flags: RAM
Multiplicity: [0,-1]
Set of personas linked to this focal object.
E.g. a set of virtual identities linked to a user. This is the set of
"secondary" focal objects that belongs to this focal object in a sense
that the currect focal object is in control over the linked focal objects.
E.g. this reference can be used to link user object which specified a physical
person with his virtual identities (personas) that specify his identity as an
employee, system administrator, customer, etc.
The deafalt meaning is that the personas are ""analogous", i.e. the represent
different facets of the same physical person. However, this meaning may be
theoretically overridden by using various relation parameters in this reference.
This reference define what the object HAS. The links reflect real state of
things (cf. assignment).
Flags: RAM,runtime
Multiplicity: [0,-1]
Set of object's assignments.
Assignments define the privileges and "features" that this object should have, that
this object is entitled to. Typical assignment will point to a role or define
a construction of an account.
Assignments represent what the object SHOULD HAVE. The assignments represent a policy,
a desired state of things (cf. linkRef).
Flags: RAM,runtime
Multiplicity: [0,1]
Type that defines activation properties. Determines whether something is active
(and working) or inactive (e.g. disabled).
It applies to several object types. It may apply to user, account, assignement, etc.
The data in this type define if the described concept is active, from when it is active
and until when. The "active" means that it works. If something is not active, it should
not work or not cause any effect. E.g. inactive user should not be able to log in or run
any tasks, the non-active role should not be assigned and if assigned it should not be
taken into account when computing the accounts.
Flags: RAM,runtime,oper
Multiplicity: [0,1]
Flags: RAM,runtime,oper
Multiplicity: [0,1]
Flags: RAM,oper
Multiplicity: [0,-1]
References to abstract roles (roles, orgs, services) that this focus currently belongs to - directly
or indirectly. This reference points to all the roles in the role hierarchy. It only points to
the roles that were evaluated as active during last recompute (conditions were true, validity
constraints not violated).
Note: the value of this reference is only updated when a focal object is recomputed.
Therefore if a role definition changes then all the affected focal objects must be recomputed
for this reference to be consistent.
Roles mentioned here are those that are NOT obtained via delegation, i.e. "deputy" relations.
Relations acquired by delegation are listed in delegatedRef item.
This is an operational property. It is set and managed by the system. It is used
for efficient search of all current role members, e.g. for the purpose of displaying this
information in the GUI.
Flags: RAM,oper
Multiplicity: [0,-1]
References to objects (abstract roles as well as users) obtained via delegation.
If A1 is a deputy of A, its delegatedRef contains a union of A, A.roleMembershipRef and
A.delegatedRef.
This is an operational property. It is set and managed by the system. It is used
for efficient search of all current role members, e.g. for the purpose of displaying this
information in the GUI.
Flags: RAM,oper
Multiplicity: [0,-1]
References to abstract roles (roles and orgs) that this focus may directly belong to.
This reference only points to the next role in the hierarchy. However, it is backed by
a "closure" index in the repository subsystem. Therefore it can efficiently support tree-like
queries. This reference points to the roles for whose the condition is not true.
Therefore it does not reliably show
who actually has a role. It shows potential role members - all the object that are possibly
influenced when a role definition changes.
This is an operational property. It is set and managed by the system. It is used
for efficient search of all possible role members, e.g. for the purpose of recomputing
all role members after the role definition is changed.
TODO. NOT IMPLEMENTED YET. EXPERIMENAL. UNSTABLE.
Flags: RAM,runtime
Multiplicity: [0,1]
Photo corresponding to the user / org / role.
Flags: RAM,runtime,oper
Multiplicity: [0,-1]
Flags: RAM,runtime
Multiplicity: [0,1]
Human-readable name of the role or org. It may be quite long, container national characters
and there is no uniqueness requirement. It is used if the "name" property contains a code that
is not entirelly user-friendly.
Flags: RAM,runtime
Multiplicity: [0,1]
Identifier of the role or org. It should be a structured information usually used for
refering to the role or org or correlating it in various systems. E.g. numeric organizational
unit identifier, role code, etc. It should be unique in its "own" scope. E.g. an organizational
unit identifier should be unique in the scope of all organizational units but it may conflict
with an identifier of a project.
Flags: RAM,runtime
Multiplicity: [0,-1]
Inducements define the privileges and "features" that other objects should have. It is
a form of indirect assignment.
Unlike assignments inducements do not apply to the object in which they are specified.
Inducements apply to the object that is has assigned the object which contains inducements.
E.g. inducements specified in a role will not be applied to the role itself.
The inducements will be applied to the user that is assigned to such role.
See Assignment vs Inducement
in midPoint wiki.
Flags: RAM,runtime
Multiplicity: [0,-1]
Set of role authorizations. Authorization define fine-grained access to midPoint objects
and system functionality. The authorizations that are defined in a role apply to all
users that have this role assigned (such user is a "subject" of the authorizations).
Flags: RAM,runtime
Multiplicity: [0,1]
If set to true then this role may be directly requested by the users.
The value of this property is only meant as a hint for role presentation.
It does NOT define any access control mechanisms. For access control please
use the authorization element.
Flags: RAM,runtime
Multiplicity: [0,1]
If set to true then this role may be delegated to a deputy.
The value of this property is only meant as a hint for role presentation.
It does NOT define any access control mechanisms. For access control please
use the authorization element.
Flags: RAM,runtime,AVals:3
Multiplicity: [0,1]
This value indicates, whether the evaluation of this role gives the
same results regardless of its position in the assignment/inducement
hierarchy. I.e. evaluation of this roles does not depend on the assignment
parameters of focus or any of the preceding roles. This flag is used
to enable aggresive caching of role evaluation, so idempotent roles
are only evaluated once regardless of their position in the hierarchy
as we can assume that any subsequent eveluation will produce exactly
the same results as the first evaluation. This is a very important
feature that allows efficient evaluation of big role hierarchies.
Marking role as idempotent is likely to result in huge performance
improvements in systems with large role hierarchies. But there are
also risks of incorrect evaluation of the roles.
If an role is idempotent then is is also assumed that any roles included
in this role are also idempotent. Therefore please take care when
constructing role hierarchies. This property has a default value
that indicates no idempotency.
Rules of the thumb:
Roles that are frequently used, roles that are
included in many other roles and roles that combine many other roles
are should be idempotent. Typical example is a "basic" roles that is
assigned to almost any user and that contains a lot of smaller roles.
Roles that are parametric or very dynamic should NOT be idempotent.
Note: it is perfectly OK for some dynamic roles to be marked as
idempotent - even if the role contains complex expressions and conditions.
If those conditions depend only on the environment or properties of the
focus then their outcome does not depend on their posittion in
assignment/inducement hierarchy and these roles can be made idempotent.
Flags: RAM,runtime
Multiplicity: [0,-1]
Specification of excluded roles (part of Segregation of Duties policy).
DEPRECATED. Use policyConstraints instead.
Flags: RAM,runtime
Multiplicity: [0,1]
Indication of the level of risk associated with the persissions that this role assigns.
This may be a numeric value, textual label are any other suitable machine-processable indication.
Flags: RAM
Multiplicity: [0,1]
Owner of this role. The owner is a person (or group) that is responsible for maintenance of
role definition.
This reference may point to object of type UserType of OrgType.
Flags: RAM
Multiplicity: [0,-1]
Approvers for this role. The approver is a person (or group) that approves assignment
of this role to other users.
This reference may point to object of type UserType of OrgType.
Flags: RAM,runtime
Multiplicity: [0,-1]
Approvers for this role. If specified, the expression(s) are evaluated and the result
is used as a set of approvers (UserType, OrgType, RoleType, or any combination of them).
May be used with approverRef element(s).
Flags: RAM,runtime
Multiplicity: [0,1]
More complex (multi-level) approval schema. If used, it overrides both
approverRef and approverExpression elements.
Flags: RAM,runtime
Multiplicity: [0,1]
Name of custom approval process. If used, it overrides
approverRef, approverExpression, and approvalSchema elements.
For explicitness, only one of approverRef(s)/approverExpression(s),
approvalSchema and approvalProcess should be specified.
THIS PROPERTY (approvalProcess) IS NOT SUPPORTED YET.
Flags: RAM,runtime
Multiplicity: [0,1]
Condition specifying when the assignment is automatically approved (e.g. "user is
from Board of Directors"). This is an expression that should yield a boolean value.
Flags: RAM,runtime
Multiplicity: [0,1]
Flags: RAM,runtime
Multiplicity: [0,1]
Set of governance, risk management, compliance (GRC) and similar policy constraints
that influence the identity model.
DEPRECATED. Use the policy rules in the assignments/inducements instead.
Flags: RAM,runtime
Multiplicity: [0,1]
Specifies the admin GUI configuration that should be used
for the members of this role.