Dear MOSIP Team,
I have deployed regclient v1.2.0.2 & was trying to enable different auth modes(face, iris, fingerprint) for different purpose in regclient such as at the time of login, packet auth, exception auth etc.
The user through which I am trying to login has role supervisor, I have enabled finger, face and iris for it & disabled pwd.
Still when I am restarting the regclient I am getting only username and password field at the time of login.
I am not understanding why I am not getting option to sign in with the enabled auth types.
Am I missing on something or I need to configure some properties to enable diff auth modes??
Requesting you to help me out in order to resolve this problem.
Thanks for your response.
I have gone through the documentation which you have provided but I was not able to find any configuration related thing w.r.t enabling diff auths modes in regclient.
Here its only mention that we can enable multi factor login which will be configure by administrative.
Can you guide me on how to configure diff auths modes in regclient.
Yes, multi factor login can be enabled in reg-client based on the entries in the “app_authentication_method” table under mosip_master DB.
For each role, and for each process → auth factors and their sequence can be defined.
Entries by default exist in “app_authentication_method” table, enable or disable the is_active flag based on the requirement. Sequence can also be altered.
As of today we do not have any endpoint to update this table (as these changes are one-time decisions). This should be directly altered in DB.
Also remember to updated the upd_dtimes so that updated data is synced to reg-client in its next sync trigger.
I was able to enable multi-factor authentication after making the changes in the database. However, every time I do this, I typically restart the masterdata and syncdata pods, followed by a fresh restart of regclient. This results in the local database on regclient being deleted, causing all information to be lost, including operator biometric onboarding. Consequently, I have to onboard the operator again.
You mentioned that after making changes in the database and updating upd_dtimes, the changes should be reflected on the regclient during the next sync trigger. Could you please clarify the exact steps to follow so that the changes are reflected on regclient without losing any data? For example, do we need to run the sync job to apply these changes? If you could provide a step-by-step guide, it would be very helpful and would prevent loss of data on regclient.
Before jumping to step-by-step guide, it is good to know from where and how reg-client does the full and delta sync.
Registration client connects to kernel-syncdata-service to pull the required data like master data, configurations, server public keys, certificates, etc..
Full Sync → when reg-clients starts for the first time, sync is triggered. Once sync is done, lastSyncTime in the sync response is saved.
Delta Sync → sync is invoked with saved lastSyncTime to pull only changes done after the last sync datatime.
On the server side(kernel-syncdata-service), when the request is recevied with non-null lastSyncTime, server tries to fetch the changes from lastSyncTime to currenttime (last 15th minute)
For eg1: If the request is sent at 03:31 today then the changes done between lastSyncTime to today 3:30 will be sent back in the sync response.
eg2: If the request is sent at 12:55 today then the changes done between lastSyncTime to today 12:45 will be sent back in the sync response.
Step-by-step guide:
Assumption: Reg-client is already done with initial full sync.
Step1: Update upd_dtimes with current datetime in the app_authentication_method table.
Step2: Trigger master data sync manually after the next 15th minute in the reg-client.
Step3: Then logout, You should notice the new login auth method changes in the reg-client.
