The guide here lists down some of the important properties that may be customized for a given installation. Note that the listing here is not exhaustive, but a checklist to review properties that are likely to be different from default. If you would like to see all the properties, then refer to the files listed below.
IMPORTANT:
From the LTS version, All the properties are synced to the registration-client only from registration-default.properties file.
See Module Configuration for the location of these files.
Registration Client reaches SBI on 127.0.0.1 within the below configured port range. As per SBI spec, the allowed port range is from 4501 to 4600.
Timeouts in milliseconds are set during any http calls to SBI.
Quality score threshold based on modality, Possible values 1 to 100
Retry attempts, Possible values 1 to 10
Quality score threshold based on the modality for operator authentication, Possible values 1 to 100
Registration clients can be integrated with more than one bio-sdks. Possible values for "modality-name" are "finger", "iris" or "face".
SDK implementation class full name
mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.classname
SDK API version
mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.version
SDK implementation class constructor args - comma separated
mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.args
SDK initialization args, this will be passed as initparams
mosip.biometric.sdk.provider.<modality-name>.<vendor-name>.<key1>=<value1>
Quality threshold used by SDK to match modality
mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.threshold
Example configurations are shown below for MOCK SDK named as mockvendor:
On every successful biometric capture during registration, the Quality of the biometrics is computed by bio-sdk if below config is enabled. Possible values are Y/N.
mosip.registration.quality_check_with_sdk=Y
Jobs like RID sync, packet upload, and status sync are carried out in batches, number of registration records to be executed in a batch on every trigger.
Only the modalities configured will be collected during operator onboarding.
On every Pre-Registration application fetch in the registration page, clear all the captured data before the Pre-Registration application fetch. Set the field IDs which should not be cleared after the Pre-Registration application fetch. It is a comma-separated list of field ids as per UI-SPEC.
Storage Location to store the downloaded Pre-Registration Packets in the local system
Pre-registration applications fetch period, No. of days before the appointment date.
Comma-separated list of offline job IDs. Offline jobs are jobs that are not part of manual sync.
Comma separated list of untagged job IDs. Untagged jobs, which will be not part of manual sync but only from the scheduler.
Comma separated list of job IDs that need Registration Client restart.
Registration batch jobs scheduler.
Default CRON expression for scheduling the Jobs.
All the identified scanner implementations will be used to list the identified devices. For each device dpi, width and height can be configured. If it is not configured, it defaults to 0.
Values in this config mosip.registration.docscanner.id map support regex.
Enable GPS device for capturing the geo-location. If y, the GPS device will be enabled. If n, the GPS device will be disabled.
mosip.registration.gps_device_enable_flag=N
Model of the GPS Device
mosip.registration.gps_device_model=GPSBU343Connector
Timeout for connecting to GPS device
mosip.registration.gps_port_timeout=1000
GPS Serial Port in Linux machine
mosip.registration.gps_serial_port_linux=/dev/ttyusb0
GPS Serial Port in Windows machine
mosip.registration.gps_serial_port_windows=
The Distance Parameter for GPS Verification
mosip.registration.distance.from.machine.to.center=900000
To reset a password in the Registration Client, click Reset Password from the Actions menu in the top-right corner of the Home page. This redirects the operator to a configurable URL:
Note: The placeholder “mosip.api.internal.url” should be defined in application-default.properties.
This configuration determines whether supervisor approval is required before the Sync and Upload of registration packets.
If enabled (Y), the system requires a supervisor to review and approve the registration packets before it is synched and uploaded.
If disabled (N), the registration proceeds auto approving, and packets are automatically uploaded in the next scheduled job.
Additionally, the system will cross-check the resident’s biometrics with locally stored operator biometric templates to verify the registration.
Minimum disk space that should be available in the machine to proceed with registration - in MB
Location to store registration packets in the client machine:
Number of days allowed to start Registration Client without upgrade when software upgrade is available.
mosip.registration.softwareUpdateCheck_configured_frequency=60
Time in Seconds for forced log-out of the operator, if the operator is idle for the specified duration
mosip.registration.idle_time=900
Time in Seconds to display the warning message pop-up to the operator, if the operator is idle for the specified duration
mosip.registration.refreshed_login_time=600
Maximum no. of days for approved packet pending to be synced to a server beyond which Registration Client is frozen for registration
mosip.registration.last_export_registration_config_time=100
Maximum no. of packets pending EOD approval beyond which Registration Client is frozen for registration
mosip.registration.reg_pak_max_cnt_apprv_limit=100
Enable supervisor authentication feature. If y, supervisor approval will be enabled, else, will be disabled
mosip.registration.supervisor_approval_config_flag=Y
No. of days beyond audit creation date to delete audits
mosip.registration.audit_log_deletion_configured_days=10
No. of days beyond the registration date to delete synced and uploaded registration packet:
mosip.registration.reg_deletion_configured_days=1
No. of days beyond the appointment date to delete unconsumed pre-registration application data
mosip.registration.pre_reg_deletion_configured_days=1
The maximum duration to which registration is permitted without sync of master data
mosip.registration.sync_transaction_no_of_days_limit=5
Allowed a number of invalid login attempts:
mosip.registration.invalid_login_count=50
Used to configure the time (in minutes) for locking the account after crossing the configured invalid login count
mosip.registration.invalid_login_time=2
Configuration is used to check if any sync job is missed/failed beyond expected days, this configuration is checked every time the operator clicks on any registration process. We follow the below convention to create this config key.
mosip.registration.job api name as in sync_job_def table.frequency=value in days
#Maximum no. of days without running the Master Sync Job beyond which Registration Client is frozen for registration
mosip.registration.masterSyncJob.frequency=190
#Maximum no. of days without running the Pre-Registration Sync Job beyond which Registration Client is frozen for registration
mosip.registration.preRegistrationDataSyncJob.frequency=190
#Maximum no. of days without running the Packet Sync Status Job beyond which Registration Client is frozen for registration
mosip.registration.packetSyncStatusJob.frequency=190
#Maximum no. of days without running the Key Policy Sync Job beyond which Registration Client is frozen for registration
mosip.registration.keyPolicySyncJob.frequency=190
#Maximum no. of days without running the Registration Deletion Job beyond which Registration Client is frozen for registration
mosip.registration.registrationDeletionJob.frequency=190
#Maximum no. of days without running the Configuration Sync Job beyond which Registration Client is frozen for registration
mosip.registration.synchConfigDataJob.frequency=190
#Maximum no. of days without running the Audit Logs Deletion Job beyond which Registration Client is frozen for registration
mosip.registration.deleteAuditLogsJob.frequency=190
Date format to be displayed on acknowledgment slip, default value - dd/MM/yyyy hh:mm a
Date format to be displayed on Registration Client dashboard, default format - dd MMM hh:mm a
This guide contains all the details you may want to know about the operator onboarding.
To generate the first operator in MOSIP eco-system, refer to the steps below.
The Admin needs to:
Create the role Default in KeyCloak with all the other roles.
Create the operator' user account in KeyCloak.
Assign the operator user account with the Default role.
Perform Zone and Center mapping for the operator using the Admin Portal.
Onboard the operator machine using the Admin Portal. Machine' details can be extracted using the TPM utility
The operator will need to:
Download the latest registration client and login with the credentials set in KeyCloak. The operator will automatically skip Operator/Supervisor onboarding and reaches the home page of the registration client.
Register themselves in MOSIP and get a RID and UIN.
Once the operator is registered:
The Admin changes the role of the operator to either REGISTRATION_OFFICER or REGISTRATION_SUPERVISOR.
Deletes the role Default from KeyCloak so that no other user has the role Default.
This operator can now register and onboard other Supervisors and Officers.
Admin needs to map the operator' UIN in KeyCloak under Attributes with attribute name as individualId.
Admin needs to remove the "Default" role mapping for the operator' user account if it exists.
The operator needs to login (password based) to the Registration Client using Keycloak credentials.
The operator needs to ensure that the Registration Client machine is online.
The operator will land into the below page and needs to click on Get Onboarded
The operator needs to provide their biometrics and click Save.
All the biometric modalities displayed in the Operator biometrics page must be captured before clicking on Save.
Captured biometrics quality must be greater than or equal to the threshold displayed in the UI.
Note- The threshold values are configurable and can be set as per the ID issuer.
After successful onboarding, the operator is automatically re-directed to the registration client home page.
Note:
After successful onboarding of the operator, the templates are extracted from the captured biometrics using configured Bio-SDK. The extracted templates are stored in Derby DB. This can be used later for operator' biometric-authentication and also for local de-duplication checks during registration.
After the first login and successful on-boarding, the registration client would mandate the operator to login with the configured authentication mode decided by the administrator.
Any number of operators can login to a registration client machine but they need to be mapped to the same center where the machine is onboarded.
Login operator' user ID is case-insensitive.
Summarizing, on-boarding of an operator is successful only if,
The operator is active and not block listed.
The operator and the machine belongs to the same center.
The operator's User ID is mapped to their UIN.
The operator's biometric authentication is successful during on-boarding.
The system is online during on-boarding.
Operator logs into Registration Client for the first time and is redirected to Onboarding screen. Here, they need to capture all their biometrics and then click SAVE button.
Request from Registration Client goes to Registration Processor for operator authentication.
Registration Processor passes this request to ID Authentication where it checks whether the user is mapped to a valid UIN and then matches the biometrics sent in the request with the biometrics of the mapped UIN.
Success/Failure response sent back to Registration Processor based on the authentication result.
Registration Processor sends back this response to Registration Client.
After successful authentication, the captured biometrics are sent to configured Bio-SDK to extract templates.
Extracted templates are sent back from Bio-SDK.
The extracted templates are stored in local Derby DB.
These templates stored in local DB can be used later for operator's biometric-authentication and also for local de-duplication checks during registration.
MOSIP supports single factor and multi factor login including password, iris, fingerprint, and face authentication for registration client. An administrative configuration setting determines the mode of authentication login.
The registration client can authenticate an operator in offline mode using the locally stored biometrics templates (face/finger/iris) and password hash.
The registration client temporarily locks the operator’s account in case they provides an invalid password/fingerprint/iris/face for X times continuously to login (X is configurable). The temporary account lock lasts for X minutes (X is again configurable).
An Operator can logout of the registration client by:
Clicking on the Logout button,
Closing the registration client,
Being in-active on the registration client for configured amount of time after which they are automatically logged out.
Upon logout, any unsaved data will be lost.
Data will not be automatically saved in the database and will not be retained in memory though transaction details which is used for auditing will be captured and stored (except for PII data).
Note- Registration client provides an alerts to the operator ‘X’ minutes before reaching the auto logout time limit. Registration client displays a countdown timer in the alert. The operator can choose to dismiss the alert and continue working. This will also reset the timer to zero.
This guide helps the operator in setting up the registration client.
A Trusted Platform Module (TPM) is a specialized chip on a local machines that stores RSA encryption keys specific to the host system for hardware authentication.The pair is maintained inside the chip and cannot be accessed by software. By leveraging this security feature every individual machine would be uniquely registered and identified by the MOSIP server component with it's TPM public key.
To extract the TPM public key, use the TPM key extractor utility.
To onboard the machine and the operator, the Admin needs to:
Create and activate the registration client machine using Admin portal.
Create a user/operator account in Keycloak
Assign the operator a role of either the Supervisor or Officer using the Admin portal.
Finally, perform the User Zone mapping and User Center mapping in the Admin portal.
System prerequisites:
CPU - Dual Core Processor - 2GHZ
RAM - 16 GB
Local Storage Disk Space - 500 GB
USB 2.0 ports or equivalent hub.
Physical machine with TPM 2.0 facility.
Windows OS [10 v]
To setup the registration client:
Download the reg-client.zip from the hosted server.
Unzip the client. You can see the directory structure below.
Click run.bat to launch registration client.
The client always launches with the pre-loader screen which displays the information about the network status, build status verification, online status, etc.
First time launch
After the pre-loader, the login screen is displayed.
Any valid operator credentials can be provided to authenticate and start the initial sync.
On successful intial sync, the operator will be prompted to restart the application.
After the first launch, the operator can notice .mosipkeys and db folders created under the registration client setup folder.
Note: Deletion of either the .mopsipkeys or the db folder makes the application get into an invalid state and hence will fail to launch. To be able to launch the client again, the operator should make sure that both the folders are removed and then re-launch the client.
On the next launch after the initial sync,
The registration client login page provides the operator an option to select the language for viewing the registration client UI.
After successful login, the operator either lands into the operator onboard page or the home page.
For more details on operator onboarding, refer to Operator onboarding guide.
For more details on Home page, refer to Registration client home page.
Offline- Operator can use the registration client in offline mode to only do the registrations and EOD process. During offline mode, the operator authentication will be based on locally saved password hash. An operator can work in offline mode only if they have logged into to the registration client being online atleast once.
Online- Machine must be online for the registration client first launch. For any server-client sync or vice-versa, the registration client must be online. In the online mode, the client reaches out to the server for password authentication.
Note: On successful onboard of the operator, biometric templates of the operator are stored locally. Biometric authentication does not reach out to the server everytime, instead it is validated based on the locally stored templates on the registration client machine.
In the development environment, Registration client can be tested using mock SBI. Find the instructions to build and run the mock SBI, click here.
1. Incorrect username/password
2. Configuration / masterdata Sync failed
Default settings schema is configured as below:
All the connected devices are listed in this page.
Option to scan for SBI for any specific port range is available in this page.
If more than one device is idenitied, operator can choose amongst the listed devices to set the default device for the current login session.
Access control on this page is controlled via the settings-schema.
All the Registration Client related configuration key-value pairs are listed in this page.
Operator can set the local preference on the server configraton value, applicable only for permitted configuration keys.
Access control on this page is controlled via the settings-schema.
All the available background jobs are listed here along with their cron expression.
Every job's next and previous trigger time is listed along with the job name.
Privileged operator can update the cron expression of any job.
Synchornize Data in home page will trigger all of these listed jobs with just one click.
If the operator needs to trigger specific job, the same can be handled in this page.
Access control on this page is controlled via the settings-schema.
Clicking on in the home page opens a pop-up displaying configured Settings page as per the above sample settings schema.
