New Capability: Management of Inactive Identities

Announcements Product News
, ,
22

Hey Kirby,

I was referring to attribute sync and hoping that they would cease for long-term inactives.

23

Hi @jahumada22,

Thanks for the input. This will be an up-next priority for us. A couple specifics, Jonathan. How does this design sound?

Attribute sync will always be triggered for Active and Inactive (short-term) identities.

Attribute sync will not be triggered for Inactive (long-term) identities…

  1. After identity attributes have been changed.
  2. After account attributes have been changed.
  3. After administrators use bulk sync for an entire source (/beta/sources/:id/synchronize-attributes).

Attribute sync will be triggered for Inactive (long-term) identities…

  1. After administrators use sync for a single identity (/beta/identities/:identityId/synchronize-attributes) .

I specified the last one so that administrators could force a sync on specific long-term inactives if needed.

I welcome comments from the entire community!

5 Likes
24

I like the design, provides flexibility for random corner cases that require an attribute sync for inactive (long-term) identities!

1 Like
25

@angelo_mekenkamp - I think we had discussed this too. Would this work for you?

26

Hi @kirby_fitch, this looks great, thank you!

I have one question.

Screenshot 2024-03-25 at 10.02.00 AM
Screenshot 2024-03-25 at 10.02.00 AM866×526 65.1 KB

Our testing doesn’t match the above exactly. Or maybe we’re not understanding what’s supposed to happen. Specifically, the “Apply Changes on Access Profiles UI” does not appear to process inactive long term users. Since the access in an access profile is not enforced like a role, the assumption here is that all this would do is “true up” the list of access profiles a user has based on their entitlements. For example, if we created a new access profile that had 3 entitlements in it, and an inactive long term user had those three entitlements, they would show as having the new access profile after the apply changes button is pressed and processing has completed. This did not happen in our testing. Active and inactive short term users do show as having the new access profile, however.

I don’t consider this to be a huge problem, but since it didn’t match the documentation I wanted to bring this to your attention. Again, it’s possible we just misinterpreted what was supposed to happen and it’s all working as expected. Let me know. Thank you!

2 Likes
28

Hi folks,

This feature has been deployed to all sandbox tenants. Sorry for the wait! Thank you to everyone who has already commented. Comment here if you have questions or feedback!

29

Hi @johnepic,

I appreciate your thoroughness. Thank you for that.

This was a documentation error I’ve corrected. Sorry!

  • Apply Changes on Roles UI was renamed to Apply Changes on Roles, Access Profiles, and Apps UIs. These three UIs call the same endpoint when you use Apply Changes. The intent is to true these up for actives and short-term inactives. It’s expected that a long-term inactive could have three entitlements that form an access profile but wouldn’t be processed and wouldn’t receive the access profile.
  • Apply Changes on Access Profiles UI was renamed to Apply Changes on Identity Profiles UI. We do process all identities on a profile when you use Apply Changes there. We relax the inclusion criteria to ensure updates to Identity State or Lifecycle State are promoted to all identities.

New Grid

2 Likes
30

@kirby_fitch: Congratulations to you and the team on delivering this awesome feature!

Slightly aligned to @angelo_mekenkamp’s comment around lifecycle state and granularity, are there plans to be able to give the customer the options on creating their own custom lifecycle state or perhaps being able to change what the outcomes of the lifecycle state (such as allowing a state to be removed from the Request UI but allowed in the My Team UI)?

The use case I am looking at is to remove a cohort of accounts (functional\service accounts) from the request center but potentially leaving them visible in the MyTeam UI.

31

Are there any licensing implications when using the short or long term inactive states? If we were to leave inactive long term identities in the system are they technically still actively managed? I’m not saying we would just want to understand any and all situations this feature may present to us.

32

Hi @Tellius,

Thanks a ton!

If that’s your use case, we’ve got better ideas for you. There will be a new In Discovery item soon. In the meantime, if you schedule time with me here, I can take you through our plans for service accounts.

33

Will the “Inactive (Long Term)” exclude users from event based Identity Profile Syncs occurring as a result of an update form the authoritative source?

I’m unsure if the “Processing for Select Identities” includes the individual ID Profile syncs that occur when we run the Scheduled Aggregation from our authoritative source of record.

I was hoping to use “Identity State:” “Inactive (Long Term)” in conjunction with a new Lifecycle State we call: “Manual Override.” The hope would be we could set this Lifecycle State manually, and this would block any potential updates to our Identities. This would allow us to essentially freeze the account, and manually manipulate downstream sources as needed. Later we could certify this state, and remove users from this state as needed down the line.

I am aware that you can manually set a Lifecycle state from the UI - example “Inactive (manual)”. However, my understanding is that this state can be overridden if our authoritative source has an update for the Identity.

1 Like
34

No, it will not. It’s important that we do continue promoting changes from the authoritative account otherwise re-hire use cases wouldn’t work.

35

Hi @u92119, great question. The two inactive states align with Inactive per our Customer Agreement Definitions.

36

@naleksandrowicz,

We accomplished this by adding a higher priority identity profile backed by a CSV file source (but could really be any source where you want to put your frozen users). To “freeze” a user we put them in the CSV source, to unfreeze we remove them and then the original HR source takes over.

1 Like
37

Amazing ! looking forward to having this in our Production tenant

38

Is it possible to include the new attribute when you do an export from the IdentityList UI view? I don’t believe I see the attribute in the csv file.

Also, with these new identity states, will this prevent sticky entitlements processing on inactive (long-term) identities?

39

Good idea, we’ll look into this.

You should see that problem reduced substantially since these identities will no longer be processed whenever you hit the Apply Changes button. I suspect that’s what’s causing the problem for most customers. I’d love to hear your findings on this one as you see the feature in action once we get to production.

CC @PGookin - you’d be interested in this too.

40

Do we have a schedule for pushing this to FedRAMP tenants?

41

Hey Steve,

We had some trouble deploying the identityState attribute to FedRAMP and are working on that. We do try to keep our FedRAMP schedule lined up with the commercial schedule. Sorry for the wait! I’ll reply to this message again when it’s done!

42

Is it deployed to fedRamp tenant?