Organizational unit, division, section, object gropup, team, project or any other form of organizing things and/or people. The OrgType objects are designed to form a hierarchical organizational structure (or rather several parallel organizational structures).
Orgs are designed for grouping of objects. Orgs usually group users, but they can group any kind of objects (roles, policies, resources, etc.) This can be used to create a flexible delegated administration setup.
See Organizational Structure page for general introduction to the concepts.
OrgType, as all the midPoint objects, is a subtype of ObjectType. Therefore it has all the basic properties such as
OrgType has a common supertype with RoleType. Therefore Orgs can also work as roles and OrgType has almost all of the properties that RoleType has. Although roles and orgs are very similar there is one principal difference: Orgs are designed for grouping, roles are designed for flexible policy definition.
OrgType is also a focal type. Therefore it can behave as a "focus" (authoritative object) in midPoint synchronization. In that case the Orgs can correspond to LDAP OUs or groups or any similar resource objects.
Following links can be used to get full an authoritative description of the role object schema:
User object contains following frequently used items:
Type of the organizational tree. It is used to distinguish what a specific Org represents. Whether it is a functional organizational unit, project, team, etc.
Examples: functional, project, team, realm
Flag indicating whether this object is a tenant or not. Tenants are top-level organizational units of organizational structures that are designed to be independent of one another. It represents a "customer" is service provider environment.
|The name, identifier or code of the cost center that applies to this org.|
Primary locality of the org, the place where the org is usually placed, the country, city or building that it belongs to. The specific meaning and form of this property is deployment-specific.
|Domain part of RFC822 e-mail address that applies to this organization.|
The content of this property specifies an order in which the organization should be displayed relative to other organizations at the same level. Organizations will be displayed by sorting them by the values of displayOrder property (ascending). These that do not have any displayOrder annotation will be displayed last. Organizations with the same displayOrder are displayed in alphabetic order.
|Reference to the password policy settings which will be used for generate/validate password for this organization.|
Human-readable name of the 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.
Set of authorizations that apply to org members. 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 org assigned (such user is a "subject" of the authorizations).
Indication of the level of risk associated with the persissions that this org assigns. This may be a numeric value, textual label are any other suitable machine-processable indication.
Owner of this org. The owner is a person (or group) that is responsible for maintenance of org definition. This reference may point to object of type UserType of OrgType.
|The role-like aspects of this org are applied only if the condition is evaluated to true. The condition is used to define conditional roles.|
Set of governance, risk management, compliance (GRC) and similar policy constraints that influence the identity model.
Full list of items can be found by using the SchemaDoc links above.
- Organizational Structure
- Assignment vs Inducement
- Roles, Metaroles and Generic Synchronization