New Capability: Identity Management

[kirby_fitch]

New Capability: Identity Management

This is available in all sandbox and production tenants. Identity > Access revocation controls had their production rollout deferred and will be handled as a separate announcement.

Try New Experience has been promoted to the experience. Visit Identity Management > Identities in the system to try it yourself.

Thank you to the 100+ administrators who tested the concepts that led to this new identity management experience. It includes the following capabilities:

• Compact and configurable views of identity + account data.
• Comprehensive view of access with revocation controls.
• Auditor-Friendly event log with drill-down controls.

More About Identity Name Presentation (All UIs)
You’re able to configure how identity names are presented using a transform on the Display Name (displayName) attribute. For example, we append (FTE) or (Contractor) in our demo tenant.

More About Navigation Bar Changes
We renamed the following navigation items:

1. Identities top-level nav renamed to Identity Management
2. Identity List sub-nav renamed to Identities
3. Access top-level nav renamed to Access Model

More About Revokes
Org Administrators can revoke access items when the option is available. Helpdesk users cannot revoke access items.

• Roles are revocable if provisioned via access request.
• Access Profiles that stand alone from roles or lifecycle states are revocable.
• Entitlements that stand alone from roles or access profiles are revocable.
• Applications are not revocable.

The system does not account for access that is indirectly chained. For example, a role could contain entitlements A and B. A separate access profile could contain entitlements A and B. If a user receives the role, the access profile will be detected and presented as revocable. The role will re-add the entitlements if the access profile is revoked. The access profile would then be re-detected. We recommend adjusting your access model if you encounter this scenario.

More About Account Manual Correlation Flag
There’s a new manuallyCorrelated attribute on the account detail UI. manuallyCorrelated = true means that an account was directly assigned to an identity by id instead of using the account correlation configuration to match based on attribute values. When Identity Security Cloud provisions a new account via request, role, etc. it directly assigns the account to the identity by id. Accounts that are assigned to an identity via /v3/accounts/:id or the manual correlation UI are also considered to be manually correlated. We’ll be adding a new account attribute called origin that will tell you if an account is Aggregated or Provisioned . This will help you discern how the account is manually correlated. We’re going to build a manual correlation UI feature up around this.

More About Applications (Access UI)
The Access UI will always show tabs for Roles, Access Profiles, and Entitlements. It will hide the Applications tab unless the identity has applications. This feature simplifies the experience for organizations that don’t use applications.

Spotlight on the Helpdesk
You might not use the Helpdesk user level often. Take a minute to use the new experience as a Helpdesk user to understand how its capabilities have improved.

Deprecation of Custom Branding in Administrative UIs
Customers could set a Product Name in Global > System Settings > Product Branding and expect to see it referenced throughout the administrative UIs.

New UIs will not reference Product Name and will instead establish universal label presentations. This move simplifies the system and improves localization accuracy.

Did you notify us about this previously?
A Try New Experience button has been available to all administrators in all production tenants since August 2023. The button has been visible when viewing an identity’s details. Identity details is one of the most-visited pages in Identity Security Cloud. This button has enabled administrators to test the new UIs as we create them. We delivered 7 customer-facing announcements concerning our plans. Additionally, we delivered in-app notifications overlaid on the Try New Experience button for previous announcements #1 and #2.

1. New Capability: Identity Access UI (published: 2/29/2024)
2. New Identity Accounts UI (published: 12/7/2023)
3. Updates to Events UI: View Event Details (published: 10/2/2023)
4. New Identity Events UI (published: 9/18/2023)
5. New Identity Details UI (published: 8/1/2023)
6. New Identity List UI (published: 3/11/2023)

Are we able to switch back to the previous user interface?
Customers are not able to switch back to the previous user interface. The previous user interface is scheduled for retirement and the CC, v1, and v2 endpoints it uses are scheduled for deprecation.

See Deprecation: CC, V1, and V2 API Decommission Update for more details.

What’s next after I receive the Identity Management UIs in production?
You’ll be eligible to receive these forthcoming changes once you’ve received the identity management UIs in production.

These features are separate from the identity management experience and will roll out independently with their own announcements.

• Manage inactive identities: You’ll be able to mark lifecycle states as Active, Inactive (short-term), or Inactive (long-term). Identities will be marked as inactive depending on their lifecycle state assignment. Inactive identities will be removed from the Request Center, manager views, and elsewhere. Here’s the relevant announcement: New Capability: Management of Inactive Identities
• Manage accounts across all sources: A forthcoming Account Management UI will enable you to search for accounts, manage account correlation, and more.

Submit Questions or Feedback
The goal of this project is to deliver a substantial upgrade to the identity management experience. We are invested in addressing all concerns that are communicated to us.

Submit questions or feedback , and we’ll be in touch.

You could also schedule time to provide feedback over Teams!

[WyssAJ01 (Adam Wyss)]

@kirby_fitch I’m loving the new access page. That’s a big deal for a lot of people. I have a question though. Are the APIs that fetch that data available for our consumption?

I’m working with a client on a use case where they would like to be able to look up what entitlements are associated with an identity and I don’t currently see an endpoint able to do that without querying the accounts first.

[ethompson (Edward Thompson)]

Which data are you not able to get with APIs? Looking at the dev tools, they are using this for the entitlements:

/beta/historical-identities/{id}/access-items?type=entitlement&limit=25&offset=0&count=true

[WyssAJ01 (Adam Wyss)]

I was trying to use the entitlements API. I kind of forgot that the historical identities endpoint existed honestly.

[bburrell (Bakhari Burrell)]

Any one having this problem?

In this first screenshot, you’ll see that we have the ability to remove Accounts from an Identity. This is in the old UI. I’ve been using this feature to troubleshoot and test Provisioning Policy’s and rules on Identities.

However, in this second screenshot, you’ll see that on the new UI, this feature has been removed. We can no longer easily test rules and policies once an account has been attached to an Identity.

Any ideas?

[ethompson (Edward Thompson)]

The old UI used an API that does not have a replacement.

POST /api/account/remove

There will not be a public replacement available before March 31st.

[ccarlton (Chad Carlton)]

@kirby_fitch

More About Applications (Access UI)

The Access UI will always show tabs for Roles, Access Profiles, and Entitlements. It will hide the Applications tab unless the identity has applications. This feature simplifies the experience for organizations that don’t use applications.

Our organization does not use requestable roles. Is it possible to simplify the experience for organizations that do not use requestable roles?

[bburrell (Bakhari Burrell)]

Ah. I see. Thank you for pointing this out Edward!
Do you know if there is a workaround for this? I’m scrambling trying to find an alternate solution now.

[kirby_fitch]

Hi Adam, we recommend you use that!

[kirby_fitch]

We’re working on a new endpoint for remove as we speak. It should be listed as: POST /beta/accounts/:id/remove. We’ll bring this feature back when the endpoint is available. Sorry about that.

[kirby_fitch]

Do you use non-requestable or birthright roles? Those show in the same area as requestable roles.

[ccarlton (Chad Carlton)]

Perhaps there is a misunderstanding on my comment.

I am referring to the request center, roles section.

We do not use requestable roles, so the request center roles page is empty.

When clicked on it says “An admin needs to add at least one item to this page.”

I understood your blog post section to say, that if a tenant / identity doesn’t have applications, the applications section is hidden from the request center left hand navigation.

I was asking if it was possible to do the same logic for the roles section in the request center. Because we do not use requestable roles, there is no reason to display / click on this link.

[angelo_mekenkamp]

Please take into account that there are two different ways to interpret ‘removing an account’ and we need both. I already notice the impact of missing the button from the UI.

One way is to only remove the account from the knowledge space of IdentityNow (the target application should still have it), an account aggregation might bring the account back (or not, dependent on delta aggregation settings, maybe we only want it back if the account gets updated for example). If the account was the authoritative account, the identity should take the next authoritative account in the identity profile priority order as its new authoritative account. If such an account does not exists, it should treat all other related accounts as uncorrelated accounts again.

The other way is to trigger the deletion operation. This usually means it will delete the account form the application side as well. Would this last one get the API DELETE /beta/accounts/:id?

[angelo_mekenkamp]

I notice that as an admin you can’t aggregate/enable/disable your own accounts through the UI. Is this a security control? If so, I believe it creates a false sense of security as you can achieve the same thing by API anyways. Now it mainly is an annoyance to a developer that is trying out operations while onboarding a source. Are there any plans to remove this blocker?

[gmilunich (Geoff Milunich)]

Does anyone else find the new Details page for the Identity view to be cluttered and hard to read when searching for a value if there are a lot of identity attributes set up for a user? I just opened the new experience in a sandbox environment to check a value, and was surprised at how difficult it was to locate the value compared to the previous table view that was available. The field names are hard to see/discern from the rest of the text and it feels jumbled to me.

I also noticed that in the screen shot above it appears that the attributes are able to be placed in sections, but I don’t see this functionality available. I see there is a pinned section and was able to find out how to do that, but that was all I could find. If there was a way to group attributes into a section for like attributes (AD Attributes, Workday attributes, Username Attributes, email attributes, etc) that would go a long way into making this a better view and increase the readability of it.

[angelo_mekenkamp]

I agree with this. This matrix view of identity/account attributes makes it more difficult for me to read as well.

On another note, I see that the account details page has account attributes missing. If the source has an account schema containing the attributes status and id, it will not be visible in the account details list anymore. It will show id which is the id given by ISC, not by the application, and it will show status which is calculated by ISC (and called IIQDisabled in the API), not the status given by the application. This makes onboarding more difficult.

Also, if you go to a source, then click on accounts, you see a list of accounts, if you click on a record, it will bring you to the identities page. It would seem more logical to me if it brings you to the account details page instead.

Lastly, It would be great if clicking the process/disable/aggregate buttons will also check for the incoming data and then overwrite the values, making a page refresh redundant.

Kind regards,
Angelo

[gmilunich (Geoff Milunich)]

@kirby_fitch Will there be an option to go back to the original table view for clients? I was just asked this by a client who was surprised by the new UI in their Dev system. Their complaint was that they now needed to go back and redo all of the screenshots in their documentation, and it is harder to find the attributes they are looking for.

Another client ran into the issue that @bburrell mentioned with the Remove Account button missing, as they used that quire often.

I also agree with @angelo_mekenkamp that clicking on the account in the source should bring up the account details, not take you back to the identity.

[Sushantmr (Sushant Maharjan)]

@kirby_fitch,

1. Is there a feature in the new UI that allows users to determine if an account attribute is single-valued or multi-valued? I’ve noticed that values in multi-valued attributes are separated by commas in the new UI, whereas in the old UI, each value was displayed on a separate line. Distinguishing between a value that contains a comma and a genuinely multi-valued attribute isn’t straightforward. Is there a simpler method to differentiate between the two?
   New UI
   

   
   
   Old UI
   
   

2. By default, the attribute’s complete value isn’t fully displayed for a few with longer characters. To view the entire value, we need to hover the cursor over the attribute.
   

   

[kirby_fitch]

Thanks for the confirmation, @ccarlton. I’ll tag in the Product Manager for the Request Center to answer that. @jennifer_mitchell, could you speak to this?

[jennifer_mitchell]

Hi @ccarlton -
It is possible that we may revisit the request center behavior but the scale of this is a little different - one identity versus all requestable items in the system. Load times are a concern and are the reason the current behavior was chosen originally. Today, the Roles page’s contents in request center gets calculated when the user clicks it. Much more pre-processing would have to be done to decide in advance whether those page options should be shown or not, which would slow things down noticeably.