New Capability: Identity Management

Is it possible to just have a global setting? It does not need to be a calculated thing.

Just provide a section in “Admin/System Features” where SailPoint admins can toggle off / on the display of “Applications” or “Roles” in the request center.

1 Like

Hi @Angelo_Mekenkamp_Hnk, we hear you on this one. Here’s the current plan.

  • We’re adding a new endpoint for removals. It’s in development right now. The new endpoint is: POST /beta/accounts/:id/remove endpoint. This endpoint will delete the account in Identity Security Cloud but not on the source. The Remove button will be updated to use this endpoint. Furthermore, it’ll be available on all sources. We’ll take care of this before we retire Try New Experience in production.
  • In the future, we’ll enhance the DELETE https://sailpoint.api.identitynow.com/beta/accounts/:id endpoint to support all sources that allow it. This endpoint will delete the account in Identity Security Cloud and provision a deletion command to the source. We would then add a Delete button where appropriate in the user interface. This should cut down on the need to use rules for deletions. This will come after we retire Try New Experience in production.
1 Like

Hi @Angelo_Mekenkamp_Hnk, we sustained behavior that’s been in place for many years on the previous UI. We might re-visit that decision in the future but will maintain it for now.

Hi @gmilunich, we support pinning your favorite attributes into the top card. Adding new sections is not supported at this time. Although I think it’s a great idea!

This new experience has been tested with 100+ administrators. We selected this design for these reasons:

  1. Admins noted that it was difficult to visually map attribute names to their value on wide screens with a lot of white space in the middle. We placed the label next to the attribute to resolve that concern.
  2. Admins noted that there was too much scrolling in tenants with a lot of attributes with a new row for each attribute. We condensed multiple attributes and their values in the same row to resolve that concern.
  3. We could see admins using Find in Page often to locate attributes of interest. We added attribute search to resolve that concern.

I’ll get with our design team to consider the feedback and determine next steps. Thanks for this!

Hi @gmilunich, I did in-line responses here:

We added the Try New Experience button in production in August 2023. The complete experience has been available under Try New Experience in production since February 1st. We’ve provided a long ramp so that customers can familiarize with the feature, provide feedback, and update documentation. We’re not able to support two experiences for the long-term. We’re doing our best to provide a good balance!

The Remove button is being developed right now and will make its return soon. We won’t promote this UI to production until it’s available.

We agree with you 100%. Once these new UIs are 100% rolled out and no longer behind the Try New Experience button, that gives us new options for linking to them from elsewhere!

I have to agree with both items that @Sushantmr posted above as well. Having the multi-valued items on a single line can be difficult to distinguish between values, especially versus the old process. On the flip side, it also makes it difficult to determine whether a single value field is really single valued or if it is multi-valued when it has a comma in it, as they display the same now to the user.

The second item @Sushantmr mentioned is more of a concern, especially with distinguished Names, as this cuts it off before you can see the domain, which is usually a good indication which environment you are in. It also requires you to now click the copy button to get the value. This means you can no longer copy just part of the DN out, you need to copy it first, paste it into another program and then copy just the portion that is needed. While this is likely primarily a developer issue, it is an increase in difficulty.

@kirby_fitch I appreciate the responses.

The pinned posts is useful and I can see value in having that. It is what made me think of the sections when I saw you already had that. When looking at the system as an Admin though, I usually need to look at the attributes for a specific application (AD, HR, etc) or a specific type (Email addresses, names, etc) and not usually my favorites. I can see there is benefit to being able to pin them, as I could pin the ones I am currently looking at, but having configurable categories would be more helpful to break up the giant blob of attributes there is now. You could take this further and allow attributes to have user-defined tags and then the sections can be of the tag name. Then the administrator could configure it how they like.

I do acknowledge that there is a lot of white space and a lot of scrolling when there are a a large number of attributes, but I feel the new interface trades the white space for a jumbled blob of attributes. It is a balancing act though with the differing size screens that people are viewing these on. I personally would have preferred a second/3rd row of Field/Value columns like there was previously depending on the monitor size. I think with the current view, if you could make the number of rows configurable, it would help mitigate the second issue that was mentioned above with values getting cut off. Then the user could decide to show less rows so that each row would have more space to display.

I did just go try out the Search Attributes feature based on your “Find on Page” comment and that is helpful, and would allow me to locate the attribute easier. It is nice that it searches both the name and the value. It can help mitigate some of the “giant blob of attributes” personal issue I mention if the attributes follow a naming convention that includes their application.

I recall seeing the try new experience button, however for administrators and developers that are working to get their projects into production, there is not always time to try these out. The admins might not have the data in their system to really see how the changes will affect them either.

For large UI changes like this, it might be better to add a notification to the Sandbox systems that a major UI change is coming, and they should review the changes. Providing a link to a page/blog with pictures of the new changes, and/or a video of them for admins to review might be a way to get better visibility to this in the future. You could leverage the Dev Rel team for this, as this platform seem well position for that.

This is great to hear. Is there an ETA on that?

Lastly, the field names roll over the divider gradient when you scroll down. (click to view it bigger)

I appreciate the discussion on this, and hope I am providing constructive feedback that is useful for your group.

1 Like

These are both fair points. I’ve got the team looking into this.

Yes, this would be cool! One thing we did here that might be causing trouble is that we show null attributes whereas we didn’t before. How many of the attributes are you looking at that have null values? Would having the option to filter nulls help?

I’ve got the team looking into our options here.

Glad it helps. There are better ways we can solve the “group by application” problem.

We’ve been communicating like this but it’s hard to reach everyone. We’ve put out an announcement for each step of this project (Details, Events, Events Details, Accounts, Access) with notifications on the Try New Experience button in-app and elsewhere. Those announcements did uncover issues we’ve since addressed. Retiring the old UI in sandbox has smoked out what else we needed to know. It’s an iterative process, and we’re on it. Thanks for your detailed feedback and patience while we work through these!

Could be in the next week or so. We’re wrapping up implementation on this.

I’ve got the team looking into this.

It is extremely useful. Thank you. If anything else comes to mind, let us know!

1 Like

Good call out, we’ll fix this.

We’ve always been unable to link as desired here due to how the old UI worked (no deep linking to accounts). The new UI supports deep linking to accounts. We’ll improve this once we’re able to roll the new UI out.

I don’t think the endpoints give the UI enough context to achieve this. We might have to stick with a page refresh for now.

The system I am referencing has roughly 100 attributes split into 4 columns. This particular system connects to 5-6 AD environments, so each has a Base User OU, User DN, Manager DN, and Term OU based on previous recommendations for handling OUs. This makes the issues mentioned (cut off values, jumbled attributes) more visible most likely.

For this example, there are roughly 1/4 that are Null values. I would say that having the option to hide nulls would be helpful. I would like to add the following to be considered if that approach is taken:

  • Nulls should not be filtered from the header or the pinned attributes. Sometimes you need to see that the attribute is null, and this could be a way to do that.
  • Nulls should show up if you use the search, even if hide nulls is configured. If I don’t see the attribute I am expecting, that is the first thing I am going to try.
  • Going Further, having a way to tag an attribute as Never Hide or Always Hide might be useful for configuring the view. For the second, always hide, this would be good if it was for an Admin to have a Show All button. This would allow some items that are needed for configuration (ie Base User OU) to be hidden from general view, as it is not needed in most day-to-day processes for managing users, and then shown if an issue needs debugging.

I realize it can be tough and there is no easy way to get everyone to see it. Some feedback I got with the “Try New Experience” button is that it was unclear if this would be reversible after trying. That was why I suggested having either it take you to a post that details the changes and exactly how the button worked, or having another link or hover text with further details that it can be changed back while in the trial state. I think several other sites/companies in the past have use this type of feature, but then you are stuck on the new one going forward, and many people are now weary of clicking the button for that reason.

An additional idea might be to have it done in 2 stages. “Try/Evaluate New Beta Experience” would be when you are gathering feedback and looking to have changes made. Then “Try New Experience” for the month before the roll out to allow users the ability to try the finalized feature and get screenshots to update their documentation. I know the finalized experience was rolled out to sandbox first, but it seemed like it was bang-bang for that, where as soon as the sandbox was rolled out, Prod was being rolled out very soon after. Forgive me if the timing was in line with my suggestion, but my perception of it was that they came faster (and I can’t find the sandbox roll-out announcement to check.)

Again, I am not sure what the answer is to this difficult problem, but these are the experiences I had with this one, and sone ideas on what could mitigate them in the future.

I appreciate that your group is working with the Dev Rel team to get this information out, and engaging with the constructive feedback from the developers.

@angelo_mekenkamp Hey Angelo, Lead UI Dev for this work. Point about the page refresh after an aggregation/enable/disable was found previously by another and the fix is finished but not deployed to prod yet! Good catch though.

Hey @kirby_fitch ,

  • Sailpoint provisioned AD accounts for new employees, and while the AD accounts were auto-correlated with identity, the “MANUALLY CORRELATED” attribute on the new UI displays as true. I’ve examined around 5 accounts in both the sandbox and production environments that were provisioned by Sailpoint, and in all cases, the “MANUALLY CORRELATED” attribute is set to true. Shouldn’t it be “false” for auto-correlated accounts?
    Could you please provide more information on the meaning of the “MANUALLY CORRELATED” attribute? Does it not relate to how the account was correlated?
    image

  • It appears that when viewing the values in the “account” attribute, multiple spaces are not shown even if they are present. The actual value on target is “Testing value 123”
    In Sailpoint:
    image
    In AD:
    image

However, when looking the same account via the API, the spaces are displayed.
image

Hi @Sushantmrj 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.

The spacing issue is a valid concern and we’re investigating that one. Thank you.

1 Like

That’s a good suggestion. We can definitely look into that!
Have you opened an idea on our Aha ideas portal for this? That would help us keep better track of the request and gauge the broader need as well.

HELP!
How do you sort Accounts by Source Name? It is so hard to determine which accounts a user has when it is only sorted by Name.

The Details page (and Account details) is now so cluttered and unreadable - we used to be able to copy/paste all of the attributes into XLS to be able to easily compare changes during unit/integration testing. Now it is all copying into a single column in random order :frowning: which means we can’t compare/identify the changes.

I think we’ve provided this feedback during design/testing but it doesn’t look like it was addressed.

On a positive note - the “Access” tab is definitely an upgrade - being able to see list of all Roles/APs/Entitlements/Apps in a sequential list is awesome :+1:. Pity this format is not applied to the other pages :confused: ?

…Alf

Hi Alf, responses below.

We’ll be bringing sorting to the Access tab. Here are some of the ones that will be sortable when that enhancement goes out. This work is in progress but will come sometime after the UI goes to prod.

Role > Name
Access Profiles > Name
Access Profiles > Source Name
Entitlements > Name
Entitlements > Value
Entitlements > Attribute
Entitlements > Source
Apps > Name

Sorry about this. We’ve had the new Details UI available under Try New Experience since August 2023. The feedback we had received to this point has been positive. We are considering changes based on recent feedback. I have a couple questions for you.

Is it valuable to alphabetically sort the attributes?

Wouldn’t it be preferable to use endpoints rather than UIs for unit and integration testing?

If there was a general Copy button that output all attributes and values into the clipboard, would that meet your needs? We envision it should paste back into an Excel file in this format:

We’re glad you like the Access tab. This format works well for access items!

1 Like

Hi folks,

We’ve been absorbing everyone’s feedback re: the identity attributes UI and would like to walk through the proposed enhancements with you. If you would be willing to participate, please schedule time with our UX Designer, @willcashman.

Here’s the scheduling link:

@WyssAJ01 @ethompson @bburrell @ccarlton @angelo_mekenkamp @gmilunich @Sushantmr @akasper

I second being able to sort the fields listed is very valuable. Sometimes a user will have 100s of entitlements and wanting to verify that they do / do not have something from the UI is a first step. Or while troubleshooting issues, the UI is one of the first places to check “did the user get Role X?”

Using endpoints can help the developer side, but there are many Admins that do not touch APIs unless required and only use the UI.

@kirby_fitch,

  • Is it feasible to add new column for Roles within the Access tab to distinguish whether a user got the role via Membership Criteria, Identity List, or Access Request?

  • I’ve noticed that all the identity attributes’ names on the “Details” page are in UPPERCASE, but when building roles by selecting “Identity Attribute” as the type, the attributes don’t appear in UPPERCASE. Is this intentional design?

  • While revoking a role from UI, it says entitlement instead of role.

2 Likes

Yes, but not in the near term.

Yes.

Thanks for pointing this out, we’ll fix it!

1 Like

Hi Edward,

We hear you loud and clear. We’ve got an enhancement project in progress to add sorting to these endpoints. Once the endpoints support sorting, we’ll update the UIs. SailPoint is a series of teams iterating continuously to meet your needs.