Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
This document outlines the necessary steps for upgrading the Platform from version 1.1.5.5-P1 to 1.2.0.1.
Postgres:
Check and remove the duplicate thumbprint entries in keymanager ca_cert_store. Refer the document to know more.
Refer the link for DB upgrade scripts to update the DB.
Change shareDomain in all the relevant policies to point to latest datashare
Change shareDomain's value from datashare-service to datashare.datashare in the policy_file_id column for each partner.
Check and rectify the partner name mismatch issue for certificate renewal. To know more, refer here.
Follow this link to check on the validity of the partner certificate and for renewal/ extension if required.
Check mvel expression, id schema and document mappings and add the required applicant document mappings. Click here to know more.
Keycloak:
Follow the steps mentioned here to execute upgrade keycloak init with import-init.yaml.
Verify all the existing users of admin and update the roles according to the latest role matrix. To know more about the existing users, refer here.
In Keycloak, it is important to ensure that the VID / UIN of each operator and supervisor is collected and updated in the individualId field. Failure to do so may cause complications during the onboarding or re-onboarding processes to new or existing machines, as well as during the biometrics update process for these users.
Manually update roles for client IDs that have been added as part of customization. For more information about the changes, please refer here.
Activemq:
Clear all the objects along with topics in the activemq or deploy a fresh instance of activemq with no previous data
ABIS:
Stop and clear all the inprogress items as it will be reprocessed freshly.
Review the queue names and update if required (mosip-to-abis and abis-to-mosip).
Manual adjudication system:
Stop and clear all the in-progress items as it will be reprocessed freshly.
Review the queue names and update if required (mosip-to-adjudication and adjudication-to-mosip).
Manual verification system:
Stop and clear all in-progress items as it will be reprocessed freshly.
Review the queue names and update if required (mosip-to-verification and verification-to-mosip).
Run the data movement to the necessary three tables using the provided script. Afterward, run the migration script to re-encrypt the data and perform the movement of data from the bucket to the folder (This step is only necessary if the pre-registration has been upgraded from version 1.1.3.x). Please consult the provided document for detailed instructions on how to carry out the data movement process.
Refer this document to run the property migration script.
Update registration-processor-default.properties reprocess elapse time to a larger time to avoid reprocessing before migration is fully complete (registration.processor.reprocess.elapse.time=315360000).
Add the below properties to syncdata-default.properties file if reg-client versions 1.1.5.4 and below are to be supported additionally.
Configuration property files required to be updated for language specific deployments. Please follow the below snippet.
Note: Ensure that the transliteration line is not commented out, even for a single language.
Take the latest version of the identity-mapping.json file (1.2.0.1) from mosip-config and update the mapping values based on the country's id schema. Please refer here for instructions on making the necessary updates.
Additionally, make adjustments to the mvel config file for the application type according to each country's specific requirements. For more details on how to modify the mvel config file, please refer here.
The camel routes need to be modified to accommodate the new workflow commands and ensure proper integration with external subsystems such as manual adjudication and manual verification. To understand the specific changes required, refer here.
Please ensure that the mosip.regproc.packet.classifier.tagging.agegroup.ranges property is aligned with the camel route.xml file.
To begin, set up the Configuration server.
Next, configure and setup the Artifactory.
Proceed with the installation in the specified sequence. Refer to the provided link for the correct order.
Execute the salt generation job to generate salts for the newly created table in the regproc.
Run the key generation job to ensure that all new module keys comply with the key_policy_def table.
Note: Disable the masterdata loader and regproc-reprocessor.
To resend the partner and policy details to IDA, please run the PMS utility job once. You can find the steps to run the job here.
The UI specs for pre-registration should be published via the MasterData API in version 1.2.0. Previously, in version 1.1.5, the UI specs were saved in the config server. To upgrade the UI specs, please refer here.
To proceed with the masterdata country specific upgrade scripts, please follow the instructions outlined here.
Please create all the required applicant type details according to the applicanttype.mvel file created in the property migration section. For more information, please refer to the document here.
Starting from version 1.2.0.1, it is mandatory to prepend the thumbprint for all encryptions. Therefore, we need to ensure that the certificate thumbprint for a particular partner exactly matches in both the keymanager and IDA key_alias tables. To learn how to check thumbprints and for further steps, please refer here.
Please check and rectify any mixed case user names in the user details and zone mapping. For more information, refer here.
Finally, restart all the services to take care of old data caching.
Configure the Registration Client upgrade at the server side. Please refer to this link for further instructions.
Run the query to identify all the packets stuck between the stages. Use the manual reprocess utility to reprocess all the RIDs found using the above query. Please refer to this link to carry out the reprocess.
Initiate the regproc reprocessor.
In case packets continue to fail due to performance issues, follow the steps mentioned in the document to process packets from the beginning.
Perform the ID Repository tasks. Run the archival script and reprocess SQL script on the credential transaction table as specified in the document.
Backup and delete any unnecessary tables and databases.
Manually remove the "mosip_regdevice" and "mosip_authdevice" databases, as they have been moved to "mosip_pms".
Delete all tables ending with "<table_name>_to_be_deleted" and "<table_name>_migr_bkp".
Ensure that the datashare property is properly configured in the abis policy for the domain. Please refer to this link for more detailed information.
Remove any unnecessary roles for clients and users.
When the admin portal becomes accessible, the admin user should generate the master keys that have been recently added to the key_policy_def table. This can be done using the admin UI master key generation page (Keymanager) for the ADMIN_SERVICES and RESIDENT roles. Only proceed with this step if the corresponding entries are not already available in the key_alias table of keymanager. For more detailed instructions, please consult the provided document.
During the pre-registration upgrade process, if the encryption key is REGISTRATION, which is an old key, it must be updated. To update the encryption key, please refer to the migration utility process by clicking here.
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.
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.
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:
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:
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)
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.
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 outlines the steps required for migrating the deployment architecture from V2 to V3.
This is required for migration from V2 to V3 architecture
Make sure to have all the pre-requisites ready as per the details present in the section pre-requisites
Setup Wireguard Bastion host
Setup wireguard client in your local and complete the configuration
Setup Observation K8 cluster
Configure Observation k8 cluster
Observation cluster’s nginx setup
Observation cluster applications setup
Observation cluster keycloak-rancher integration
Setup new MOSIP k8 cluster
MOSIP k8 cluster configuration
MOSIP cluster nginx setup
Setting up Monitoring for MOSIP cluster
Setting up Alerting for MOSIP cluster
Setting up Logging for MOSIP cluster
(Required for V2 to V3 architecture migration)
Setup postgres server
Note:
i. Deploy postgres server in a seperate node.
ii. Make sure postgres initialisation is not done (only install postgres).
Setup Keycloak server
Note: Make sure keycloak initialisation is not done (only install keycloak).
Setup Softhsm
Setup Minio server
Setup ClamAV
Setup ActiveMQ
Setup Message Gateway
Setup docker registry secrets if you are using private dockers.
Note: These instructions are only applicable if you need to access Private Docker Registries. You may disregard them if all of your Docker containers are downloaded from the public Docker Hub.
Setup Captcha for the required domains.
Setup Landing page for new MOSIP cluster.
This step is required for V2 to V3 architecture migration.
Softhsm (only required if softhsm is used instead of real HSM)
i. Backup keys
ii. Restore old key
iii. Update softhsm ida and softhsm kernel security pin
Kafka
i. setup external minio for backup.
ii. backup kafka
iii. restore kafka
Conf-secrets
Update the secrets in existing secrets in conf-secrets namspace.
Packets in landing to be copied from old environment to the upgraded environment or same NFS folder can be mounted to regproc packet server and group 1 stage groups. Refer here for more details.
dmz-sc.yaml
dmz-pkt-pv.yaml
dmz-pkt-pvc.yaml
dmz-landing-pv.yaml
dmz-landing-pvc.yaml
MOSIP has recently announced the release of its latest version, 1.2.0.1-B4. This new release brings about an architectural upgrade and addresses multiple bugs. To assist users in migrating from the MOSIP version 1.1.5.x to the latest version 1.2.0.1, a detailed Runbook has been provided, offering comprehensive guidance.
To set up the new environment and deploy the upgraded version of MOSIP, carefully follow the procedures outlined below step-by-step.
The migration will only be supported if the latest version deployed is 1.1.5.x (mostly 1.1.5.5-P1 and above). Countries should ensure that MOSIP is updated to version 1.1.5.x before migrating to the newer version.
Once the upgrade is completed, all the modules running on the server will be upgraded together.
The IDA Database will not have any entries from version 1.1.4.
Migration of websub event is not supported for countries transitioning from db-based websub to kafka-based websub.
After migration, if a new machine is added for the Registration Client, it must be installed with the latest version of the Registration Client. We will not provide support for the old version.
Partners who decrypt data encrypted by the key manager will support decryption with thumbprint support after upgrading to version 1.2.0.1. Therefore, backward support to encrypt without thumbprint is not available.
Prior to migration, countries should prioritize packets stuck in between stages using the registration processor and complete the processing.
Any third-party subsystems such as Manual adjudication/ABIS will not respond after migration for a request received before migration. Therefore, it is suggested that all subsystems, such as ABIS and manual adjudication, consume all the messages from ActiveMQ, complete the processing, mark all for reprocess, and respond back to registration processor before migration.
Default resource allocation (CPU and memory) has been added to all the pods in version 1.2.0.1, so additional nodes may be required after the upgrade.
The rollback process during the migration needs to be handled by the respective system integrators (SI).
All the server services and registration clients will be running version 1.1.5.x.
Registration packets available in MinIO and the landing zone can be version 1.1.4.x / 1.1.5.x.
Existing Grafana and Kibana reports from version 1.1.5 are not required to be viewable in the upgraded environment.
If there are additional attributes in the data share for manual adjudication, the manual adjudication system will ignore them and not fail.
The first global admin user login does not need to be handled during the upgrade.
Out of scope for migration:
Configuration of correction flow and related changes are not included in this migration.
Anonymous profiles for existing data are not handled in this upgrade.
Support for the Lost RID/AID search feature for packets synced before the migration is out of scope.
This comprehensive upgrade process entails the deployment architecture upgrade from V2 to V3, as well as the MOSIP platform upgrade from version 1.1.5.5-P1 to 1.2.0.1. The various tasks involved in this process are organized into the following categories.
Installation and configuration of new environment with V3 architecture.
Deployment of external services.
Backup and restoration of external services.
Upgrade of necessary external services.
Migration of properties.
Upgrade of MOSIP services.
Execution of activities once all upgraded services are operational.
Carrying out activities after completion of initial round of testing.
Let us go through the processes discussed above in detail.
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
libdirectory.
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.
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:
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 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-print 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_client. 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
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.
| 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) |
|---|---|
Module Name
Before LTS
LTS
Pre-registration
Yes
Yes
Registration Client
No
No
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
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
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.
