Option to not send back data as part of StringAttributeInputCallback

Setup
, , , ,
1

Hi,

We have a requirement to allow user to Authenticate using their PIN. For this, we have created a property for PIN in IDM. For this property, we have setup a few policies in IDM to enforce complexity.

In order to allow the user to set their PIN, we are using Attribute Collector. This works as intended when the user is setting their PIN for the first time.

However, in cases where a user already has a PIN set, and is trying to reset their PIN, the Attribute Collector sends back the original PIN in the callback. This behavior is not intended. Unfortunately, I couldn’t find any option to turn this behavior off.

My options are to use a StringAttributeInputCallback in a scripted decision node. However, this would mean that I need to handle policy validation myself, which is not ideal.

Another option that I came across is the Return by Default option in the property settings in IDM. Disabling this option gives me the required functionality. I am not getting the data in callback, and I am able to Patch the data and retrieve as expected. However, in order to enable this, we need to first enable this as a Virtual property. But in our use case, PIN is not a virtual property. However, everything seems to be working fine. What are the implications of setting this property as Virtual property?

What other options do I have?

1 Like
2

Hi @anishetty,

First of all, I am surprised that virtual must be set before being able to set the ReturnByDefault flag? Have you tried to update directly the json configuration (managed.json)?

Anyway, I would not recommend this approach. The PIN is left open to be read - ReturnByDefault set to false does not prevent a request with the field explicitly listed. A pin is confidential and secret, and therefore should be treated like a secret, e.g a password:

  1. Set the PIN attribute as “Private” in IDM. A private attribute is not accessible from external requests, but is for internal requests (you need this to sync it).
  2. Use a Platform Password Collector to acquire the user’s pin. After all, it’s like a password. In the settings set “PIN” as the password attribute, and enable validation.
  3. Ideally, the pin should be hashed, and I strongly recommend it. This will still allow validation, but in the AM journey, you’ll have to hash the user’s input to compare with the hash stored in the user profile to validate the user.

Kind regards
Patrick

2 Likes
3

Thank you for the suggestions.

  1. Setting the PIN as private attribute worked as expected.
  2. In our setup, we have both password and PIN attributes. So, I believe we don’t have a way to configure both of them as passwords, since the settings is at the connector level. Please correct me if I’m wrong
  3. We will implement this as well. Thank you for bringing this up.
1 Like