How to hide the User REST endpoint?

Hi, I ran into a difficult situation.

I have user accounts with custom profile field data that is sometimes considered private, like a phone number or an address.  I have configured the community to hide these fields from the user's profile field page, but this doesn't solve the issue of these profile fields being available via the REST API.  I know that Verint 12 has a feature to disable the generation of API keys, but at the moment we can't upgrade.

Some initial ideas that crossed my mind...

  • Create a plugin that implements a HTTP filter that block the endpoints that might leak the private data (GET User, maybe search?)
  • Maybe create an automation that removes private data when the User record is retrieved?  I don't think this would work well, but just wanted to throw it out there.
  • If I create a CustomPage at the same URL of the endpoint(s), maybe it would block the endpoint URL from being called?

Given GDPR and other security related requirements I'm hoping this has come up before.

What would be the best way to achieve this?

Thanks in advance.

Parents
  • Hi . Yes, this is a bit tricky. As with other REST endpoints, the User endpoint only makes accessible what would already be available to the the accessing user anyway. But if there's extra data that's stored in profile fields or extended attributes, the platform doesn't have a way of limiting the security of that beyond what the endpoint already does. We are investigating scoping REST accessibility, but even that would still not be granular enough for this kind of use case. The unfortunate recommended approach for now remains to not use profile fields or extended attributes to store private data that shouldn't be available alongside the rest of the entity to the same audience. 

Reply
  • Hi . Yes, this is a bit tricky. As with other REST endpoints, the User endpoint only makes accessible what would already be available to the the accessing user anyway. But if there's extra data that's stored in profile fields or extended attributes, the platform doesn't have a way of limiting the security of that beyond what the endpoint already does. We are investigating scoping REST accessibility, but even that would still not be granular enough for this kind of use case. The unfortunate recommended approach for now remains to not use profile fields or extended attributes to store private data that shouldn't be available alongside the rest of the entity to the same audience. 

Children
No Data