RoleType (Complex Type)

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.

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

• 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

  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]

  Defines triggers for an object. Trigger is an action that should take place at specified time or under some other condition.

• 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 compted 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.

• linkRef

  Flags: RAM

  Multiplicity: [0,-1]

  Set of shadows 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).

• 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).

• activation

  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.

• iteration

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Iteration number. Starts with 0. It is used to iterativelly find unique identifier for the object.

• iterationToken

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Iteration token. String value that is usualy a suffix to the identifier based on iteration number. E.g. ".007". It is used to iterativelly find unique identifier for the object.

• roleMembershipRef

  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.

• delegatedRef

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

• roleInfluenceRef

  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.

• jpegPhoto

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Photo corresponding to the user / org / role.

• policySituation

  Flags: RAM,runtime

  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.

• displayName

  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.

• identifier

  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.

• inducement

  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.

• authorization

  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).

• requestable

  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.

• delegable

  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.

• exclusion

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of excluded roles (part of Segregation of Duties policy).

  DEPRECATED. Use policyConstraints instead.

• riskLevel

  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.

• ownerRef

  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.

• approverRef

  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.

• approverExpression

  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).

• approvalSchema

  Flags: RAM,runtime

  Multiplicity: [0,1]

  More complex (multi-level) approval schema. If used, it overrides both approverRef and approverExpression elements.

• approvalProcess

  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.

• automaticallyApproved

  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.

• condition

  Flags: RAM,runtime

  Multiplicity: [0,1]

• policyConstraints

  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.

• adminGuiConfiguration

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specifies the admin GUI configuration that should be used for the members of this role.

• roleType

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Type of a role, usually denotes a "layer" or "purpose" of the role. Such as "business", "IT", "asset", etc. This field has no special meaning in the IDM computation logic. Its purpose is to organize roles for presentation (GUI) and management. Therefor it is assumed that the values of the roleType will be an enumeration.

  In a complex RBAC structures the role type is usually defined by an assignment of a meta-role. However, selecting the roles by (sometimes transitive) meta-role assignment is not very efficient. Therefore the recommended use is for a meta-role to set the value of (focal) role roleType property to a simple string value (focusMapping in a meta-role is ideal for this purpose). The roleType property should also be associated with a LookupTable (or similar mechanism) to allow GUI to efficiently display and select role types.

  Examples:

  • application
  • business
  • it
  • technical
  • asset