Expiration dates are coming to entitlement requests!
We’re rolling out the ability to add expiration dates to entitlement requests submitted through Identity Security Cloud.
What is the Problem?
Customers need to be able to apply duration constraints to any type of access request and have that access auto-revoked. Automating access removal promotes security by ensuring that users only retain access for the time they really need to have it, which is especially important for sensitive or privileged entitlements.
What is the Solution?
Access requests for entitlements will support specifying expiration dates. This option was previously supported only for role and access profile requests.
Users will see the Set Expiration option on any entitlement they’ve added to a request in the Request Center. When they specify an expiration date, the entitlement’s revocation will be automatically initiated by Identity Security Cloud on the specified date.
Thank you - looking forward to this! Wondering if there are plans to make Entitlement Expiration Date mandatory rather than optional (or to have the the option to make it mandatory via configuration). I voted for the following similar idea for roles/access profiles - but most of our requests are for single entitlements. https://ideas.sailpoint.com/ideas/GOV-I-1764
Making expiration date mandatory (often discussed in conjunction with a max duration requirement) is in our future plans, for sure. I don’t have any timelines to offer you at this time, but it’s definitely a need I am aware of and want to address.
Thank you for the announcement! We don’t plan to allow single entitlement requests yet, but I do have some questions regarding the behavior of this functionality.
1: Suppose I have a role with end date two years from now. IdentityNow will provision the corresponding entitlements on my account. If someone removes this entitlement from my account through the application itself, IdentityNow will, on the next (single) account aggregation, detect that the entitlement has disappeared and IdentityNow will then provision the entitlement again. Now suppose instead I requested an entitlement directly with end date two years from now (which will become possible). IdentityNow then provisions the entitlement on my account. If someone removes this entitlement from my account through the application itself, IdentityNow will also, on the next (single) account aggregation, detect that the entitlement has disappeared. But will IdentityNow then provision the entitlement again, since the end date has not been expired yet? Or will it stay deprovisioned?
2: If I request entitlement X with end date next year, and afterwards request an access profile (containing entitlements X, Y and X) with end date next month. Will IdentityNow, after a month, deprovision entitlement X, Y and Z, or only entitlements Y and Z?
3: Same question as 2, but where the same access requests occured in the reversed order.
4: In the My Access/My team tabs, will end users/managers be able to modify the end date? Always, or only when it already has an end date?
5: Suppose we allow entitlement requests, and we have all the entitlements of a source (let’s say AD) assigned to several segments to ensure that only the right people can request those entitlements. Suppose that a new entitlement gets created on the application and we perform an entitlement aggregation. Is this entitlement automatically requestable by everyone by default, until we later assign it to a segment? (I know that this question is not related to the expiration date part of entitlement requests, but whenever functionality we don’t use gets expanded, it makes sense to revisit the total offer/behavior of that functionality to determine if we want to use the functionality or not).
Like roles, entitlements are “sticky” in ISC. If someone takes the access away through an operation locally on the system, ISC is not aware that that was intentional/authorized and will push the access back until the expiration date arrives or until the access is otherwise revoked from an ISC-initated action.
When the entitlement is requested first, the entitlement assignment will take precedence over the earlier access profile revocation because of the record that makes the entitlement “sticky”. So the rest of the access profile’s access will be revoked but the user will keep the entitlement until its end date.
When the access profile is requested/provisioned first, the user already holds entitlement X when the entitlement request comes in, so the entitlement request will be canceled/fail as a duplicate.
At this time, entitlement end dates will not be shown on My Access/My Team. We want to add that path for entitlement date management in the future. But a user can re-request the entitlement through request center with a different end date to change the date. As is true for roles and APs today, you can’t add an end date if the original request didn’t have one, and you can’t remove end date entirely if it was originally requested with one.
You’re right - this is out of scope of this project. I think that entitlements are aggregated as not-requestable, but that may be a connector-specific behavior. I can’t answer this question definitively.
Thank you @jennifer_mitchell for the very clear answers (I like your use of “sticky” for this concept),
it does trigger some follow-up questions/remarks
So if I do an account aggregation and ISC notices that my account now has an entitlement attached to it, that was not caused by ISC, the entitlement is not sticky, but I am also not able to make the entitlement sticky by performing an entitlement request? So ISC doesn’t automatically adds it back when removed from the application and detected by ISC, and if I want this behavior, I need to deprovision the entitlement first and then add it again?
And if I need an entitlement for a month and an access profile (that are not sticky right?) containing that entitlement and others for a week, I have to first request the entitlement and then the access profile, because if I accidentally perform the other way around I can’t get that entitlement for a month anymore?
And if I have an entitlement with end-date and that entitlement gets removed as entitlement from the application, it also gets removed from the account, will ISC then still try to provision the entitlement (which probably causes errors, preventing other provisioning actions) until a scheduled entitlement aggregation occurs? If the entitlement aggregation occurs, will the entitlement get removed from ISC together with the sticky end-date?
But this is only possible when the entitlement already got deprovisioned then? As long as the identity has that entitlement (with end date or not) they are not able to re-request it with a different end date? So the user will have to accept that the access gets deprovisioned (with whatever side effects that may be caused on the application side) before requesting the access again?
Some sources have been configured that if you lose your last entitlement, the account will be disabled or deleted, to save license costs. This would be an example of the side effects I mentioned, which is a reason we rather extend the end date while the entitlement still exists rather than wait until it is removed before adding it back, as the account might then be disabled or deleted in the meantime.
Ahh, That would be good to know! I just tested it on a direct source in my ambassador tenant and indeed newly aggregated entitlements are nonrequestable by default, which is good in my opinion!
Hi @jennifer_mitchell, we’d like to rollout expiration for some of our requestable items that are high privilege, but I noticed we can’t set “expiration time” (e.g. expiration in a few hours).
As a workaround we implemented a “temporary” workflow that automatically revokes access after 12h of been granted, but it generates confusion with our end-users who still want to use the “set expiration” dialog.
I don’t think we have the controls to hide the expiration dialog, is that something we can control via APIs?
Do you have in your roadmap the support for shorter than 24h expirations?
There is not, to my knowledge, an option to control visibility of the expiration dialog via API.
It is possible today to submit access requests via API with a removeDate attribute that specifies a date-time component. And yes, it is definitely on our roadmap to surface that granularity to the UI so we can support expirations in Request Center requests at that more granular level, though I don’t yet have date targets for this. As a category, date-time controls in access requests is a very popular topic, with end times being one component of that.
The permutations of this first part make my head swim a little , and I’m a little concerned that the nuance in this series of questions may be a little too complex for a written exchange in a forum, but I’ll answer what I can.
You are correct that you can’t request an entitlement that we’ve aggregated for the user already, so there is not the ability to force the stickiness onto an existing entitlement today, and yes, that may have some implications if you later request an item which contains the entitlement. This was true before entitlement end dates too, though.
Yes, for this ordered behavior, you’d have to request it in that order.
I am not certain enough about how removal of entitlements entirely from the downstream system works to answer this question.
As to the issue in the second block though, No - you do not have to let the item expire first. The one exception we make in request center for allowing you to re-request something you already hold is when the thing was originally requested with an end date. Then, as long as you re-request it with an end date, we will treat this as a request to change its end date. You can do this re-request at any time. It will go through approval again, but if approved, the end date will be changed.
Thank you for the clear answers on how ISC behaves in these different cases.
Although the cases are complex, we do have to take them into account before using this functionality as these cases will definitely occur in production and we want to limit end user confusion and odd behaviour as much as possible.
Hi, yesterday (June 30) was our first expected auto-revocation of an entitlement requested with the expiration date set. However, ISC did not initiate the entitlement’s revocation on the specified date. I will open SailPoint Support ticket with the evidence, but I also wanted to mention it here in case others are experiencing this.
Jennifer, this functionality has caused us massive issues at Legal and General.
Entitlements unlike roles are not an ID now construct. We have hundreds of thousands of entitlements, a small proportion of which, we auto provision via API’s from ServiceNow. 30 days after an account is disabled our IDAM teams delete it. These AD account then all get re-created breaking all security Audits. To add insult to injury looking at these accounts through the GUI you cannot tell which one or two entitlements now need to be removed via API to allow the account deletion. To add insult to injury we then had all leavers re-created after writing into leavers processing that when a leaver is known in the future, to prevent DLP we automatically added a group so they could not send email attachments outside of the company. This group then caused everyone of our deleted leavers to be re-created. As a minimum entitlement stickiness needs to have an on off flag. Fully appreciate the advantage of revoking at a set date, but see it as a bug not an advantage them being added back if removed by Security teams. Particularly if the whole account is removed. If we wanted this we would include the entitlement in a role. Also this is not made clear anywhere we could find in the Sailpoint documentation.
Thank you for your message John. I understand your concern. I want to clarify, though, that the behavior you are describing is not actually connected to the setting of an end date. “Entitlement stickiness” is existing behavior in ISC where if you request it through ISC, we enforce it for the identity until you revoke it through ISC (in a cert or an access request, for example), regardless of whether you put an end date on it in the request. This is documented here: Managing Requests for Entitlements - SailPoint Identity Services.
If you are seeing a change in that behavior with the date addition, please open a support ticket so it can be investigated. I do understand the potential problems with entitlement stickiness and will continue to work with others to determine if we want/need to change that product behavior.
It does sound like a flag for Stickiness would satisfy your full customer bases requirements. We have done IDAM presentations to many of your customers for Sailpoint as well as presenting at Navigate and Gartner. So we know we are far from an isolated use case in provisioning with API calls to IdentityNow from other applications. There are also lots of customers that provision, but have manual deprovisioning, which the stickiness prevents.
But I must say limiting entitlements based on date criteria, is an exciting and much needed development that we look forward to using.
Thank you, Jennifer. Auto-revocation is not an issue after all. It had to do with the way we were configuring entitlement owners, so that’s been resolved.
Hi Ankit,
It is my understanding that our ServiceNow integration team is working on an update to make it possible for that integration to set entitlement end dates, now that we can accept that info in the API request. Stay tuned for a future update from the PM and team responsible for that work!
Expiration dates are coming to entitlement requests!
, and I’m a little concerned that the nuance in this series of questions may be a little too complex for a written exchange in a forum, but I’ll answer what I can.