Enhancement: Expiration dates in entitlement requests


:bangbang: 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.

Expiration dates will also be supported in API access requests through the removeDate parameter.

Important Dates

Planned release schedule:

  • Sandbox tenants: Monday, June 3
  • Production tenant rollout: June 10 - 13

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.

Hi Jennifer!

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).

Great questions @angelo_mekenkamp . I’ll do my best to answer.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
1 Like

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! :slight_smile:

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.

  1. I don’t think we have the controls to hide the expiration dialog, is that something we can control via APIs?
  2. Do you have in your roadmap the support for shorter than 24h expirations?

Thank you!

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.

1 Like

The permutations of this first part make my head swim a little :laughing:, 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.

1 Like

This is great!

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.

Kind regards,

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.

Thank you for the alert. We will take a look at what is happening when your ticket comes through.