Using the Search UI, I was attempting to look up an identity based on the email address and if I used the actual, complete email address, it returned ALL identities. This seems like a bug.
If I modified the search to remove the last letter to give me this search query “attributes.email:[email protected]” the search returned the singular identity.
Searching for the exact value should return a single identity with that value, or multiple if that value still partially matches for additional identities.
What product feature is this related to?
Identity Security Cloud. Tested in Client Sandbox environment, and Ambassador Tenant
What are the steps to reproduce the issue?
Using a tenant with data in it (Ambassador with Demo Data works) do the following:
Log in as an admin.
Go to Identities and find a user with an email address and copy it.
Go to the Search UI and search for that email using the query “attributes.email:” where is the meail address you looked up.
Note that all identities are returned.
remove the last character from the email
Search again and notice the single identity is returned.
Do you have any other information about your environment that may help?
I had created a Developer Topic to see what options others recommended for this, and to document my own testing. It can be found here:
The best currently available approach/workaround, at least for the email, seems to be using the “exact” keyword, which allows you to search as one would expect, and does not return ALL identities when using the actual full email address. This might be good to have documented on the Search page. However, it fails because it is Case Sensitive, so if you do not know the case, then the approach Colin mentions quoting the whole thing, is correct.
Engineering has confirmed that this is not a bug. This is expected behavior. Attributes are indexed as both Text and Keyword. The Text index type strips out special characters and ignores casing, which makes it match on more of the identities. If you want to search by an exact attribute value, you would use attributes.attribute.exact.
This is a quirk of the Elastic Search query language, and not a SailPoint specific thing.
Thanks Colin! We got basically the same response from support:
The problem we have here is that @ is a special character in Identity Security Cloud that denotes a nested object. So what is actually happening here is:
When you search for [email protected], ISC breaks the string into two tokens using the @ as a separator and searches for sailpointdemo.com. Since that string is located in all identities, it returns all identities.
When you search for [email protected] it does the same as above but does not find anything as sailpointdemo.co is not a whole searchable (indexed) token. As a last resort, it tries to search for the whole string as a wildcard and then the search works.
When you search for “[email protected]” it ignores all symbols and tokens and treats whatever is within double quotes as a string. That’s why it works as expected.
Here is one of our articles, explaining why it’s important to use quotation marks when you want precision in your query results.
So this is actually as designed, per engineering and not a bug.
I do wonder if the documentation could use to be updated to account for the special case of how the @ operator in the email address is handled with regards to searching as described above. I did go back and review the link above to see if I missed anything related, but the only mentions of the @ symbol are with Nested Queries, and even then, there is no mention of it’s use within a string.
Additionally, when you get down to the Using Special Characters Section, there are no references to the @, but there is a Note that mentions “Dates, Phone Numbers, and emails do not need to follow these requirements”.
This seems contradictory to the details above, and no further details on any special requirements are provided for them. So I would think that some additional Documentation could be added with regards to the special handling of the email within searching.
