Add dependency in account and permission flow with dependent system
complete
G
Grady Koopman
We would like that the account actions should be fired first before the permissions actions. This way we are certain that the account reference is correct before firing any permission actions. This means that we should add a dependency between account actions and permission actions just like a dependency between systems.
Solution:
Inside system
Account grant
Account Access grant -> Account data available, Account update
Account Access revoke -> Account update, Permission Revoke
Account update -> Account data available
Permission Grant -> Account data available, Account update
Permission Revoke->Account data available, Account update
Account revoke -> Account data available, Account Access revoke (critical), Permission Revoke (critical)
Dependant system
All account actions should be taken (Grant and update account are critical) on the dependant system first before executing the system actions
Add icon for waiting on the system or waiting for other action
Add pending reason when entitlement is a grant or revoke pending
Show pending reason in entitlement overview (when hovering pending grant)
The reason should only be on the next reason
Optional: Link entitlement to the progress of the target system
Show all reasons (open actions)
Add to docs
R
Rick van den Dijssel
complete
R
Rick van den Dijssel
in progress
Bernard Moeskops
Rick van den Dijssel: Will updates on dependent target systems also be executed in order? So if system B is dependent on system A, an update on B will be executed after the update on system A? Momentarily we have situations where the update to change the emailaddress in AFAS occurs before the change of the emailaddress.. Only with new users this seems to be in the correct order.
R
Rick van den Dijssel
Bernard Moeskops: Yes in your case all actions(account grant/revoke, account access grant/revoke, update and permission grant/revoke) of system a will be before system b in a single run. Besides this the grant account and update are critical which means the grant account and update will not fire until the dependent system action has been successfully finished. Hope this answers your question.
Bernard Moeskops
Rick van den Dijssel: Really happy to hear this! Thanks :)
G
Grady Koopman
Merged in a post:
Support account dependency for Update event
Ramon Schouten
Currently the system dependency is only available for granting entitlements and doesn't influence the sequence of the updates or revokes of entitlements.
We would like to see this functionality available for updates and revokes as well.
G
Grady Koopman
planned
Mike Sheldon
This is very important feature as it can currently have unexpected results on revoking an entitlement if there are errors.
Example
Goal: Disable Account for Person
Person – John Smith
John Smith has the following entitlement
- AD Account
- AD Account Access
John Smith is removed from the source data, thus deleting the person. The entitlements are then marked to be revoked. The “Account Access” fails to be revoked because there is bad logic in the “Move account on disable” PowerShell script. The “Account” entitlement is revoked, but no action occurs because “DELETE THE ACCOUNT WHEN REVOKING THE ENTITLEMENT” is disabled.
On the next enforcement, there is a retry “Account Access” revoke. Ultimately does nothing because the “Account” entitlement is revoked.
Result: Account for Person is left enabled