Options to "override" IIQ OOTB classes / methods with a Plugin: remove searchable identity attributes from Access Request's identity search

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

Dear colleagues,

we’re looking for a way to modify IIQ OOTB functionality using a Plugin (any other suggestions are also highly appreciated).

The requirement is to remove certain searchable identity attributes from the (identity) search page which is available during access requests because filtering by those attributes would
allow the requester to gain insights which should not be disclosed.

The same requirement was already discussed on Compass: https://community.sailpoint.com/t5/IdentityIQ-Forum/Hide-Filter-Access-Attributes-from-Manage-Access-in-SailPoint/td-p/165365

However the solution provided (also by the Plugin mentioned) is not stable/secure as it can easily be reverted by just using browser development tools.
For that reason we are looking for a solution to change the way the search page is build in the back-end so there is no easy way to bypass the mechanism.

Do you think this is achievable using a Plugin? Any ideas regarding the details to achieve this?
Do you see any other options to achieve the goal?

Thank you very much for your help which is highly appreciated.

Best regards,
Daniel

1 Like
2

Hi @daniel_neubert ,
I think the only option where you can control this would be create a new access request page along user selection and pagination and group selection with plugin and control the data being displayed or to modify the sailpoint xhtml and bundled js files.
I personally prefer doing a new access page with custom ui and stuff.

3

Hi @chaitanyav ,

thank you very much for your comment.
As our design principal is to stay with the standard as much as possible this option is definitely not the preferred one :wink:

I also should have mentioned that there is an idea created which also addresses our requirements: https://ideas.sailpoint.com/ideas/IIQ-I-914

Thank you.

4

Hi Daniel ,

I totally agree that this is pretty much very standard requirement for most of the client . Sailpoint would have added the configuration for both the user and access filter to show only extended attribute based on org requirement .

2 Likes
5

Hello Daniel,

Per my testing, the easiet solution shall be add the entry under the System Configuration:

<entry key="columnSuggestBlacklist">
  <value>
    <Map>
      <entry key="AuthenticationAnswer" value="*"/>
      <entry key="Identity" value="password"/>
      <entry key="Identity" value="$YOUR_ATTRIBUTE$"/>
    </Map>
  </value>
</entry>

This will affect all frontend pages which is using the ‘suggest’ REST endpoint. So you may want to evaluate if this may affect any other pages which is not intendend.

Thanks and Regards,

1 Like
7

Hi Mike,

thank you very much for sharing the “blacklisting option”.

However, as you already pointed out, this affects all areas of IdentityIQ and therefore is not a suitable solution in our case.
Adding an identity attribute to “columnSuggestBlacklist” would also prevent the suggestions from being populated e.g. within the identity search page in Advanced Analytics.

And just in case somebody want’s to apply these settings: the attributes per class should be defined as a comma-separated list as shown in the example below:

<entry key="columnSuggestBlacklist">
  <value>
    <Map>
      <entry key="AuthenticationAnswer" value="*"/>
      <entry key="Identity" value="password,$YOUR_ATTRIBUTE$"/>
    </Map>
  </value>
</entry>

Best regards,
Daniel

8

This would be good option when we talk about sensitive data .

9

Dear colleagues,

we found aother configuration option in UIConfig which is related to our requirements but does also unfortunately not help to meet them:

<entry key="disabledSuggestExtendedAttributes" value="<ID_Attrib_1>,<ID_Attrib_2>"/>

This will change the behavior in a way that those fields are display solely as plain text field in Advanced Analytics’ Identity Search.
So it will definitely help to hide the existing values but still allow searches for users who know the values they are looking for.

However this option is solely honored from the Advanced Analytics Identity Search page and does not help with the identity filters available during LCM Access Request.

Best regards,
Daniel

1 Like