Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In previous versions (1.1.5.x) of our system, we utilized the mosip-partner-client
for Partner Management Services (PMS). However, starting from version 1.2.0.1 onwards, we have implemented the use of mosip-pms-client
instead. This transition has led to updates in service account roles, client scopes, and client configurations.
Please find below the details of the changes made to service account roles and client scopes.
mosip-partner-client (1.1.5.x) | mosip-pms-client (1.2.0.1) |
---|---|
In version 1.1.5.x, the mosip-admin-client
was utilized for administrative services. We are also continuing to utilize the same client in version 1.2.0.1. While there have been modifications to the service account roles, the Client scopes have remained unchanged. Please find below the updated service account role adjustments. Additionally, it is worth noting that MOSIP Commons is also utilizing this client.
Service account roles for Admin-Services:
Client scopes are the same for mosip-admin-client in 1.2.0.1 & 1.1.5.1
profile
roles
web-origins
In version 1.1.5.x, we utilized the 'mosip-prereg-client' for Pre-Registration. This client is also utilized in version 1.2.0.1. There have been modifications in the service account roles, while the client scopes have remained unchanged. Please find below the updated service account roles.
Service account roles for Pre-Registration:
Note: Prior to proceeding with the upgrade, please ensure that the INDIVIDUAL
role has been removed.
Client scopes are the same for mosip-prereg-client in 1.2.0.1 & 1.1.5.1
profile
roles
web-origins
In the previous version 1.1.5.x, the mosip-ida-client
module was responsible for handling ID authentication. However, starting from version 1.2.0.1, we have switched to using mpartner-default-auth
for this purpose. This transition has brought about several changes, including modifications to service account roles, client scopes, and client configurations. Below is an overview of the changes in service account roles and client scopes.
Service account roles for id-authentication:
Client Scopes for id-authentication:
In the previous version, 1.1.5.x, we did not employ any clients for our digital card service. However, in the latest version, 1.2.0.1, we have implemented the use of the mpartner-default-digitalcard
client. Please find below the service account roles and client scopes associated with the mpartner-default-digitalcard
client.
Service account roles assigned to _mpartner-default-digitalcard_** in 1.2.0.1**
CREATE_SHARE
CREDENTIAL_REQUEST
default_roles_mosip
PRINT_PARTNER
PUBLISH_CREDENTIAL_STATUS_UPDATE_GENERAL
SUBSCRIBE_ CREDENTIAL_ISSUED_INDIVIDUAL
SUBSCRIBE_IDENTITY_CREATED_GENERAL
SUBSCRIBE_IDENTITY_UPDATED _GENERAL
Client scopes assigned to _mpartner-default-digitalcard_** in 1.2.0.1**
profile
roles
web-origins
In version 1.1.5.x, we do not employ any clients for printing. However, beginning from version 1.2.0.1, we utilize the mpartner-default-prin
t client. Please find below the service account roles and client scopes associated with the mpartner-default-print
client.
Service account roles assigned to _mpartner-default-print_** in 1.2.0.1**
CREATE_SHARE
default_roles_mosip
PUBLISH_CREDENTIAL_STATUS_UPDTAE_GENERAL
SUBSCRIBE_ CREDENTIAL_ISSUED_INDIVIDUAL
Client scopes assigned to _mpartner-default-print_** in 1.2.0.1**
profile
roles
web-origins
In version 1.1.5.x, we utilized the mosip-regproc-client
for id-repository. Starting from version 1.2.0.1, we have transitioned to using mosip-idrepo-client
. This switch has led to modifications in service account roles, client scopes, and client settings. Below are the details of the changes in service account roles and client scopes.
Client Scopes for id-repository:
Service account roles for id-repository:
In version 1.1.5.x, we utilized the mosip-resident-client
for Resident Services. This client is also employed in version 1.2.0.1. Although there were modifications in service account roles, the client scopes remain unchanged. Below the details of the alterations made in service account roles.
Service account roles for Resident-Services:
Client Scopes for Resident-Services:
In previous iterations (1.1.5.x) of our system, we did not employ any clients for the compliance toolkit. However, beginning with version 1.2.0.1, we have implemented the use of mosip_toolkit_clien
t. The following information outlines the service account roles and client scopes associated with mosip_toolkit_client
.
Service account roles assigned to _mosip_toolkit_client_** in 1.2.0.1**
default_roles_mosip
Client scopes assigned to _mosip_toolkit_client_** in 1.2.0.1**
profile
roles
web-origins
mosip-partner-client (1.1.5.x) | mosip-pms-client (1.2.0.1) |
---|---|
mosip-admin-client (1.1.5.x) | mosip-admin-client (1.2.0.1) |
---|---|
mosip-prereg-client in 1.1.5.x | mosip-prereg-client in 1.2.0.1 |
---|---|
mosip-ida-client in (1.1.5.x) | mpartner-default-auth (1.2.0.1) |
---|---|
mosip-ida-client (1.1.5.x) | mpartner-default-auth (1.2.0.1) |
---|---|
mosip-regproc-client (1.1.5.x) | mosip-idrepo-client (1.2.0.1) |
---|---|
mosip-regproc-client (1.1.5.x) | mosip-idrepo-client (1.2.0.1) |
---|---|
mosip-resident-client (1.1.5.x) | mosip-resident-client (1.2.0.1) |
---|---|
mosip-resident -client (1.1.5.x) | mosip- resident -client (1.2.0.1) |
---|---|
offline access
CREATE_SHARE
REGISTRATION_PROCESSOR
default_roles_mosip
uma_authorization
DEVICE_PROVIDER
PARTNER
PARTNER_ADMIN
PMS_ADMIN
PMS_USER
PUBLISH_APIKEY_APPROVED_GENERAL
PUBLISH_APIKEY_UPDATED _GENERAL
PUBLISH_CA_CERTIFICATE_UPLOADED_GENERAL
PUBLISH_MISP_LICENSE_GENERATED_GENERAL
PUBLISH_MISP_LICENSE_UPDATED_GENERAL
PUBLISH_OIDC_CLIENT_CREATED_GENERAL
PUBLISH_OIDC_CLIENT_UPDATED _GENERAL
PUBLISH_PARTNER _UPDATED _GENERAL
PUBLISH_POLICY_UPDATED _GENERAL
REGISTRATION_PROCESSOR
SUBSCRIBE_CA_CERTIFICATE_UPLOADED_GENERAL
ZONAL_ADMIN
add_oidc_client
profile
roles
get_certificate
web-origins
profile
roles
send_binding_otp
update_oidc_client
uploaded_certificate
wallet_binding
web_origins
MASTERDATA_ADMIN
Default-roles-mosip
offline_access
ZONAL_ADMIN
uma_authorization
offline-access
PUBLISH_MASTERDATA_IDAUTHENTICATION_TEMPLATES_GENERAL
PUBLISH_MASTERDATA_TITLES_GENERAL
PUBLISH_MOSIP_HOTLIST_GENERAL
uma_authorization
INDIVIDUAL
offline_access
PRE_REGISTRATION_ADMIN
PREREG
REGISTRATION_PROCESSOR
uma_authorization
default_roles_mosip
PRE_REGISTRATION_ADMIN
PREREG
REGISTRATION_PROCESSOR
AUTH
AUTH_PARTNER
ID_AUTHENTICATION
offline_access
uma_authorization
CREDENTIAL_REQUEST
default_roles_mosip
ID_AUTHENTICATION
offline_access
PUBLISH_ANONYMOUS_PROFILE_GENERAL
PUBLISH_AUTH_TYPE_STATUS_UPDATE_ACK_GENERAL
PUBLISH_AUTHENTICATION_TRANSACTION_STATUS_GENERAL
PUBLISH_CREDENTIAL_STATUS_UPDATE_GENERAL
PUBLISH_IDA_FRAUD_ANALYTICS_GENERAL
SUBSCRIBE_ACTIVATE_ID_INDIVIDUAL
SUBSCRIBE_APIKEY _APPROVED_GENERAL
SUBSCRIBE_APIKEY _UPDATED _GENERAL
SUBSCRIBE_AUTH_TYPE_STATUS_UPDATE_ACK_GENERAL
SUBSCRIBE_AUTH_TYPE_STATUS_UPDATE_INDIVIDUAL
SUBSCRIBE_CA_CERTIFICATE_UPLOADED_GENERAL
SUBSCRIBE_CREDENTIAL_ISSUED_INDIVIDUAL
SUBSCRIBE_DEACTIVATE_ID_INDIVIDUAL
SUBSCRIBE_MASTERDATA_IDAUTHENTICATION_TEMPLATES_GENERAL
SUBSCRIBE_MASTERDATA_TITLES_GENERAL
SUBSCRIBE_MISP_LICENSE_GENERATED_GENERAL
SUBSCRIBE_MISP_LICENSE_UPDATED_GENERAL
SUBSCRIBE_MOSIP_HOTLIST_GENERAL
SUBSCRIBE_OIDC_CLIENT_CREATED_GENERAL
SUBSCRIBE_OIDC_CLIENT_UPDATED_GENERAL
SUBSCRIBE_PARTNER_UPDATED_GENERAL
SUBSCRIBE_POLICY _UPDATED_GENERAL
SUBSCRIBE_REMOVE _ID_INDIVIDUAL
uma_authorization
profile
roles
web-origins
add_oidc_client
profile
roles
update_oidc_client
web-origins
profile
roles
web-origins
profile
roles
web-origins
ABIS_PARTNER
CENTRAL_ADMIN
CENTRAL_APPROVER
CREDENTIAL_INSURANCE
CREDETIAL_PARTNER
Default
DEVICE_PROVIDER
DIGITAL_CARD
FTM_PROVIDER
GLOBAL_ADMIN
INDIVIDUAL
KEY_MAKER
MASTERDATA_ADMIN
MISP
MISP_PARTNER
ONLINE_VERIFICATION_PARTNER
POLICYMANAGER
PRE_REGISTRATION
PRE_REGISTRATION_ADMIN
PREREG
REGISTRATION_ADMIN
REGISTRATION_OFFICER
REGISTRATION_OPERATOR
REGISTRATION_SUPERVISOR
ZONAL_ADMIN
ZONAL_APPROVER
default_roles_mosip
ID_REPOSITORY
offline_access
PUBLISH_ACTIVATE_ID_ALL_INDIVIDUAL
PUBLISH_AUTH_TYPE_STATUS_UPDATE_ALL_INDIVIDUAL
PUBLISH_AUTHENTICATION_TRANSACTION_STATUS_GENERAL
PUBLISH_DEACTIVATE_ID_ALL_INDIVIDUAL
PUBLISH_IDENTITY_CREATED_GENERAL
PUBLISH_IDENTITY_UPDATED _GENERAL
PUBLISH_REMOVE _ID_ALL_INDIVIDUAL
PUBLISH_VID_CRED_STATUS_UPDATE_GENERAL
SUBSCRIBE_VID_CRED_STATUS_UPDATE_GENERAL
uma_authorization
CREDENTIAL_ISSUANCE
CREDENTIAL_REQUEST
offline_access
RESIDENT
uma_authorization
CREDENTIAL_REQUEST
default_roles_mosip
offline_access
RESIDENT
SUBSCRIBE_AUTH_TYPE_STATUS_UPDATE_ACK_GENERAL
SUBSCRIBE_AUTHENTICATION_TRANSACTION_STATUS_GENERAL
SUBSCRIBE_CREDENTIAL_STATUS_UPDATE_GENERAL
uma_authorization
profile
roles
web-origins
ida_token
individual_id
profile
roles
web-origins
First, we will compare the thumbprints in the key_alias tables' thumbprint column of the mentioned IDA and Keymanager DB.
To check if the thumbprints are the same in both databases, we can follow these steps. For demonstration purposes, we will use 'mpartner-default-auth' as an example.
In the results of the above query, if it is found that the thumbprints do not match, the next objective is to take the MOSIP signed certificate from keymanager and store it in IDA manually, so that they match.
Here is a simple method to accomplish that task.
A. Perform the required authentication at authmanager portal using the below swagger URL
Sample request body:
B. Get the certificate using following swagger URL
In the app_id
field use : PARTNER , in the ref_id
field use : name of the partner whose cert thumbprints are mismatching such as mpartner-default-auth
.
Sample response:
C. Now, reauthenticate in the same authmanager URL (note the different clientId , appId and corresponding secret key changes )
https://api-internal.dev.mosip.net/v1/authmanager/swagger-ui/index.html?configUrl=/v1/authmanager/v3/api-docs/swagger-config#/authmanager/clientIdSecretKey
Sample Request
D. After getting the certificate through step B mentioned above, copy it and use it in the following POST request in the below swagger URL:
https://api-internal.dev.mosip.net/idauthentication/v1/internal/swagger-ui/index.html?configUrl=/idauthentication/v1/internal/v3/api-docs/swagger-config#/keymanager/uploadCertificate
In applicationId
field use IDA
and in the referenceId
field use name of the partner whose cert thumbprints are mismatching such as mpartner-default-auth
.
Sample request
After successfully completing this final step, we can proceed to the SQL cmd check mentioned at the beginning of this document and ensure that the thumbprints now match.
Always ensure that you are using the correct base-url for your environment. In our case, it is dev.mosip.net and this should be used in all swagger links. Make sure to change it according to your requirement.
If you encounter an error code such as "errorCode": "500", "message": "401 Unauthorized", please re-authenticate using the authmanager token provided and ensure that you are using the proper credentials.
If you receive a 400 Bad request error, please resend your request with the correct time format and verify that your request JSON is in the specified format.
If you encounter any other issues, please remember to post your queries on the MOSIP Community.
If a country desires to designate specific data sharing to be transmitted on HTTP or HTTPS endpoints, they should accomplish this by including the Domain URL of the data sharing in the policy field itself. This will have priority over any other settings.
Furthermore, two new fields have been incorporated into the policy:
shareDomainUrlWrite
: This field should be employed by individual modules when calling the data sharing functionality to write data.
shareDomainUrlRead
: This field should be used by the data sharing functionality when generating a URL to share with modules for reading data.
Note: It is important to note that these fields are compatible with previous versions and are not obligatory to include in all policies. They can be utilized only if a country sees a need for the new features.
Here's how to fix it!.
The key point to note here is that MOSIP only accepts partners whose client certificates have a minimum of 1 year of validity remaining. MOSIP re-signs the client certificate with a 1-year validity. The respective partner must renew their certificate before the MOSIP-signed certificate expires in order to continue communication with MOSIP.
However, if this renewal is not done, the certificates will expire.
Here is a three-step process to address this scenario:
a. How to check the validity of your partner's certificate?
To check the validity, the user must have access to the database.
The user can access the mosip_keymanager
database and open two tables: ca_cert_store
and partner_cert_store
.
The ca_cert_store
table stores the CA and SUBCA/Intermediate CA certificates, while the partner_cert_store
table stores the PARTNER/CLIENT certificates. In both of these tables, there are columns named cert_not_before
and cert_not_after
which provide details about the validity of the partner's certificate.
b. How to extend the validity of the partner's certificate?
There are two categories of partners: MOSIP Internal partners (e.g., IDA) and External partners (e.g., Device Partners, MISP partners).
For MOSIP Internal partners, if the validity of their certificate needs to be increased, the onboarder script can be run again for that specific partner. The onboarder will create fresh certificates and upload them to extend the validity.
For External Partners, they will need to obtain fresh certificates from their CA and upload them to extend their validity.
c. Troubleshooting common errors:
KER-ATH-401 Authentication Failed
If the user encounters this error code, it means that the user is not authenticated. The user should authenticate first before using the API.
KER-PCM-005 Root CA Certificate not found
.
If the user encounters this error code, it means that there is an issue with either the CA or SUBCA certificate. The user must resolve the CA/SUBCA issue first.
This document addresses how an error in Database upgrade script can be managed effectively.
If the below error has been encountered while attempting to execute the upgrade script, this can be resolved by following the steps mentioned in this document.
Error message
The error message states that a unique index, named cert_thumbprint_unique
, cannot be created due to a duplicate entry. Specifically, the values for the cert_thumbprint
and partner_domain
columns, which are (231bd472ab24ef60ec6*******2cace89c34, AUTH), already exist in the database. This duplicate entry violates the unique constraint defined for the ca_cert_store
table in the mosip_keymanager
database.
To address and successfully execute the DB upgrade script, the following steps can be taken:
Identify the duplicate entries in the mosip_keymanager table.
To accomplish this, use the provided SQL query:
This query will retrieve the rows of data that contain duplicate entries.
As a precautionary measure, it is advisable to create a backup of all the duplicate values.
Remove the duplicate entries so that only one composite key remains. The aforementioned SQL script can be reused to verify that the duplicates have been successfully deleted. If the result is empty, then all duplicates have been removed.
By following these steps, the problem should be resolved, and the DB upgrade script can be executed without any further issues.
After running the reprocess utility and regproc reprocessor, it is possible that a few packets may end up in the FAILED status. This can occur due to various reasons such as environment instability or high parallel processing of packets. The following steps will help in identifying if such packets exist and how to handle them.
To handle these packets, please follow the below steps:
Use the sample query below to find out if there are packets in a non-recoverable state:
Here, cr_Dtimes
should be less than the time of upgrade completion and the processing of the first packet. latest_trn_Dtimes
should be greater than the time of upgrade completion and the processing of the first packet. If there are no packets in this status, no further action is required. If any packets are found with the above status, proceed to step 2.
Before running the reprocess utility to process the packet from the beginning as per the APPROACH 1 in document, update the DEFAULT QUERY in the config.py file as per the requirements to process non-recoverable records.
The sample query is as follows:
Here, the status code should be set to FAILED. cr_Dtimes
should be less than the time of upgrade completion and the processing of the first packet. latest_trn_Dtimes
should be greater than the time of upgrade completion and the processing of the first packet.
After changing the query in config.py, please refer to the documentation on how to set up and run the reprocessor script.
To reprocess packets, use the following command:
This document helps in addressing an error related to partner organization name mismatch.
How do we handle this error?
During the partner certificate renewal process, users may encounter an error message while uploading the partner certificate.
The error code KER-PCM-008 indicates a partner organization name mismatch.
This error suggests that the organization name on the partner's certificate is different from the one originally registered with.
To resolve this issue, users need to manually update the name
column in the partner
table of the mosip_pms
database with the new organization name from the fresh certificates.
After successfully uploading the partner certificate, it is important to restart the partner-management-service
pod.
<<>
This document provides instructions on manually reprocessing all packets from the beginning after migration. The 1.2.0.1 release introduces multiple new stages and a new tagging mechanism. All packets that have not been processed before migration will be reprocessed to ensure they go through the new stages.
To facilitate packet reprocessing, MOSIP provides a Python script. This approach involves fetching all RIDs from the database using a query and processing them from the beginning. Please consult the documentation for instructions on setting up and running the reprocessing script. The query can be found in the config.py file.
Note: This script is highly customizable, and each country can modify it according to their specific requirements. This document outlines the general approach for reprocessing packets. If a country has special needs, the query will need to be adjusted accordingly.
The following command should be used to reprocess packets:
It is important to first reprocess just one packet after migration to ensure that all stages are functioning correctly. This can be accomplished by setting the limit to 1. Please refer to the explanation below for instructions on changing the limit.
APPROACH 1
DEFAULT QUERY
The default query reprocesses all packets that were not "PROCESSED" or "REJECTED" before migration. The query uses a limit of 1000 packets and a 1-second delay between each packet. This means that when the script is executed, it will reprocess 1000 packets one by one with a 1-second interval. These settings can be adjusted if necessary in the config.py file:
This query also selects packets that are one day old (latest_trn_dtimes < (SELECT NOW() - INTERVAL '1 DAY')). This ensures that the script does not reprocess the same packets repeatedly. The time frame should be adjusted according to the system downtime caused by migration.
A country can determine the number of packets to be reprocessed in each batch and set the limit accordingly. The script should be executed the necessary number of times. For example, if there are 10000 pending packets and the limit is set to 1000, the script should be run 10 times.
APPROACH 2
This approach is designed for countries where packets are not directly routed from the securezone. In cases where the country has disabled routing from the securezone by setting the below property to false, the securezone notification stage should be disregarded. This is because any packets that have not moved beyond the securezone will be taken care of by the automated reprocessor.
Property: securezone.routing.enabled=false
This approach is similar to APPROACH 1 with one key difference. It utilizes the latest_trn_type_code
in the query to specifically target packets that are stuck in these stages for reprocessing. It will disregard packets stuck in other stages.
Note: If any custom stage is introduced by the country, the latest_trn_type_code
should be added to the query.
Query:
Modular Open Source Identity Platform (MOSIP) integrates a suite of Mock Services designed to emulate key functionalities of MOSIP services within the framework. In the development, testing, and demonstration phases, Mock Services will make available a controlled environment to evaluate MOSIP features.
This document details each of the mock services and explains its significance within the MOSIP architecture.
Below are the current set of Mock Services available in MOSIP, the services are subject to modifications, as may be planned, in future releases. Please refer to the latest available version of the document.
Simulates device services for testing, authentication and delete registration functionalities.
Allows developers to interact with a device-service environment without a physical device.
Mock MV (Manual Verification)
Reproduces the manual verification process for testing and validation purposes.
Enables the testing of manual verification workflows without human intervention.
Simulates the functionality of the Automated Biometric Identification System (ABIS).
Facilitates testing of biometric matching, search, and integration with ABIS without accessing production data.
Maintains resident biometric uniqueness through de-duplication.
Interfaces with MOSIP via message queues in JSON format.
Supports 1:N de-duplication and adheres to ABIS API Specifications.
Replicates MOSIP's Biometric Software Development Kit (SDK) for testing and debugging purposes.
Allows developers to integrate biometric functionalities into applications without connecting to physical device.
Used for 1:N match, quality, extraction, etc.
Simulation is available as Mock BioSDK, installed in the MOSIP sandbox.
Exposes REST APIs for 1:1 match and quality check at the MOSIP backend.
The Registration Client Docker serves as a registration client zip downloader and upgrade server. The Nginx server within the Registration Client Docker container provides all necessary artifacts and resources during the upgrade process.
Patch updates:
When the registration client is launched, it downloads the manifest file from the upgrade server if the machine is online. Otherwise, it uses the local manifest file.
The client compares the checksum of each JAR file in the lib directory with the checksum stored in the manifest file. If there's a mismatch, the client considers the file invalid and deletes it before downloading it from the client upgrade server.
A checksum mismatch may be intentional for the rollout of hotfixes in the libraries used by the registration client or in the registration-client and registration-service module.
Patch updates do not support the upgrade of local Derby DB.
Assumption:
No major or minor version changes should occur for registration-client and registration-services modules.
Registration clients must be online to receive patch updates.
To roll out patches:
Rebuild the Registration Client Dockerfile and publish it with the same version.
Restart the registration client pod in Rancher.
For slow connections or connection failures:
If the client fails to download the manifest file when the machine is online, the registration client application will exit and report a build status check failure in the pre-loader screen.
If the latest manifest file is successfully downloaded but fails to download all the patches, the registration client application will exit and report a patch download failure.
In both cases, the operator/supervisor must restart the registration client application with a stable network connection. Upon restart, the client application will repeat the check from the server and continue the patch update.
Patch updates can include updates to existing libraries and the addition of new files. However, they are only applied to files in the
lib
directory.
Note: Deleting the registration-client.jar
or registration-services.jar
is not recoverable.
This procedure entails upgrading from one version of the software to the next iteration.
Additionally, this may involve upgrading local derby databases.
Upon each launch of the registration client, the client retrieves the maven-metadata.xml
file from the client upgrade server. The version specified in the local manifest file is then compared to the initial version element found in the maven-metadata.xml
.
Should the version values differ, the client recognizes it as an available upgrade to a new version.
Above is the sample content of maven-metadata.xml
.
The version upgrades are not performed automatically and must be initiated by the operator or supervisors. The process for the version upgrade can be outlined as follows:
Backup the database, libraries, binary, and manifest files and folders.
Download the latest JAR files and manifest files from the upgrade server to the local machine.
Prompt the operator/supervisor to restart the registration client with the upgraded JAR files.
Upon restart, the application executes the database upgrade scripts.
If the execution of the upgrade scripts is successful, the registration client starts and the version upgrade process is considered complete.
In the event of failure, rollback scripts for the database are executed and the registration client application exits. The operator/supervisor must rerun the registration client to initiate the execution of the upgrade database scripts.
Once the version upgrade process is successfully completed, the backup folder is removed and the registration client is fully functional for use.
From version 1.1.5.5 and above, the registration client now has the ability to upgrade directly from one version to another without going through the versions in between.
To enable this upgrade process, a new configuration has been introduced. This configuration is required for the upgrade to any higher version. The configuration key that needs to be set is mosip.registration.verion.upgrade.version-mappings
.
The version-mappings configuration specifies the list of released versions of the registration client, their respective release order, and the database scripts folder name.
For example, to upgrade from version 1.1.4 to version 1.1.5.5, the configuration should be specified as follows:
This configuration needs to be specified in the spring.properties
file of the registration-services.
During the registration client upgrade process, the application retrieves the above configuration and initiates the database upgrade based on the specified list of versions.
The upgrade progresses according to the releaseOrder
and executes the necessary database scripts based on the dbVersion
value.
How to roll out version upgrades?
In rancher,
Delete the existing version helm deployment of the registration client.
Deploy the new version of the registration client helm chart.
Example:
Let us assume that the registration-client version 1.1.5.5 is currently running, and we have to upgrade to version 1.2.0.1 version.
What happens after deploying the 1.2.0.1 version registration client in rancher?
Registration clients downloading the maven-metadata.xml
from the upgrade server will be aware of the new version availability.
content:
Based on the first version available in the maven-metadata.xml
, registration client will next download the MANIFEST.MF
.
After the successful download of the manifest file, the registration client will start the download of all the new files, updates the existing file if the hash is mismatched, and deletes the unused files from the lib directory.
After completing the download, operator/supervisor will be prompted to restart the registration client.
Next restart, will start the registration client as version 1.2.0.1 and starts the DB upgrade script execution if present based on the version-mappings configuration available.
The status of the DB script execution is printed on the preloader screen and also logged into registration.log
.
During the version upgrade process, we create backups of the manifest, db, lib, and bin folders in the designated backup directory. Once the upgrade is completed successfully, the backups are cleared. However, if the upgrade fails, we only roll back the changes made to the database.
In the event that the registration client application gets stuck during the upgrade due to errors or failures in the background, it is necessary for the operator or supervisor to manually roll back to the previous version of the registration client.
Below are the steps for manually rolling back:
Close the registration client application.
Delete the db
and .mosipkeys
folders in the reg-client working directory.
Navigate to the designated backup directory, where you will find a folder named after the previous version and the timestamp when it was created. For example, "1.1.4.4_2023-05-30 13-00-27.238Z".
Copy all the files and folders (lib, bin, MANIFEST.MF) from the backup to the registration client working directory, except for the .mosipkeys
folder.
Copy the .mosipkeys
folder from the backup to the home directory of the current user.
Launch the registration client application again.
Close the registration client application.
Delete the db
folder, if it exists, in the registration client working directory.
Navigate to the designated backup directory, where you will find a folder named after the previous version and the timestamp when it was created. For example, "1.1.5.5_2023-05-30 13-00-27.238Z".
Copy all the files and folders (lib, bin, MANIFEST.MF
) from the backup to the registration client working directory.
Launch the registration client application again.
By following these steps, the registration client application will be successfully rolled back to its previous version.
Below is the list of admin roles:
GLOBAL_ADMIN
ZONAL_ADMIN
REGISTRATION_ADMIN
MASTERDATA_ADMIN
KEY_MAKER
GLOBAL_ADMIN | ZONAL_ADMIN | REGISTRATION_ADMIN | MASTERDATA_ADMIN | KEY_MAKER |
---|---|---|---|---|
Here:
Green- colored represent persisted roles.
Blue- colored cells represent newly added roles.
Red- colored cells represent removed roles.
How to adjust the role accessibilities for existing users after upgrading to 1.2.0.1-x from 1.1.5.5-P1?
For a user having GLOBAL_ADMIN
role:
If a GLOBAL_ADMIN user is performing Certificate related operations then KEY_MAKER role need to be added to that user.
If a GLOBAL_ADMIN user is performing Packet Bulk Upload then REGISTRATION_ADMIN role need to be added to that user.
For a user having ZONAL_ADMIN
role:
If a ZONAL_ADMIN user is performing Certificate related operations then KEY_MAKER role need to be added to that user.
If a ZONAL_ADMIN user is performing Packet Bulk Upload then REGISTRATION_ADMIN role need to be added to that user.
For a user having REGISTRATION_ADMIN
role:
If a REGISTRATION_ADMIN user is performing Certificate related operations then KEY_MAKER role need to be added to that user.
For a user having MASTERDATA_ADMIN
role:
If a MASTERDATA_ADMIN user is performing GenerateCSR then KEY_MAKER role need to be added to that user.
If a MASTERDATA _ADMIN user is performing Packet Bulk Upload then REGISTRATION_ADMIN role need to be added to that user.
Note: A few new permissions were added to MASTERDATA_ADMIN and KEY_MAKER roles, please refer to the above role matrix table and if there is any inconsistency in the accessibility or roles of existing user, please reassign the roles to the user accordingly.
This document outlines the changes made to the camel route file following the migration.
In the 1.2.0.1 release, there is a default camel route file for each registration type, without any differentiation between the dmz and mz concepts. This is due to the transition from V2 to V3 deployment, which is mandatory.
Workflow commands are implemented to handle the isValid and internal error, with the primary purpose of making important decisions regarding the overall workflow state. Previously, these decisions were made within each individual stage, but now we are transferring them to the camel route, allowing for easier customization by different countries. This change grants more flexibility in controlling the workflow and reduces the reliance on specific stages for decision-making. It is mandatory for the registration table to be updated with packet processing results in each stage, whether successful or failed, excluding the status code. The example below demonstrates one of the workflow commands utilized in routes.
<to uri="workflow-cmd://complete-as-failed" />
Below are the workflow commands:
Commands | Usage |
---|---|
The OSI validator stage is divided into four stages: operator-validator stage, supervisor-validator stage, introducer-validator stage, and cmd-validator stage. If a packet is determined to be valid, it will be directed from the packet classifier to the cmd-validator stage. This step is mandatory.
Tags will be created in the packet classifier stage. Depending on the tags, the packet will be transferred from the command validator stage to either the supervisor or operator stage. In order to introduce validation and check tags, packets will be moved accordingly. The availability of tags allows us to modify camel routes. (Mandatory)
The quality checker stage has been updated to the quality classifier stage. Packets are now transferred from the supervisor, operator, and introducer stages to the quality classifier stage, depending on the designated route. This change is mandatory.
Instead of manual verification in section 1.1.5.5, it is now replaced with manual adjudication in section 1.2.0.1. Additionally, a new route has been specified from the manual adjudication stage to the UIN generator stage in the XML route. In cases where duplicates are identified, the manual adjudication stage is added to the route after the demo dedupe and bio dedupe processes. This change is mandatory.
New route has been added from UIN generator stage to biometric-extraction stage. This stage fetches biometric extraction policy from PMS and sends to ID Repository (mandatory).
New route has been added from biometric-extraction stage to Finalization stage. This stage publishes draft version to ID Repository DB (Mandatory).
New route has been added from Finalization stage to Printing stage. This stage creates Credential Request for printing systems (mandatory).
Based on Tags related to quality score, the packets will move form quality classifier to workflow-cmd://pause-and-request-additional-info
or demodedupe (optional).
We can use JSON path also and update the conditions. If we want to update route based on isValid
and internalError
then follow the below syntax (optional)
If we wish to use check condition based on address, then follow the below syntax (optional) ,
If we wish to use the check condition based on Tags, then follow as below (optional):
If we want to set the property in camel route, then follow the steps as below. .
This property is used for PAUSE and RESUME feature. We cant set application properties here (optional)
As a part of the 1.2.0.1 update, if no biometric data is available, the system will proceed to the verification stage. This stage is only relevant in cases where the required biometrics are missing from the packet. The system will send the applicant's demographic and biometric information to the external Verification System (VS) through a queue and Datashare. Upon receiving the decision from the VS, the system will proceed accordingly and forward the packets. In case of rejection, the applicant will be notified (optional).
New route is specified from verification to UIN generator stage route.xml
Now securezone-notification stage can consume from securezone-notification-bus-in address which is from packet receiver stage. We can even use, http://regproc-group2.regproc/registrationprocessor/v1/securezone/notification instead of http://mz.ingress:30080/registrationprocessor/v1/securezone/notification (optional)
1.1.5.5
1.2.0.1
~~~
In the registration processor, there was an issue where packets were failing at the supervisor validation stage when the username of the supervisor was entered in a different case than it appeared in the database. To resolve this issue, a case insensitive search will be implemented to retrieve the username of the supervisor during the validation stage.
In order for this fix to work properly, it is necessary for the user_id
column of the user_details
table in the master database to not contain any case insensitive duplicates.
If there are any duplicates in this table, packets will fail at the supervisor validation stage once again. Therefore, it is important to deactivate or delete these case insensitive duplicates. It should be noted that this action will not have any impact on other areas, as the mapping between keycloak users and the user_id
of the user_details
table is one-to-one and case insensitive.
user_id
column of the user_details
table?Follow these steps:
Log in to the master schema of the mosip_master
database.
Open a query tool.
Execute the following SQL command in the query tool:
Make sure to copy the output to a text file to manage the duplicate data effectively.
Login in to the admin portal with a user having ZONAL_ADMIN
role.
On the left pane, click on Resources
in the side-menu.
Select User Center Mapping
under Resources in the side-menu.
Click Filter on the User Center Mapping
page.
Enter the user_id
that was retrieved from the database and copied into the text file. After entering the user_id
, click on the Apply button.
Now, on the User Center Mapping
page, case insensitive duplicates of user_id
would be displayed.
Based on the Center, choose the entry that can be deactivated/deleted.
Now click on the ellipsis of the selected entry.
Select the appropriate action (Delete/ Deactivate) on that entry.
Location: mosip-config repository
Applicant-type MVEL script usages in MOSIP modules :
This MVEL script is used to determine the type of applicant based on the captured demographic data during the registration process.
→ Set of rules to determine the type of applicant is written as an MVEL script.
→ Applicant Data required for the evaluation passed as “identity” map to the MVEL context.
→ def getApplicantType()
method MUST be defined in the script. The string returned from this method should be a valid applicant type code or error code (KER-MSD-151, KER-MSD-147)
applicant_type_code
- Must be one of the values in the apptyp_code column in “master.applicant_valid_document" table.
"KER-MSD-147"
- returned when any of the demographics that are required for the script to return a code are empty (As per default script, it throws this exception if gender or residenceStatus or age is not filled / empty).
"KER-MSD-151"
- returned when the DOB exceeds the current date.
→ Data in the “identity” map are key-value pairs. The Key is the field id in the id-schema.
→ For the fields which are based on dynamic field values. For Ex: gender
“identity” map will have 2 mappings, genderCode, and gender. where the
identity.genderCode = “FLE”
identity.gender = “Female”
→ Age group configuration is also passed in the MVEL context as below
{ “ageGroups” : {'INFANT':'0-5','MINOR':'6-17','ADULT':'18-200'} }
and will be accessible as below in the script.
ageGroups.INFANT = “0-5”
ageGroups.MINOR = “6-17”
ageGroups.ADULT = “18-200”
Sample MVEL script is defined here https://github.com/mosip/mosip-config/blob/master/applicanttype.mvel
Note: In Pre-registration and Registration-Client, applicant-type
code is used to control the list of documents to be collected during the registration process.
The applicant_type_code
returned from this mvel script will be then used to fetch the required documents from master.applicant_valid_document
table.
For example, if the script returns applicant_type_code as “001”, all those entries in the applicant_valid_document table with app_typ_code as “001” will be picked and shown in the respective document dropdowns.
Attaching the sample csv file below which lists down the required entries for master.applicant_valid_document
table.
We can upload this default data from Admin Portal through Bulk Upload feature.
The steps to be followed are mentioned below:
Login to Admin Portal.
Navigate to Bulk Upload → Master Data.
Select the Insert operation, select the table name (ApplicantValidDocument
) from the dropdown and upload the csv file.
Click on Upload, which saves the uploaded data to the server DB.
Attaching screenshot for reference:
As part of the migration process, we will be updating the latest version of the identity-mapping.json
file (1.2.0.1) from the mosip-config
. This update involves modifying the mapping values to align with the id schema of the respective country.
To guide you through the updating process, please refer to the following information:
In the provided sample identity-mapping.json
, the focus will be solely on modifying the mapper values to match the id schema of the country.
According to the identity-mapping.json
file mentioned above, we need to verify if a value is present in the country's ID schema. If the value exists, we can retain it as is. Otherwise, we should update the value in the identity-mapping.json
file.
To illustrate, let's consider a few examples:
The fullName field is not included in the ID schema. Instead, it consists of firstName, middleName, and lastName. Therefore, we should replace the fullName with firstName, middleName, and lastName in the identity-mapping.json file.
Similarly, the introducerUIN field is not present in the schema, but instead, it has introducerCredentialID. Hence, we need to substitute introducerUIN with introducerCredentialID in the mapping.json file.
Additionally, since addressLine1 is not part of the schema, we should replace its value with presentAddressLine1, which is present.
Lastly, the phone field is not found in the schema, but mobileno is present. Thus, we need to replace phone with mobileno in the mapping.json file.
Our task is to compare each field value in the identity-mapping.json file with the ID schema and update it with the appropriate value based on the schema.
Centers
Centers
Packet Status
Devices
GenerateMasterKey
User Zone Mapping
Devices
Pause/ Resume RID
Machines
GenerateCSR
All Master Data
Machines
Retrieve Lost RID
All Master Data
GetCertificate
Masterdata Bulk Upload
User Zone Mapping
Packet Bulk Upload
Masterdata Bulk Upload
UploadCertificate
Packet Bulk Upload
User Center Mapping
UploadCertificate
GenerateCSR
UploadOtherDomainCertificate
GenerateCSR
All Master Data
Upload OtherDomainCertificate
Devices
GetCertificate
Masterdata Bulk Upload
Machines
UploadCertificate
GenerateCSR
Upload OtherDomainCertificate
UploadCertificate
Upload OtherDomainCertificate
Packet Bulk Upload
Module Name
Before LTS
LTS
Pre-registration
Yes
Yes
Registration Client
No
No
workflow-cmd://complete-as-processed
The status code will be updated to "PROCESSED" and a websub event will be sent to the notification service for notification purposes. Additionally, it will check if there is an additional request ID present. If so, a tag will be created with a specific registration type and flow status set as "PROCESSED". Furthermore, the latest transaction status code of the main flow will be updated to "REPROCESS" in order to resume processing. Lastly, notifications will be added for failed, rejected, processed, and pause-and-request-additional-info records within the workflow.
workflow-cmd://complete-as-rejected
The status code will be updated to "REJECTED" and a websub event will be sent to the notification service for notification. Additionally, it will verify if there are any additional request IDs present. If so, a tag will be created for the specific registration type with a flow status of "REJECTED", and the processing of the main flow will be resumed.
workflow-cmd://complete-as-failed
The status code will be updated to FAILED, and a websub event will be sent to the notification service for notifying relevant parties. Additionally, if there is an additional request ID present, a tag will be created with the corresponding registration type and flow status as FAILED. Following this, the processing of the main flow will resume.
workflow-cmd://mark-as-reprocess
It will update status code to REPROCESS. It will create tag with particular reg type with flow status as FAILED
workflow-cmd://anonymous-profile
To store packet details in anonymous profile table
workflow-cmd://pause-and-request-additional-info
It will verify if there is an additional request ID. If there is, it will update the status code to "FAILED" and the latest transaction status code of the main workflow to "REPROCESS" in order to resume processing of the main workflow. If there is no additional request ID, it will update the status code to "PAUSED_FOR_ADDITIONAL_INFO" and create the additional request ID. It will then send a web sub-event to the notification service to trigger a notification.
The Pre-Registration UI-spec file pre-registration-demographic.json
was previously included in the mosip-config repository in version 1.1.5.*, but starting from version 1.2.0, it should be manually published using the master data UI-spec API.
Go to Swagger clientIdSecretKey
to get the Authentication token:
Go to Swagger defineUISpec
to define the new UI Specifications
Go to publishUISpec
to Publish the newly defined UI Spec
Once done, check the master.ui_spec
table.
The Pre-registration UI Specifications document provides details about all UI spec attributes. This document can be referred to in order to identify the changes between versions 1.1.5 and 1.2.0.1.
The following new attributes have been added:
subType (optional - for dynamic dropdowns)
transliteration (mandatory to enable transliteration)
locationHierarchyLevel (mandatory to be added in each location dropdown to indicate the location hierarchy level)
parentLocCode (mandatory to be added in the topmost dropdown in the location hierarchy to indicate the parent for it. It can also be omitted, in which case the mosip.country.code property will be used)
gender
Attribute should be mandatory, and the parameter required
should be true
The control type for the date of birth should be changed to ageDate
The labelName should be provided with the "languageCode" as the "key" and the label as the "value". Example: {"labelName": { "eng": "Date Of Birth", "ara": "تاريخ الولادة", "fra": "Date de naissance" }}
visibleCondition (optional)
requiredCondition (optional)
alignmentGroup (optional)
containerStyle (optional)
headerStyle (optional)
changeAction (optional)