AuthorizationType (Complex Type)

Items

• name

  Flags: RAM,runtime

  Multiplicity: [0,1]

• description

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Free-form textual description of the object. It is supposed to describe the object or a construct that it is attached to.

  This information may be presented to midPoint users, even to ordinary end users. For example role description may be presented to users when they are selecting roles to request. Therefore the description should be written in a language that the users can understand.

  Description is assumed to be a plan, non-formatted text. Amount of white space is considered insignificant. E.g. leading and trailing white space may be skipped, multiple spaces can be collapsed to one and so on.

• documentation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Technical documentation for a particular object or construct.

  The purpose of this element is to document system configuration and behavior. The documentation will not be presented to end users. In fact, it will probably not be presented at all in midPoint user interface. This documentation element is supposed to be a part of the technical documentation of midPoint deployment. The tools than generate deployment configuration will look for these elements and combine them to compiled documentation document.

  AsciiDoc formatting is assumed for this element. Any leading or trailing whitespace is skipped. Indentation equivalent to he indentation of the first non-blank line of text is also skipped.

• decision

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Decision that this authorization specifies. If the decision is "allow" (which is the default) then this authorization allows access. If the decision is "deny" then this authorization denies access. Denial is a final decisions. If at least one applicable authorization denies access then the access is always denied, regardless of any other allow authorizations.

  Note: there is subtle (but important) difference between not allowing access and denying access. Authorization that denies access specifies a final decision. Denied access cannot be allowed by any other authorization. Deny authorization are very strong from a security perspective, but it is extremely difficult to combine them with other authorizations. Therefore deny authorizations are used very rarely. On the other hand if the access is not allowed by a specific authorization then it can still be allowed by another authorization. This makes authorizations "mergeable". Not allowing access is usually the right approach.

• action

  Flags: RAM,runtime

  Multiplicity: [1,-1]

  Action part from the (subject,action,object) authorization triple. It is an URL to allow extension. Multiple actions may be specified. In that case the authorization applies to all of them.

• phase

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Specifies when to conduct authorization and what exactly to authorize. If no phase is specified then the authorization applies to all phases.

• enforcementStrategy

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Setting that specifies when to enforce the authorization. Default setting is to always enforce the authorization.

• zoneOfControl

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

• object

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Object part from the (subject,action,object) authorization triple.

• item

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of items that form a scope of this authorization. This authorization will only affect the items specified in this element. If no items are specified then the authorization applies to all items in the objects.

  The item specification must not be combined with exceptItem. One or the other can be used, but not both. If neither item nor exceptItem is specified then it is assumed that the authorization applies to all items.

• exceptItem

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of items that are excluded from the scope of this authorization. I.e. the authorization applies to all the items except those items that are specified here.

  Note: there is subtle (but important) difference between not allowing access and denying access. Authorization that denies access specifies a final decision. Denied access cannot be allowed by any other authorization. Deny authorization are very strong from a security perspective, but it is extremely difficult to combine them with other authorizations. Therefore deny authorizations are used very rarely. On the other hand if the access is not allowed by a specific authorization then it can still be allowed by another authorization. This makes authorizations "mergeable". Not allowing access is usually the right approach. The exceptItem specification is a convenient way to "not allow" access to specific items.

  The item specification must not be combined with exceptItem. One or the other can be used, but not both. If neither item nor exceptItem is specified then it is assumed that the authorization applies to all items.

• target

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Target of the operation. E.g. an role that is being assigned. It can be considered an operation parameter. If no target is specified then the authorization applies to all possible targets.

• relation

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Relation(s) to which the authorization applies. This is applicable only to some authorizations, mostly those that create new object references (e.g. assign/unassign authorizations). If left empty it applies to all relations.

• orderConstraints

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Order constraints for cases when assignment/inducement is a matter of the authorization decision. Order constrain may limit the order of assignment/inducement being authorized. Order constraint of zero (default) means assignment. Order constraint of one or greater means inducement. Note: Partially implemented in midPoint 3.9. Only values of zero and one are supported. Only integer orders are supported. Assignments/inducements with complex orderConstraints are not supported.

• limitations

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Limitations of this authorization when it is applied to other authorizations. For example this specification may limit the power of attorney. It is only applicable to some authorization types.