Hello @zeross
The said issue was identified and is fixed. This was limited just to non-english browser prefrences using the tenant. And hence SB & PRD once released will also have the issue fixed.
Let us know if you find it otherwise or any such issue around non-english UI.
1 Like
In addition to this, if, through the UI, add a “does not contain” criteria to an Account Attribute on a Role then the VS Code extension will not produce a CSV export and just produces an error.
Error running command vscode-sailpoint-identitynow.csv.export.roles-icon.view: Invalid operation. This is likely caused by the extension that contributes vscode-sailpoint-identitynow.csv.export.roles-icon.view
I have proven this by removing the “does not contain” criteria from the Account Attribute in the UI, and once again the VS Code extension can produce a CSV of all Roles in the instance.
Hello @mikeq
Can you open an issue in tge GitHub repo for the same VSCode extension. The team will get this issue fixed. As this is still a new implementation that has come out for the new types of criterias & multi valued.
Thanks
1 Like
Thanks, have raised it as a feature request on the github repo.
Presumably the API will also need to be updated to support this stuff, which I don’t think it has yet. Couldn’t see anything in the Beta APIs supporting these changes.
Hey Mark,
I can say that the experience around the UI and NavBar is one that the PM and UX Design teams are actively having a discussion around, with opportunities coming to provide direct feedback to the teams.
2 Likes
Has anyone had issue with this feature not working when using the “contains” operation?
Hello @PGookin, customer question: They can see it in SB. When will it be in PROD? Thanks in advance!
Daniel C, CSM
Bug information needs to be shared. This “bug” took out access for over 6000 of our users on Friday causing a MAJOR incident! Not good!!
Update! The initial announcement indicated that null value handling was being modified. However, for this release, Null value handling will continue to behave as it did previously. Identities without an account will still be selected in the case of a false expression match.
The current behavior is being maintained to prevent any impact on existing implementations. Any tenants that were already enabled with the new null value handling will be rolled back to the previous version.
We plan to address this issue in a follow on release as soon as possible and we sincerely apologize for any inconvenience.
Hi @angelo_mekenkamp we have decided to maintain the current behavior for account selection based on null values to avoid impacting customers who have implementations based on how it currently works.
Hi @PGookin,
Thank you for the update.
I strongly recommend SailPoint Product Managers (and/or their delegates) to read the responses of announcements they made in this forum in a timely manner. After all, I did warn about this issue before it was even released to non-production tenants.
I think for this case, if the comments were read and acted upon in a timely manner, the major incident experienced by @vbeth27 and perhaps other tenants could have been prevented. Or have I missing something here?
Note that the issue of unexpected deprovisionings was not caused here by the fact that there was a bug in the system, but by the way how the bug got resolved. Functionality/behavior was changed by SailPoint without properly allowing end users to migrating the behavior of those tenants who were depending on the behavior as it was implemented for multiple years already, even though it had a bug.
I also recommend to release these announcement earlier, allowing more people to be aware of the upcoming changes, raise concerns, or prepare for the changes.
Then for the fix. In order to properly go from the undesired state that we are “stuck” in now due to tenants that over time started to rely on this functionality behaving the way it does now, I recommend to perform the following changes in order.
- Document the current behavior and note that this is a known limitation on which a fix is prepared for.
- Deploy a new criteria option for role membership
hasAccountInSource, where one can pass the reference (nameorid?) of a source. Similar havehasNoAccountInSource, which is the opposite. - Add a temporary global configuration called something like
roleMembershipNullValueIncludeIdentitiesWithoutAccountswhich is by defaulttruefor current tenants (to ensure backwards compatabiliy) andfalsefor new tenants that don’t have to work with the old way. - Announce a deprecation of the old way, ask everyone to migrate their roles (where they can use
hasNoAccountInSourceandhasAccountInSourceto ensure the desired behavior is kept, but with a more clear configuration) and to switch the global feature once they are ready to use the desired behavior. - Wait X months/years, ensure tenants are aware and migrated before a given deadline.
- Remove the temporary global configuration as the migration is complete and all tenants can now behave in the correct way, without causing undesired (de)provisioning, by using the desired configuration.
Kind regards,
Angelo
3 Likes
Hi, fairly new to using Identity Security Cloud within our organisation so this type of change is my first experience of how this is carried out with your product.
As an observation I really think that releasing updated features such as this should be done in tandem with the APIs being updated, even if it is Beta APIs. So although there is new functionality we are not in a position to use it as it is not supported by the APIs.
Even a single value equals has now changed how it is returned with a new “values” field not catered for in the API, so potentially breaking our existing Roles workflow.
There is also the potential for an admin to not realise using the new Role functionality could break our “config as code” workflow and potentially break our Role assignments.
For info:
VS Code Extension feature request: Support recent enhancements to Automated Role Assignment · Issue #119 · yannick-beot-sp/vscode-sailpoint-identitynow · GitHub
and from that the Bug that Yannick raised on your own repo: [Bug] Role membership · Issue #867 · sailpoint-oss/developer.sailpoint.com · GitHub
I never got an answer to my post requesting a preview of API changes, and as mentioned above by Mike Quinn the API changed in a non-backward-compatible way, which broke our scripts: ideally this should have been thought through, and before/after API examples given as part of the announcement.
Separately, I concur with @angelo_mekenkamp that it would be good to have a path towards resolving the “null issue” cleanly.
1 Like
Please note that there seem to be some bugs in the membership criteria for entitlements.
I select Entitlement → choose source → choose EQUALS, and when every I select an entitlement it sometimes disappears instead of being visible as list below. I also sometimes observe this error in the UI The following "roleCriteria.entitlementAttr" values do not exist in the system: "[]".
I think this is mostly related to the fact that the data structure of entitlements are not always fully understood or taken into account by SailPoint functionality.
Please note that one source can have multiple entitlement types (can have types names different than group ). And entitlements can have the same value and name, even within the same source, since they can belong to different types. Based on how the JSON of the role with membership looks like, it seems that this is not properly taken into account.
I see that the documentation is not updated yet to take into account multiple options for EQUALS operation. @saas_docs_team , FYI. Please ensure that this documentation is here and clear on what it does. Please note that you have the default AND/OR operations for membership criteria, but it is not clear in the UI (and absent in the documentation) if multiple options in the same EQUALS operation will be considered an OR operation or and AND operation. Someone who wants to give a role to everyone who has two specific entitlements in the same source might expect to just describe both entitlements in the same EQUALS statement and expect it will work.
Kind regards,
Angelo
1 Like
Hi @angelo_mekenkamp. Thanks for the docs feedback. We’ll look into this and update here with our findings.
Hi @angelo_mekenkamp I haven’t been able to reproduce the issue you’re seeing with entitlements disappearing. I’ve tested this with a source that has multiple entitlement types and duplicate naming across types but I’m not seeing the issue. If you could open a support ticket that would be helpful.
Multiple values in an equals expression are treated as an OR operation. We will be updating the doc to clarify the behavior. We are also considering adding “equals any” and “equals all” operators in a future release to provide support for both AND or OR expressions against a value list.
Thank you for bringing these issues to our attention!
Patrick
Hi @PGookin , Thank you for your quick response. I already have created a support ticket for this. Please see CS0403789, which also contains screenshots. I can reproduce this bug. I am happy to have a call with you to demonstrate the issue if you like.
Also note that it is regardless of the bug not clear in the UI which entitlements you are adding as in the UI you are not seeing the entitlement type or value, only the name, which is not necessarily uniquely defined.
And if your source name is Production - Azure, you can’t just start type for Azure and then see the results. You have to type the whole prefix first, which makes it more difficult to quickly select the correct source. I suggest it filters on contains operation instead of start_with. Especially since the UI itself does mark your typed substring regardless of location. For example if the source is Production - Proxy - ... and you search for Pro, you will see both Pro in Production and Pro in Proxy highlighted in bold.
Kind regards,
Angelo
@angelo_mekenkamp The EQUALS definition has been updated to specify that multiple values are compared as OR operations. Thanks for helping to make the docs better.
1 Like
Did you get a solution to this? I’m running into the same error when trying to set the membership criteria based on entitlements both in the UI and via roleImporter.
No not yet, @aaron
I have observed and communicated 5 issues with this functionality that is mostly based on the implementation having a wrong understanding on what uniquely defines an entitlement in ISC. This requires a fix in multiple APIs, UI, missing validation that should have picked up this issue and the strange disappearing of divs in the HTML.
the support engineer was not able to reproduce the issues as they were not testing under the right conditions that would trigger this issue. I demonstrated the issues in a call in a second attempt to communicate these issues, but the support engineer did not yet understand them properly so now we are trying to plan a call with someone from the engineering team to directly communicate this issue to.
unfortunately my agenda was full and I am also out of office for a couple of days, so this third communication attempt will be in a couple of days.
please note I generally observe it takes a couple of months before the support ticket has an internal bug ticket created and then it will take time before it is properly fixed. Based on this I don’t expect these bugs to be fixed soon.
tl;dr - this is still in the phase “SailPoint to understand and accept the bug”
Kind regards,
Angelo