New Capability: Management of Inactive Identities

[kirby_fitch]

This is available in all tenants. Comment on this announcement if you have questions or concerns about it!

A new option on the Lifecycle State UI enables admins to remove inactive identities from:
• Identity Picklists in Request Center
• My Team UI for Managers
• Identity Processing

You’ll know this is available in your tenant when you see a configuration option for Identity State on the Lifecycle State UI.

How do I implement the feature?

Watch this 25 minute video for a step-by-step implementation guide. Continue reading this post if you prefer text over video!

Quick start: management of inactive identities

How do Identity States work?

Admins use the configuration option

Admins make a selection when creating new lifecycle states. Existing lifecycle states have the value set to null as the default, but admins can update them at any time.

Identities receive an identity attribute

All identities receive an Identity State (identityState) attribute. This attribute is non-configurable on the Mappings UI since it’s configured elsewhere.

An identity’s state typically reflects the value that has been configured for their assigned lifecycle state. If an identity’s assigned lifecycle state is null OR their assigned lifecycle state hasn’t had its state configured, their Identity State will be Active.

Identity processing keeps attribute up-to-date

Identity processing updates an identity’s state when the identity changes lifecycle states, or when the configuration for the identity’s current lifecycle state is changed.

Identity Security Cloud uses attribute for filtering

Identity Security Cloud uses the attribute to filter inactive identities from its services.

How are the three states used?

Active identities will be included in all services. Inactive (short-term) will be excluded from some services. Inactive (long-term) will be excluded from most services.

Our initial focus is in these areas. Future releases will focus on additional areas.

Area	Active	Inactive (short-term)	Inactive (long-term)
Identity Picklists in Request Center	Included	Excluded	Excluded
My Team UI for Managers	Included	Excluded	Excluded
Scheduled Processing	Included	Included	Excluded
Apply Changes on Roles, Access Profiles, and Apps UIs	Included	Included	Excluded
Apply Changes on Identity Profiles UI	Included	Included	Included
Processing for Select Identities	Included	Included	Included
Identity Attribution Promotion after Accounts Updated in Aggregations	Included	Included	Included

How should I map my lifecycle states?

Active

Lifecycle States that represent identities who are joining or work for your organization should be mapped to Active. Here are some prevalent lifecycle states we recommend mapping into this bucket:

• Pre-Hire
• Active

Inactive (short-term)

Lifecycle States that represent identities that are leaving or have a restricted relationship with your organization should be mapped to Inactive (short-term).

With regards to “leaving,” tenants can use two or more lifecycle states for multi-phase termination. For example, identities might move to Terminated when first separated, and then moved to Deleted when separated 90+ days.

With regards to “restricted relationship,” some regions or countries consider on-leave identities as active.

You shouldn’t feel compelled to use this state unless it’s relevant to your implementation.

Here are some prevalent lifecycle states we recommend mapping into this bucket:

• Leave of Absence
• Recent / Phase 1 Terminations

Inactive (long-term)

Lifecycle States that represent identities that have fully separated from your organization should be mapped to Inactive (long-term). Here are some prevalent lifecycle states we recommend mapping into this bucket:

• Inactive
• Final / Phase 2 Terminations
• Deleted

How do I apply my Identity State mappings?

Identity Security cloud will let you know that your changes need to be applied through identity processing after you’ve updated a lifecycle state’s Identity State mapping, enabled it, or disabled it. Press Apply Changes to update the Identity State attribute for all identities.

More on Disabled Lifecycle States

A lifecycle state must be enabled for its Identity State mapping to take effect.

What if I have identities that are not assigned to lifecycle states?

An identity’s Identity State typically reflects the value that has been configured for their assigned lifecycle state. If an identity’s assigned lifecycle state is null OR their assigned lifecycle state hasn’t had its Identity State configured, their Identity State will be Active.

Submit details about your use case if you’ve got inactive identities who can’t be assigned a lifecycle state.

How do I see an identity’s state via the UI?

You’re able to see an identity’s state via the Identity Management UI.

How do I search for identities in each state?

Use these queries to search for all identities in each state:

attributes.identityState:ACTIVE
attributes.identityState:INACTIVE_SHORT_TERM
attributes.identityState:INACTIVE_LONG_TERM

How do I filter for identities in each state via the APIs?

List identities endpoint

GET /beta/identities?filters=identityState eq "ACTIVE"
GET /beta/identities?filters=identityState eq "INACTIVE_SHORT_TERM"
GET /beta/identities?filters=identityState eq "INACTIVE_LONG_TERM"

Public identities endpoint

GET /v3/public-identities?filters=identityState eq "ACTIVE"
GET /v3/public-identities?filters=identityState eq "INACTIVE_SHORT_TERM"
GET /v3/public-identities?filters=identityState eq "INACTIVE_LONG_TERM"

How are inactive identities returned to active?

You will encounter identities who are re-hired after long separations. Identity Security Cloud will process an inactive when their authoritative or other accounts are updated. This processing could run joiner-mover-leaver transforms/rules to move inactives back into active lifecycle states.

How do I initiate identity processing for inactive identities?

If you encounter a scenario where Inactive (long-term) identities are stuck in an inactive lifecycle state after being re-hired, update your joiner-mover-leaver configuration to prevent future occurrences. Then, initiate identity processing for the inactives.

If you encounter a scenario where Inactive (long-term) identities are stuck in a role, update your role membership criteria to prevent future occurrences. Then, initiate identity processing for the inactives.

The Process Identity button on the Identity List UI is a useful way to initiate identity processing for a handful of inactives. You could also use the process identities endpoint for up to 250 inactives.

How do I trigger a workflow when identity states change?

Identity State is an identity attribute. You could use the Identity Attribute Changed trigger to initiate a workflow when identity state values change.

What are the next priorities?

Here are the areas we intend to expand this feature in the future. Submit questions or feedback about your top priorities.

• Certifications
• Access Modeling
• Login Capability
• Removing Requestable Roles
• Elsewhere

Thank You

Thank you to the 320+ voters who showed your support for GOV-I-1864: Management of Inactive Identities, as well as all the admins who joined us for interviews!

[jewalker (James Walker)]

Set this up in our sandbox tenant and it is working as expected. Excited to get this in production soon!

Thank you to the product team that worked on this solution.

[angelo_mekenkamp]

I think this announcement deserves a big round of applause!

It looks like this functionality has really been thought through and that an assessment has been made on what impact this functionality will have on existing functionality and on different concepts like UI, API, access requests, refreshes, birthright roles and search (not sure about segmentation membership though).

I do wonder what challenges (small or big) we will get into when using this capability on our tenants, but unless there are bugs in the functionality, I think we can definitely use this to our advantage!

Right now this identity attribute Identity State is getting calculated by SailPoint using our lifecycle state configuration as input. I wonder if we (at some point) will require SailPoint to have this calculation as the default, whilst still allowing us to override this by our own mapping logic that determines the value for Identity State, simply because lifecycle state is not granular enough.

I just thought of one question. If an identity has Identity State with value Inactive (short-term) or Inactive (long-term), I am, not able to request access for them in the request center anymore. Am I still able to request access through the API to those users? And am I as manager or admin still able to revoke access for this identity?

Kind regards,
Angelo

[jahumada22 (Jonathan Ahumada)]

Awesome! I don’t see any mention of event-based processing (only scheduled) being excluded, do you see that coming in the future for identity state Inactive (long-term)?

[kirby_fitch]

@jewalker

Set this up in our sandbox tenant and it is working as expected. Excited to get this in production soon!

Thank you to the product team that worked on this solution.

Thank you, @jewalker for the quick trial.

1. How long did it take you start-to-finish to configure?
2. What aspects of the UI did you try out after it was configured?
3. Anything you’d change about the capability?

Thanks!

[kirby_fitch]

@jahumada22

I don’t see any mention of event-based processing (only scheduled) being excluded, do you see that coming in the future for identity state Inactive (long-term)?

Hi Johnathan,

Would you happen to be referring to Attribute Sync? Are you expecting us to cease attribute syncs for long-term inactives?

If not, tell me more about the piece of event-based processing that you’d like us to address.

[kirby_fitch]

@angelo_mekenkamp

I think this announcement deserves a big round of applause!

It looks like this functionality has really been thought through and that an assessment has been made on what impact this functionality will have on existing functionality and on different concepts like UI, API, access requests, refreshes, birthright roles and search (not sure about segmentation membership though).

Thanks, @angelo_mekenkamp! Yes, we’ve stressed all the fine details here. I’ve personally spent days testing this feature, as have the Engineers I work with. And there are still many places throughout Identity Security Cloud to take advantage of this new attribute.

@aaron_andrew could weigh in on segmentation.

@angelo_mekenkamp

I do wonder what challenges (small or big) we will get into when using this capability on our tenants, but unless there are bugs in the functionality, I think we can definitely use this to our advantage!

There are a numerous complex configurations out there. We think we’ve thought of them all. We’ve got a conservative rollout plan and are prepared to address problems that arise.

@angelo_mekenkamp

Right now this identity attribute Identity State is getting calculated by SailPoint using our lifecycle state configuration as input. I wonder if we (at some point) will require SailPoint to have this calculation as the default, whilst still allowing us to override this by our own mapping logic that determines the value for Identity State, simply because lifecycle state is not granular enough.

We selected the most flexible solution that admins of every skill level could quickly self-implement. We’re now “waiting-and-seeing” what further needs materialize. What use case do you think should override the lifecycle state? Does that get too complicated when you can also manually set the lifecycle state?

@angelo_mekenkamp

I just thought of one question. If an identity has Identity State with value Inactive (short-term) or Inactive (long-term), I am, not able to request access for them in the request center anymore. Am I still able to request access through the API to those users?

Yes, you’re still able to request through the API. We could be more restrictive yet.

@angelo_mekenkamp

And am I as manager or admin still able to revoke access for this identity?

Managers would be authorized to submit revoke requests for inactives but wouldn’t see them in My Team view.

Admins will see inactives in the Identity Management UI. Additionally, we’re adding the ability to revoke there.

Finally, the forthcoming Account Management UI will enable Org Admins, Source Admins, and Source Sub-Admins to filter for accounts belonging to inactives. That could help you spot post-termination access from a different perspective.

[aaron_andrew]

@angelo_mekenkamp since this Identity State attribute would be an Identity Attribute, it should be pulled in to build Segmentation Policies - meaning you could build segments who could intentionally see inactive identities (made up example: inactive identities in a pre-hire state) and take actions like access requests on their behalf. You could also build a filter on segmentation policy and specifically exclude inactive identities with one criteria on every segmentation policy you build.

[klaus_hild]

Hi Kirby, Congrats to you and your team. This is a big step forward toward what customers expect as “normal behavior”. I’ll check the feature and come back with more feedback.

[vguleria (Vikas Guleria)]

Hi Kirby,

I believe this is a great and feature, so many many congratulations to the whole team. I have just a query about the Inactive (long-term) identities excluded from the scheduled processing.

I hope this will not exclude processing of these identities during the scheduled identity refresh. There could be some transform (for example for lifecycle calculation) which may be based on end-date and requires periodic refresh so in case these are not refreshing it could have some issues with rehiring processes.

But overall looks like a great addition to ISC and looking forward to it.

Thank You.
Kind regards
Vikas.

[angelo_mekenkamp]

@kirby_fitch

We selected the most flexible solution that admins of every skill level could quickly self-implement. We’re now “waiting-and-seeing” what further needs materialize. What use case do you think should override the lifecycle state? Does that get too complicated when you can also manually set the lifecycle state?

I have yet to find a good use case, but I think the risk is that we need to create more lifecycle states then preferred. Suppose you are on a temporary leave of absence and your manager wants to request access for their team, if you are Inactive (short)-term and you return back to work, you now do not have the access that all your colleagues have. Your manager has to request access again and this is causing additional steps. As a consequence, we decide that temporary leave of absence should stay mapped to Active. But then we get a message from the manager of a security department that has now requested access to its team members and noticed that some temporary leave of absence colleagues now also has the access. We conclude that it could depend per country/department or risk level whether leave of absence identities should be in the request list or not. We can solve this by splitting the lifecycle leave of absense in multiple lifecycle states, but this will then create yet another lifecycle state and too many of them might cause confusion. Perhaps it makes more sense in that case if we keep the lifecycle states as is and directly map to the identity state attribute ourselves.
Again, maybe not the best example. I guess the future will tell if this more granular control is really needed.

@kirby_fitch

Yes, you’re still able to request through the API. We could be more restrictive yet.

Please note I am not saying I think this should be done. I am not sure yet if restricting it more is actually desired. I think the main point is to prevent accidental access requests for inactive users, not preventing requesting access for inactive users on purpose. I can image cases where (local) admins or scripts still want to perform access (grant or revocation) requests on the identities, even when they are short/long term inactive. As long as it is clearly documented that access requests are still possible via API, their will not be a false assumption of a certain sense of security.

Once again, really nice feature! I look forward to work with it

Kind regards,
Angelo

[kirby_fitch]

@vguleria

I believe this is a great and feature, so many many congratulations to the whole team.

Thanks for the kind words!

@vguleria

I hope this will not exclude processing of these identities during the scheduled identity refresh. There could be some transform (for example for lifecycle calculation) which may be based on end-date and requires periodic refresh so in case these are not refreshing it could have some issues with rehiring processes.

All identities including inactives are processed after their account attributes change during aggregations. For example, an inactive (long-term) identity could have their End Date updated to December 31, 2024. The system would re-run their Lifecycle State transform and move them back to Active.

You can also use start-identity-processing | SailPoint Developer Community to force the Lifecycle State transform to re-run if End Date changes fail to move identities back to Active when the changes are detected.

[kirby_fitch]

@angelo_mekenkamp

I guess the future will tell if this more granular control is really needed.

You and I have drawn about the same conclusions here. We’ll make enhancements if we find prevalent valid use cases where locking this to a lifecycle state is too restrictive.

We could also make it possible for managers to work with inactives so decisions such as this one could be managed in the business rather than via administration.

@kirby_fitch

I can image cases where (local) admins or scripts still want to perform access (grant or revocation) requests on the identities, even when they are short/long term inactive. As long as it is clearly documented that access requests are still possible via API, their will not be a false assumption of a certain sense of security.

I meant that we could be more restrictive with regards to granting access to inactives. Revocations should be allowed regardless of state! In the meantime, we’ll consider how to document this.

Thanks again!

CC- @kaitlyn_stockton and @jennifer_mitchell

[vguleria (Vikas Guleria)]

Hi Kirby,

Great, I had missed this part earlier. Thank you for clarifying.

So i believe, it already looks quite promising and would be really useful.

Still, I see there are lots of transforms which offers the property requiresPeriodicRefresh which ensures that the transform will run every day periodically, do you or the team already know if this attribute’s (requiresPeriodicRefresh ) functionality be overwritten by the feature or will stay as it is (even for long term inactive employee). But i must, admit i do not foresee any issues with this but having this information could be helpful in future considerations.

Thank You again for clarification.

Thank You.
Regards
Vikas.

[kirby_fitch]

@vguleria

Still, I see there are lots of transforms which offers the property requiresPeriodicRefresh which ensures that the transform will run every day periodically, do you or the team already know if this attribute’s (requiresPeriodicRefresh ) functionality be overwritten by the feature or will stay as it is (even for long term inactive employee).

Hi Vikas,

requiresPeriodicRefresh does not create an exception for long-term inactives. Long-term inactives will be removed from scheduled processing altogether.

[jewalker (James Walker)]

1. We have two identity profiles, so it took maybe 5 minutes to set.
2. I checked the My Team UI and went to make a request to see who appeared.
3. Not at this time, knowing what is coming down the line already. Certifications, Access Modeling, and etc…

We have been pinged quite a bit about long retired employees showing up in My Team so I look forward to getting this set up in production.

Thanks again.

[kirby_fitch]

@jewalker

We have two identity profiles, so it took maybe 5 minutes to set.

5 minutes. Love it! Thanks!

[vguleria (Vikas Guleria)]

Great. Thank you for the detailed explanation

[mayzach (Zach May)]

Thank you Kirby! Is there a way for customers like us who hadn’t yet voted for this to get the preview activated in our sandbox?

[kirby_fitch]

Hi @mayzach,

This is less about who voted and more about picking a reasonable number of tenants to get started with the capability. We’re seeing good signal so far. We could be going to all sandbox tenants next week. We’ll provide new date guidance towards the end of this week.

Thanks for your interest!