Description
We’ve made recent improvements to our access request expiration date support to ensure more consistent and comprehensive handling of expiration date changes on access assignments. As we prepare to roll out these enhancements, we’re taking the opportunity to highlight the available options and raise customer awareness!
With this enhancement, Request Center will now support all of these date-management options across all access item types:
-
Re-request of an expiration-dated assignment with a new date to change the scheduled expiration date.
-
Re-request of an expiration-dated assignment with no date to remove the scheduled exipration date, to make the assignment perpetual.
-
Re-request of an undated assignment with an expiration date to add scheduled expiration to a previously perpetual assignment.
Note:
-
All of these re-requests will be sent through the grant-access approval flow before the change will be applied.
-
The My Access, My Team, and Identity admin pages also support date changes, also processed through the grant-access approval flow, but do not currently support adding/removing dates on assignments.
-
Through our access-request API, date change requests can alternatively be submitted as revoke requests, but only to shorten the duration - moving the expiration date earlier or adding a date where one did not exist before. These requests will be processed through the revocation approval path configured for the item.
Action Required
No action is required for you to enable these behaviors, and nothing will visibly change for your users in the Request Center, other than some requests that would have been cancelled silently before will now be submitted and processed.
Important Dates
The improvements have already been enabled in customer sandbox tenants!
Production rollout: Week of June 2, 2025.
1 Like
Looking forward to this one! It only makes sense that the request center can handle these different occurrences 
Also nice to see this is following the other update on self-revocation and revocation on behalf of others in a good pace. These are the really important features
I already shared this feedback 1~2 years ago, but I would also like to place this here as it becomes even more relevant now with this enhancement and it would be good for other customers/partners to be aware that the current design allows the option to bypass the access revocation approval workflow such that they can take this into account during the role modeling process.
In short:
- The goal for an Access Request Grant Approval workflow is to ensure that getting more access (roles, access profiles, entitlements) is not resulting in problems for whatever reason.
- The goal for an Access Request Revoke Approval workflow is to ensure that losing more access (roles, access profiles, entitlements) is not resulting in problems for whatever reason.
These two workflows can contain different approval steps. Though often the case, we shouldn’t simply assume that goal 1 is always more important than goal 2 as several examples can be given where this does not hold.
If I have a role without end date, I can request revocation and it will trigger the Access Request Revoke Approval workflow, allowing those responsible for ensuring that losing access will not cause problems for whatever reason. To bypass this security control, I can choose to instead request this role I already have, but now give as enddate tomorrow. Due to the current design, it will now trigger the Access Request Grant Approval workflow, whose approvers (if configured at all) can be different and have a different goal and might be approving, not knowing that basically I am losing this role (within 24 hours) whereas if they would deny this access request, I would have kept it forever. And for customers whose revocation approval workflow is less strict than the grant approval workflow, this would still unnecessarily trigger the approval workflow as their goal (ensuring more access is not causing problems) is not required in this case.
So if you don’t use the revocation approval workflow at all and insta-allow revocations, this workaround of requesting revocation with an end date is merely an inconvenience to the approvers, but if you use a revocation approval workflow, this can be a security concern. To mitigate this, you could decide to add all approvers of the revocation approval workflow to the grant approval workflow as additional step(s), such that they can step in whenever this revocation trick occurs and approve it otherwise, but it would definitely be less ideal.
Long term I think that if a request contains an end date, that is timewise earlier than the current end-date, it should not trigger the access request grant approval workflow, but should instead trigger the access request revocation approval workflow.
Kind regards,
Angelo