Enhancement: Time Based Refresh!

Announcements Product News
, ,
1

Description

:bangbang: SailPoint is excited to share that Time-Based Refresh is now available!

With the introduction of Time-Based Refresh, administrators can now control the desired local time of refresh for targeted identities.

Problem

Prior to having the Time-Based Refresh capability available, Identity Security Cloud would leverage a pre-defined time for refreshing target identities. For global organizations supporting multiple time zones, this pre-determined timing was not flexible enough to effectively support their need to perform joiner-mover-leaver events on a specific local time that was applicable for that identity.

Solution

Administrators can now configure the desired local time of refresh for targeted identities based on a given time attribute (Next Processing Date), which means less identifies must be refreshed at one time. ISC can now support identity state changes in different local times.

Important Dates

Staging: Monday, September 30, 2024.
Production: Week of October 7, 2024.

6 Likes
2

Any documentation on how you are supposed to set this up? I see the new identity attribute in identity profiles, but nothing about how to use it in product documentation.

3 Likes
3

So exciting!! We’ve been fighting this for a while now. Will it be able to have different time zone settings for users in different parts of the globe? So we’re not waiting 12 hours to suspend someone from Australia as example.

4

Any details around Next Processing Date Attribute . What all changes in system can reset the value for this attribute? so that we should clearly know when identity will get refreshed ?

3 Likes
5

Thanks Yael,

Looking forward to any documentation regarding this feature.

Regards
Arjun

6

Sounds interesting @yael_kadoshi, could be useful for us. :grin:

I do think some more information is needed. As mentioned (a link to the) documentation. I also wonder what happens if we don’t directly start configuring it. Will it behave differently than before the release?

In addition I wonder how we can choose time zones that change, for example due to daylight savings time. Can I choose Amsterdam time and configure it will always refresh 2am Amsterdam time? Would I need to change the configuration every half year to ensure it stays at 2am?

Also I would like to emphasize again that timing of these announcements are important. This announcement arrived on the 7th of October, while staging apparently occurred on the 30th of September and release to production is planned in the week of the 7th. This means we lost the possibility of properly testing this new functionality before the release to production and perhaps raise issues, concerns or bugs to you and perhaps to communicate and potentially train our relevant end users. Please release announcements before the staging occurs such that we can start planning on this from our side.

Kind regards,
Angelo

1 Like
7

My guess is that all time has to be given in UTC, so you’ll likely need to do your own calculation of timezones based on the timezone of the identity itself.
But to leave guesses out of it… documentation is required.

Agreeing with Angelo on the announcement part.
Timely announcements of sandbox releases and production releases are crucial for success.

1 Like
8

Just stumbled on the documentation page, thought I’d already share.

2 Likes
9

Looks like this was added in the last 24hrs or so. I didn’t see it yesterday when I posted. Thanks for the update. This feels clunky and totally not what I expected. Thought we were going to be able to schedule refreshes based on some criteria, not just calculate dates for a refresh to happen. Interesting :slightly_smiling_face:

10

Really curious about what use-cases folks foresee for this. I’m hard-pressed to think of any where it’d be a better way to handle things than, say, a complex transform.

11

Looking at the page posted earlier this is still very unclear on how exactly it operates or how to properly implement this.

Looking at the use case I see for most clients is to update the LCS when an identity starts or leaves the company, relative to their time zone.

I can see that this might be useful, but would need a relatively ‘complex’ transform in order to ensure we do the ‘next processing’ on the start & end dates of an identity.

And then I also have some concerns, which is: when will the refresh happen? Do I need to offset the date to ensure it is refreshed in the proper time, relative to an identities’ time zone? In what time zone does the tenant trigger the refresh, the one I set up in the tenant settings or something else?

I believe we need some more information or examples in order to fully judge this.

12

Hello @arjun_sengupta! Here is where your can find our official documentation for this feature. Processing Identity Data - SailPoint Identity Services

2 Likes
13

@tysremi that is correct. The time does have to be given in UTC.

14

Thank you for sharing this documentation @KJR11!

But comparing the documentation to the announcement does get me confused.

The announcement of @yael_kadoshi lets me believe that there is now a solution to the problem “The scheduled identity refreshes occurs at the same moment, regardless of the identities timezone, which causes many refreshes happening at the same time and at wrong times for identities”. As mentioned in the announcement, the solution will mean that less identities will be refreshed at the same time. Therefore I would expect that this time-based processing will occur instead of the refreshes that we had before, the ones that refreshes identities all on the same time.

However, the documentation shared by @KJR11 lets me believe in the opposite.

First of all, the documentation is still mentioning the following:

and

So it seems that these two scheduled refreshes will still occur on top of the new refresh functionality. Therefore I don’t see what supports the statement that less identities will be refreshed at the same time.

Secondly, the documentation mentions this:

So the next processing date is not just pointing to a specific time of the day, on which the refresh should daily occur. It is the combination of date+time, so it will only cause one refresh. This means we can’t replace the scheduled processing by this new functionality.

Thirdly, as workaround to my second point, we could think to write a transform for this identity attribute that will use the current date and the identities timezone to calculate the next time we would want to trigger the identity processing. This would then really result in scheduled identity-timezone based processing. However this will not work due to the following limitation mentioned by the documentation:

So it is not possible to refresh the identity and then let the transform set the value for the next day. And even if that would be possible, we would go from two refreshes each day (8AM and 8PM) to only one refresh per day. We could however let the workflow calculate the 8AM/8PM time at the identities local time and then create a workaround with trigger on identity attribute changes, which will then wait until that timestamp arrived and then let the workflow call the process identity API to reach the desired effect, but I can imagine that this will take much more computational power and efficiency than if SailPoint has out of the box functionality for this, which is undesired for both SailPoint and customer.

And last, looking at this part of the documentation:

It looks like the new functionality is mostly used to ensure that an additional refresh is being made either exactly when the identity starts at the organisation or exactly when they end, not for regular scheduled refreshes. I foresee the need of complex transforms if you want to use this same single identity attribute for these cases combined (start date, end date and perhaps combined with any other cases, where it should be noted that this functionality will not work for identities who gets hired less than 24 hours before their first day starts, or for HR systems that only pass information to the IGA tool if the identity will start the next day. Additional workarounds would be needed for those cases.

Please correct me if I am reading parts of the documentation wrong or draw the wrong conclusions from it, as I currently have the feeling that the announcement is over-promising functionality.

Kind regards,
Angelo

3 Likes
15

Genuine question: What use case is there to completely replace scheduled processing and have it completely different for each user?
I only see 1 use-case for different processing times…
Making sure people are end-dated (or enabled) in their local time zone, which this solves.

It will still cause less provisioning tasks at once during scheduled processing since the user would already be disabled, so the claim of less processing is somewhat true (in addition to mapping identity states).
Whether or not it’s more or less resource intensive doesn’t really matter in the end, right?

16

I guess processing all identities, twice a day at fixed times respective to the timezone of the identity instead of processing all identities twice a day at fixed times respective to a global timezone has multiple advantages

  1. Just in Time Provisioning. All Joiners/Movers/Leavers will get/lose access X hours before their working day starts instead of some Joiners/Movers/Leavers getting access X-6 hours before their working day starts and others X+5 hours before their working day starts.
  2. Lower queueing. We have to wait a long time before we can make certain changes in Identity Security Cloud, just because the identity refresh is going on. And because all identities are being processed, we have to wait longer before we can make configurations.
  3. Workload/Energy reduction. I can imagine that spreading the refresh calculations throughout the day lead to less computational spikes, which I can imagine makes it more efficient. Of course we would then still need to be able to run full refreshes whenever we make big changes ourselves, for example to identity profile mappings or transforms related to it.
17

I don’t see this mentioned in the Documentation that you posted previously. This seems like a good piece of information to have there.

I agree here. It seems like this is on a per-user basis, not adjusting the current twice a day timeframes to align better for global users. Would it be possible to get some clarification on this?

I have to agree with @angelo_mekenkamp’s statements on the use cases for this (Shortened quoted response for clarity.) It does seem like this is in addition to the two time zones. It also does not seem to allow for setting multiple times for a refresh, such as start of work day, mid-work day and end of work day.

I am also confused by when this gets set. It seems like if you use a transform to set “now” whenever it was process, then the result is that the processing would never be done since it would be within 24 hours.

I would love to get clarification for this, and maybe a real world example of how the process is intended to work.

18

Hi all,

We have tried this out in our Sandbox, but can’t get it to work. We used the following transform to populate the attribute “nextProcessing”

{
    "id": "uniqueId",
    "name": "Next Processing Date",
    "type": "dateFormat",
    "attributes": {
        "input": {
            "attributes": {
                "expression": "+4h+15m",
                "roundUp": false,
                "input": {
                    "attributes": {
                        "input": {
                            "attributes": {
                                "sourceName": "HR Source",
                                "attributeName": "EmploymentDate"
                            },
                            "type": "accountAttribute"
                        },
                        "inputFormat": "yyyy-MM-dd",
                        "outputFormat": "ISO8601"
                    },
                    "type": "dateFormat"
                }
            },
            "type": "dateMath"
        },
        "inputFormat": "yyyy-MM-dd'T'HH:mm",
        "outputFormat": "yyyy-MM-dd'T'HH:mm:ss.SSSZ"
    },
    "internal": false
}

This is the format of the identity attribute in IDN:
image

Currently the processing occurs at 08:00 CET (with up to 30-60 minutes delay), which causes problems for newhires which potentially don’t have an active account the day they start.
We want to use this new attribute to get the processing for newhires’ accounts to occur 04:15 CET so that their accounts will be activated prior to them starting their first day.

Thanks in advance

19

Thank you for sharing it!

20

Has anyone had the time to test this new feature for Time Based Refresh and got it to work?

Maybe @yael_kadoshi, @colin_mckibben have some input?
With the above transform, we believe we have followed the documentation and feel like it should work. Is there perhaps something missing in the documentation?