User16166002114184590819 (Customer) asked a question.
We have an issue with segregation of duties when using Okta Access Requests. It is mandatory that users raising the request would not be able to approve their own access requests. Currently, if approvers are set to Group Owners, then it allows to self-approve your access request which raises a flag in security audit. The only workaround at the moment is - to use Groups for approvals (it does not assign approval to requester by design as described here: https://support.okta.com/help/s/article/access-request-expected-reviewer-self-attestation-behavior?language=en_US). However, this is not an option just to re-work all request types to use Groups instead of Group Owners (would have to duplicate all existing groups - assignment groups and approver groups as approvers are different for each group). Any ideas if there are any proper workarounds for this without moving away from Group Owner approvals? Additionally, does anyone know if it is in plan to implement such segregation of duties feature for Group Owners as approvers in the near future?
@User16166002114184590819 (Customer) - I don't think that is intended. Obviously, if there is ONLY 1 group owner self-attestation cannot be avoided (Edit: I stand corrected, the expected behavior in this scenario would be for the approver to be left unassigned). But the logic is supposed to work the same regardless of the "pool" selection. Essentially it determines if the user (requester) and user (approver) Okta Id's match. If they do they should be removed from the list of candidates for approval.
There "might" be a defect here I will see if I can reproduce the behavior you have described.