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. "".
|Create a certification definition||<prefix>#add||This 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>#openCertificationCampaignReviewStage||The object being evaluated is the certification campaign object.|
|Close a campaign review stage||<prefix>#closeCertificationCampaignReviewStage||The 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>#startCertificationRemediation||The object being evaluated is the certification campaign object. (Note: In case of automated remediation, the task runs under administrator user.)|
|Close a campaign||<prefix>#closeCertificationCampaign||The object being evaluated is the certification campaign object.|
|Read user's own certification decisions (done along with those that are to be done)||<prefix>#readOwnCertificationDecisions||Evaluated without relation to any object.|
|Record own certification decision.||<prefix>#recordCertificationDecision||Evaluated without relation to any object.|
At the GUI level, there are the following action URIs available. <prefix> is the standard prefix for GUI authorization actions, i.e. "".
|GUI page||Action URI||Comment|
|Add/edit certification definition||<prefix>#certificationDefinition||Currently there is no way how to distinguish between "add" and "edit" at the GUI level.|
|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:
- read requests he has to certify (including his own decisions) as well as record the decisions - the first authorization,
- display "my cases to decide" page - the second one.
Example 2: Certification campaign owner
This role allows a user to:
- create campaigns for a given certification definition (in this case, specified by OID, although the any other filter can be used) - the first authorization,
- read and manage campaigns that were derived from this particular definition - the second one,
- 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).