Skip to end of metadata
Go to start of metadata

Model level

For certification module there is a set of specific authorization action URIs available. They are listed in the following table. Note that <prefix> is the standard prefix denoting authorization actions at the model level, i.e. "".

OperationAction URIComment
Create a certification definition<prefix>#addThis is a standard action URI used to create an object.
Create a campaign<prefix>#createCertificationCampaign

The certification definition object is evaluated with regards to this authorization (not the campaign object itself). So, it is possible to specify e.g. that a user can "instantiate" definitions with a specific owner. Or definitions with a specific tenantRef, or some extension attribute.

Note that the newly created campaign has ownerRef set to the currently logged-in user.

Open a campaign review stage<prefix>#openCertificationCampaignReviewStageThe object being evaluated is the certification campaign object.
Close a campaign review stage<prefix>#closeCertificationCampaignReviewStageThe object being evaluated is the certification campaign object. (Note: If a campaign closure is scheduled automatically on campaign start, it runs under administrator user.)
Start remediation<prefix>#startCertificationRemediationThe object being evaluated is the certification campaign object. (Note: In case of automated remediation, the task runs under administrator user.)
Close a campaign<prefix>#closeCertificationCampaignThe object being evaluated is the certification campaign object.
Read user's own certification decisions (done along with those that are to be done)<prefix>#readOwnCertificationDecisionsEvaluated without relation to any object.
Record own certification decision.<prefix>#recordCertificationDecisionEvaluated without relation to any object.

GUI level

At the GUI level, there are the following action URIs available. <prefix> is the standard prefix for GUI authorization actions, i.e. "".

GUI pageAction URIComment
Certification definitions<prefix>#certificationDefinitions 
Add/edit certification definition<prefix>#certificationDefinitionCurrently there is no way how to distinguish between "add" and "edit" at the GUI level.
Certification campaigns<prefix>#certificationCampaigns 
View specific campaign<prefix>#certificationCampaign 
My cases to decide<prefix>#certificationDecisions 
All certification-related pages<prefix>#certificationAll 

Note that unlike editing user, role and org, GUI does not currently adapt itself to specific security settings for the model level. This means that, for example, if a user has an authorization to read but not modify a particular definition, the GUI is the same as if he had an authorization to read as well as to modify it - i.e., all fields are shown and editable. Only after "Save" button is pushed, an "access denied" exception occurs in the former case. Also, if a user has an authorization to view some of the items but not the others, the form does not adapt to this: it shows all the fields; and those that are not authorized are simply not filled in. This is to be fixed in later versions of midPoint.

Example 1: Reviewer role

This role allows a user to:

  1. read requests he has to certify (including his own decisions) as well as record the decisions - the first authorization,
  2. display "my cases to decide" page - the second one.

Example 2: Certification campaign owner

This role allows a user to:

  1. create campaigns for a given certification definition (in this case, specified by OID, although the any other filter can be used) - the first authorization,
  2. read and manage campaigns that were derived from this particular definition - the second one,
  3. use respective GUI pages.

By "manage" we mean opening and closing their stages, starting remediation, but not closing the campaigns prematurely. The last privilege could be added by adding action URI #closeCertificationCampaign in the list of URIs in second authorization.

Alternatively, we might want to specify the second authorization in a way of "all campaigns whose owner is currently logged-in user". But the implementation of owner = self is not quite finished yet (see MID-2789).

  • No labels