Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Release Name: Android Registration Client v0.9.0
Release version: 0.9.0
Support: Beta Release
Release Date: 26th February, 2024
The Android Registration Client is a tablet application designed to provide a mobile version of the existing desktop Registration Client. It has been developed to ensure accessibility on all Android devices and was created to meet the mobility needs of countries implementing MOSIP.
The main goal of the tablet application is to simplify the registration process for residents, particularly those who are unable to visit registration centers in person. It also aims to reach remote areas where establishing registration centers is difficult. The Android Registration Client allows Operators and Supervisors to efficiently reach these remote locations and increase resident registrations nationwide.
The new features included in this release, along with those from the Android Registration Client DP1 release, are:
Device Trust validation- This feature is introduced since the Android Registration Client will not accept biometrics from any non-trusted biometric application.
Transliteration- Ability to transliterate to another language upon entering the data
Combatibility with real SBI
Audit
Operator/Supervisor Login (offline and online)
a. Multilingual Support for display of labels (LTR)
b. Multilingual Support for Data Entry (LTR)
Auto sync / Manual sync
Enhanced new registration capabilities:
Streamlined New Registrations Consent
Demographic Details
Document Upload
Biometrics capture
Preview Section
Operator Authentication
Packet Synchronization
Packet Upload
Acknowledgment Section
Note: Compatible with MOSIP version 1.2.0
To access the build and read through the deployment instructions, refer to the Developer Guide.
For details related to Android Registration Client configurations, refer to the Configuration Guide.
To learn more about the available features, processes, and user interface, refer Android Registration User Guide for further information.
To view the list of known issues, refer here.
Repositories
Tags Released
android-registration-client
Handled the decryption failures occuring in ID Reposotory. In credential_transaction
, if decryption fails for request column, then unencrypted format should be retrieved. #MOSIP-23190
There is no dependency on Credential Request Status table. UIN table is connected with service to retrieve data related to UIN and its associated VID. #MOSIP-23189
Enabled logging query parameter for biosdk service. Logging process helps in tracking the extraction process carried out by biosdk services. #MOSIP-29421
During authentication, number of attempts to enter OTP was not restricted. This could result in many number of attempts. During this fix, number of attempts to enter OTP has been restricted. #MOSIP-31314
In credential service, when idvid API is called to retrieve demographic and biometric data, proof documents is also shared as response and thus affecting the performance time of the service. As a part of improving the performance, mosip.credential.service.fetch-identity.type
, property is included in the config file with the default value all. Through this parameter, the data shared by idvid API response is restricted. #MOSIP-29458
As a part of performance improvement, null value is not cached in uin_hash_salt
and uin_encrypt_salt
tables. #MOSIP-30221
During updating of packet processing, even if data was not updated in ID Repo, UIN was generated. After the fix, packet update is processing as expected and the modified data is correctly updated in ID Repository. #MOSIP-28436
Valid response was not sent for APIs, AuthInternalLock
and AuthInternalUnlock
. After the fix, upon provoking APIs, AuthInternalLock
and AuthInternalUnlock
, valid responses are sent. #MOSIP-28075
APIs were processing request with previously requested date instead of notifying such request as error. After the fix, APIs are behaving as expected for the past, present and future requested dates. #MOSIP-28074
Reprocess can now accommodate reprocessing the packets from desired stage. Based on the configuration, when a packet is marked as reprocess
, registration processor will re-process the packet instead of re-processing from the current stage. #MOSIP-29935
Included the name of the resident / recipient in all email notifications of Pre-Registration module. #MOSIP-30200
Upgraded the system and streamlined the credential issuance process to ensure smooth communication between the Credential Requestor Stage and the Credential Issuance module while adhering to specific policies for data sharing and notification updates. In this implementation, the printing stage is renamed to credential issuance stage. #MOSIP-28121
In Update UIN, data was not updated with the blank value for non mandatory field. After the fix, to update the non-mandatory field, user can provide a space so that data entered previously gets updated with null value. #MOSIP-29862
Unable to generate report based on the registration date as value,pkt_cr_dtimes
in the table, registration
is null. After the fix, enabled the system to update pkt_cr_dtimes
. User can now generate report based on the registration date. #MOSIP-29895
In certain scenarios, when the admin processes the second packet manually due to some failures in first packet and when the first also gets reprocessed, two UINs were generated for the same individual. After this fix, upon re-processing the packets, they are marked with specific status and one UIN is generated. #MOSIP-26697
Although kernel salt generator job status displays as completed, due to the exception occured during the job execution, related table displayed empty value. After the fix, user is notified if there is an exception occuring while the job is executed. #MOSIP-28212
Application displayed error while utilizing the DataShare Policy due to the naming convention of the partner. After the fix, the naming convention is modified to accommodate both uppercase and lower case characters. #MOSIP-28155
Mismatch in Kibana dashboard due to the infrastructure setup of Debezium connector. After the fix, the parameter, slot.drop.on.stop
is set to false. #MOSIP-27172
While processing the packet, in bio-deduplication stage, the new packet was compared against the failed lost packets which may cause the new packet to be rejected. With resolution, the status of the failed lost packets is updated to Rejected instead of Failed. #MOSIP-27069
Packet moves to manual verification before getting response from manual verification system, after some time re-processor picks up the same record and moves to UIN generator stage because latest transaction status code displayed as success. #MOSIP-27066
This issue occurred due to stage-group-3 and activemq connectivity. After the fix, added retry mechanism. #MOSIP-23025
Enabling VID can be shared as one of the printable credentials in the digital card service. #MOSIP-23420
User could not define Scanner device type. After the fix, upon including new configuration parameter, mosip.registration.imagingDeviceType
, user can configure scanner device type. #MOSIP-22171
Error occured due to invalid BIR images not sent during local de-duplication. After the fix, modified BIR structure to store operator biometrics in registration client. #MOSIP-25687
Application currently displays both MDS and SDK quality scores in the Biometrics screen in registration client UI. #MOSIP-26665
Even if Operator is de-activated in the system, Operator credentials were not disabled. After this fix, upon deletion or de-activation of operator credentials, the biometrics of operator is deleted in the system. #MOSIP-29676
When a module subscribes to websub, the hub secret was logged in plain text. After the fix, upon logging, hub secret is encrypted. #MOSIP-24522
When a module subscribes to websub, the hub secret was logged in plain text. After the fix, upon logging, hub secret is encrypted. #MOSIP-24522
Protocol is now included in the DataShare policy to be used while creating the DataShare URL. Default protocol is as http. #MOSIP-29662
Error occurred when user attempts to change the language in the single sign in. After this fix, user should be able to switch to other language in the single sign in. #MOSIP-23552
When MISP partner registers through Partner Management Portal, the partner is not required to be mapped a policy. After this fix, MISP partner will not be mapped to a policy. #MOSIP-23552
In module, Pre-Registration, when user attempts to register, for some cases, user has to mandatorily furnish exception proof documents. After this fix, user is not required to submit documents as mandatory. #MOSIP-24358
Once the registration client fetches the data of the application from pre-registration, the application status was updated to cancelled instead of pre fetched. After this fix, the application status is updated to pre fetched as expected. #MOSIP-24650
Version: 1.2.0.2
Name: Patch on Asymmetric Amoeba
Date: 05th April, 2024
Version: 1.2.0.1
Name: Patch on Asymmetric Amoeba
Date: 06th March, 2024
Version: 1.2.0.1 Beta 4
Name: Beta release on Asymmetric Amoeba
Date: 12th January, 2024
Version: 1.2.0.1 Beta 3
Name: Beta release on Asymmetric Amoeba
Date: 14th April, 2023
Version: 1.2.0.1 Beta 2
Name: Beta release on Asymmetric Amoeba
Date: 8th January, 2023
Version: 1.2.0.1 Beta 1
Name: Beta release on Asymmetric Amoeba
Date: 14th October, 2022
Version: 1.2.0
Name: Asymmetric Amoeba
Date: 14th February, 2022
Recommended Patch Version: 1.2.0.1 Beta 2
Refer to Older Releases.
The scope of testing is to verify fitment to the specification from the perspective of:
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the configurability and extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, the verification scope required comprehensive automation testing for all the MOSIP APIs. An automated Test Rig is created for the same.
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the test scenarios that resemble a real-time implementation.
A Persona is a fictional character / user profile created to represent a user type that might use a product/ or a service in a similar way. Persona-based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/ scenarios that the customers will execute. The persona's needs may be addressed through any of the following:
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
For regression check, "MOSIP Test Rig", an automation testing suite is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to the creation of the packet in the registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below:
Default configuration - with 3 Languages (English / Arabic / French)
Registration Client UI
Partner Management Portal UI
Below mentioned are the test metrics for functional testing using mock MDS, mock Auth, and mock ABIS. The process followed was black box testing which based it's test cases on the specifications of the software component under test.
Functional test was performed in combination with individual module testing and integration testing. Test data was prepared inline with the user stories. Expected results were monitored by examining the User Interface (UI). The coverage includes GUI testing, System testing, end-to-end flows across multiple languages, and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Here is the detailed breakdown:
The scope of testing is to verify fitment to the specification from the perspective of:
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the configurability and extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, the verification scope required comprehensive automation testing for all the MOSIP APIs. An automated Test Rig is created for the same.
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the test scenarios that resemble a real-time implementation.
A Persona is a fictional character / user profile created to represent a user type that might use a product/ or a service in a similar way. Persona-based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/ scenarios that the customers will execute. The persona's needs may be addressed through any of the following:
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
For regression check, "MOSIP Test Rig", an automation testing suite is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to the creation of the packet in the registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below:
Default configuration - with 3 Languages (English/Arabic/French)
Administration
Pre-Registration
Registration Client
Registration Processor
Partner Management Service
Resident
ID Repository
ID Authentication
Functional test results
Below are the test metrics by performing functional testing using mock MDS, mock Auth and mock ABIS. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared inline with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate: 100% with Pass rate: 93.19%
Here is the detailed breakdown of metrics:
Note: In API Based testing, 5 test cases are marked as skipped as they were not automated. In UI Based testing, 2 test cases are marked as skipped as they were enhancement test cases.
DSL - End to end scenarios results
End-to-End Scenarios
Detailed Test Metrics
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
API Test rig reports were generated by below sha id
for mosipqa/automationtests:1.2.0.1
image
sha256:48a30113bdf426630bd5f2275d3661dca92c4a26c4311c3e7232edeef04308a6
Module | Total | Passed | Failed | Skipped |
---|---|---|---|---|
Total | Passed | Failed | Skipped | |
---|---|---|---|---|
Total | Passed | Failed | Skipped |
---|
Module | Total | Passed | Failed | Skipped |
---|
Status | Test Cases |
---|
Github link for the xls file .
Repository Name | Branch Name | Coverage (>80%) | Reliability (0) | Security (0) | Hotspots (0) | Duplications (Less than 3%) |
---|
Registration Client UI automation
27
27
0
0
Partner Management Portal UI automation
18
18
0
0
End to end scenarios
163
123
38
2
2722 | 2537 | 178 | 7 |
API Based Testing | 2538 | 2373 | 160 | 5 |
UI Based testing | 184 | 167 | 15 | 2 |
Total | 163 |
Pass | 123 |
Fail | 36 |
Skipped | 4 |
partner-management-portal | release-1.2.0.1 | - | 42 | 0 | 0 | 11.7 |
partner-management-services | release-1.2.0.1 | 76.8 | 2 | 0 | 0 | 11.7 |
admin-ui | release-1.2.0.1 | - | 54 | 0 | 0 | 18.2 |
durian | release-1.2.0.1 | 85.2 | 5 | 0 | 0 | 0.0 % |
registration | release-1.2.0.1 | 80.9 | 2 | 0 | 1 | 4.6 |
packet-manager | release-1.2.0.1 | 0% | 7 | 0 | 0 | 1.2 |
id-repository | release-1.2.0.1 | 79.9 | 9 | 0 | 0 | 1.80% |
digital-card-service | release-1.2.0.1 | 0 | 4 | 0 | 0 | 1.4 |
pre-registration | release-1.2.0.1 | 81 | 48 | 0 | 0 | 1.9 |
pre-registration-ui | release-1.2.0.1 | - | 53 | 0 | 2 | 2.9 |
id-authentication | release-1.2.0.1 | 72.4 | 10 | 0 | 0 | 2.2 |
otp-manager | release-1.2.0.1 | 53.51 | 0 | 0 | 0 | 0.0 % |
resident-services | release-1.2.0.1 | 77.30% | 0 | 0 | 0 | 1.30% |
registration-client | release-1.2.0.1 | 73.7 | 21 | 0 | 5 | 7.5 |
Release Name: Android Registration Client DP1
Release version: vDP1
Support: Developer Preview Release1
Release Date: 7th Nov, 2023
The Android Registration Client is a tablet application that serves as a portable version of the existing desktop Registration Client. It has been developed to support accessibility on all Android devices. The existence of Android Registration Client came about in order to meet the mobility requirements of countries adopting MOSIP.
The primary objective of the tablet version is to facilitate the registration process for residents, specifically those who are unable to physically visit registration centres and also serve remote locations where setting up Registration centres is not feasible. To address this challenge, the Android Registration Client was created, enabling Operators/ Supervisors to easily reach the remote areas and maximise resident registrations across the country.
The key features provided on the Android Registration Client are:
Operator/Supervisor Login (offline and online)
Multi-language support
Auto-Sync/ manual sync
New Registrations
Note: The Android Registration Client is compatible with the following MOSIP platform versions:
1.1.5.x
LTS 1.2.0 and above
Dependencies:
mosipdev/kernel-syncdata-service:1.1.5.3
- This image contains temporary fix for encryption methodology for Android Registration Client. In the next release, there will be some decryption login changes and this will no longer be needed.
To access the build and read through the deployment instructions, refer to the Deployment Guide.
For details related to resident portal configurations, refer to the Configuration Guide.
To have a quick glance at the features, refer the video!
Release Name: 1.2.0.1 Beta3
Release Version: 1.2.0.1-B3
Support: Developer Release
Release Date: 14th April 2023
The 1.2.0.1 Beta3 release of MOSIP is a patch release on top of the Long-Term Support (LTS) release 1.2.0. This patch release mainly contains all the fixes for bugs, security and performance given as part of the 1.2.0.1-B1 patch and additional integrations modification for the Inji and e-Signet.
For complete documentation, refer to 1.2.0 LTS documentation.
To read though the Test Reports, refer here.
Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.
Developer documentation for all the repositories has been added for developers to set up in their local systems.
Release Name: Resident Services
Release version: vDP1
Support: Developer Preview Release1
Release Date: 12th Sept, 2023
This release marks the developer's preview release of Resident Services, offering valuable insights into the range of features and functionality available. Resident Services is designed to run on 1.2.0.1-B3 version of MOSIP platform. Resident Services are the self-services which are used by the residents themselves via a portal. Resident Portal is a web-based UI application that provides residents of a country the services related to their Unique Identification Number (UIN). The residents can perform various operations related to their UIN/ VID and can also raise concerns if any through the portal.
The key features provided on the Resident portal are:
Avail UIN services using UIN/VID (through e-Signet):
View My History
Manage My VID
Secure My ID
Track My Requests
Get Personalised Card
Share My Data
Logout
Get Information
About Registration Centers
List of supporting documents
Get My UIN (using UIN/ VID/ AID)
Verify email ID and/ or phone number
Responsive UI support- Support for the application to work seamlessly on various resolutions.
Book an appointment for new enrolment (via the pre-registration portal)
Ancillary features
Font size
Get Notifications (email and bell notifications)
View profile details of the logged in user (name, photo, and last login details)
For a quick overview of the design principles and to understand the relationship of Resident Services with other services, read Resident Services Overview.
For detailed description of Resident services, the code and design, refer to resident services repo.
MOSIP provides a reference implementation of the Resident portal that can be customized as per the country’s needs. The sample implementation is available here.
For getting started with the resident portal, refer to the Resident Portal User Guide.
To access the build and read through the deployment instructions, refer to the Resident Services Deployment Guide.
For details related to resident portal configurations, refer to the Configuration Guide.
For a detailed description of Resident Services, code, design, and setup steps, refer to:
Refer API Documentation.
For details on the test results, refer here.
The scope of testing is to verify fitment to the specification from the perspective of:
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the configurability and extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, the verification scope required comprehensive automation testing for all the MOSIP APIs. An automated Test Rig is created for the same.
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the test scenarios that resemble a real-time implementation.
A Persona is a fictional character/ user profile created to represent a user type that might use a product/ or a service in a similar way. Persona-based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/ scenarios that the customers will execute. The persona's needs may be addressed through any of the following:
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
For regression check, MOSIP Test Rig
, an automation testing suite is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to the creation of the packet in the registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below:
Default configuration- with 3 Lang
Virtual countries
1 Lang configuration
2 Lang configuration
3 Lang configuration
The below section provides details on API test metrics for all modules by executing MOSIP functional automation Framework. All external API test executions were performed at module-level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.
Test Rate: 100% with Pass Rate: 96%
Here is the detailed breakdown of metrics:
End-to-end flows are a set of stateful test cases that expects the results across multiple modules. The test does not cover the intermediary stages, rather concentrates on the end result for a given data. The test covers both negative scenarios and positive scenarios with real world scenarios. Below are the end-to-end scenarios test metrics by executing MOSIP Automation Framework.
Test Rate: 100% with Pass Rate: 75%
Below are the detailed test metrics by performing manual/ automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Release Name: 1.2.0.1 Beta 2
Release Version: 1.2.0.1-B2
Support: Developer Release
Release Date: 8-Jan 2023
Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.
Developer documentation for all repositories has also been added for developers to set up in their local systems.
The 1.2.0.1 Beta 2 release of MOSIP is a patch release on top of the . This patch release mainly contains all the fixes for bugs, security and performance given as part of the and additional integrations modification for the and .
For complete documentation, refer to .
Repositories
Tags Released
Branch
android-registration-client
Repositories
Tags Released
mosip-mock-services
biosdk-service
biosdk-client
bio-util
partner-management-services
id-authentication
esignet
esignet-mock-services
Inji
tuvali
mimoto
resident-services
mosip-file-server
mosip-helm
mosip-infra
postgres-init
k8s-infra
mosip-config
artifactory-ref-impl
mosip-data
mosip-onboarding
mosip-functional-tests
mosip-automation-tests
converters
Repositories
Tags Released
Resident Services
Resident UI
Total
Passed
Failed
Skipped
4565
4402
163
0
Module
Total
Passed
Failed
Skipped
Pre Registration
212
210
2
0
Mobile ID (Inji)
37
36
1
0
ID Repository
136
130
6
0
Resident
1020
958
62
0
Master Data
592
590
2
0
ID Authentication
358
336
22
0
Partner Management
463
462
1
0
e-Signet
563
558
5
0
Total
Passed
Failed
Skipped
84
63
21
0
Repositories | Tags Released |
mosip-openid-bridge |
keymanager |
id-authentication |
partner-management-services |
mosip-config |
artifactory-ref-impl |
mosip-data |
mosip-infra |
mosip-helm |
mosip-file-server |
mosip-onboarding |
mock-smtp |
keycloak |
postgres-init |
idp |
idp-ui |
oidc-demo-portal |
Verifying the LTS bug fixes and performing regression for the same.
Manual testing for bug validation.
DSL automation/ API test rig: Java, Selenium
Test report with results
Feature health report
Tested in environments supporting 2 languages: Eng, Ara
Features tested on V2 as well as V3 console
Below are the test metrics by performing functional tests:
Note: The number of failed test cases is cumulative of issues in released software as well the issues in the test automation scripts.
Release Name: 1.2.0.1 Beta1
Release Version: 1.2.0.1-B1
Support: Developer Release
Release Date: 14-Oct 2022
Bug fix: Filter search was not working for the user zone and center mapping page. This error was because keycloak expected two different values for first name and last name and none of it should be null. As a fix, changes were made in keycloak. #MOSIP-18973
Bug fix: In the admin UI, there was a restriction on the number of drop-downs as it was hardcoded and hence it wasn’t flexible. As a fix, the property-filterValueMaxCount:{"default":${mosip.kernel.filtervalue.max_columns},"registrationcenters":50,"locations":100} was added which has the ability to configure the number of items in drop-down. #MOSIP-19978
Bug fix: Audit logs were not listed for few transactions. After the fix, audit logs were getting listed in the DB. #MOSIP-19965
Bug_fix: In the admin portal, the cloning feature was not working. If a template had to be cloned from English to Arabic, on Arabic login, it displayed template not found error even though template was present. This issue has been fixed and cloning feature is now working. #MOSIP-19935
Bug fix: User zone and center mapping column sort was not working as expected. As a fix, sorting for logical column was removed. #MOSIP-19934
Bug fix: For bulk upload, the event Id in audit log was incorrectly being captured. After the fix, the audit logs displayed the expected event Id. #MOSIP-19841
Bug fix: In admin portal, when the center is inactive, the user should still be able to change the zone. After the fix, user was able to change the zone with an inactive center. #MOSIP-19817
Bug fix: In admin portal, for an active center, when a device was created in that center, on editing the device, it did not display the expected values (it was blank). After the fix, the device details are visible in edit mode. #MOSIP-19806
Bug fix: In Arabic language, on selecting the location on 1st level of hierarchy, the value in 3rd level of hierarchy was being populated. After the fix, the value of only 2nd level of hierarchy is populated on selecting the location on 1st level of hierarchy. #MOSIP-19699
Bug fix: In admin portal, when the status of a language dependent masterdata was changed or if it was decommissioned, in a particular language, it was expected to be reflecting in other languages as well. After the fix, it was reflecting in Arabic language as well. #MOSIP-19652
Bug fix: For language dependent masterdata, both the code and lang_code should have primary_key_constraint so that one is able to have same code in different languages. As a fix primary_key_constraint was added. #MOSIP-18682
Bug fix: Failure/Error messages are displayed with "!". In case of failures and errors, the exclamation symbol from the end of the text was removed to fix the issue.#MOSIP-18658
Bug fix: In the existing dynamic field, the "name" and "description" field were editable. After the bug fix, those were made to be non-editable. #MOSIP-18589
Bug fix: In the admin portal, when one adds values under an existing dynamic field, the description of that value should be pre-filled with the data in the existing dynamic field. After the fix, the description was auto-filled as expected. #MOSIP-18584
Feature upgrade: While creating dynamic field, initially, we used to input the data as dataType and now it is entered as text field. #MOSIP-16855
Bug fix: In admin portal, the pagination options were displayed in "English" language by default instead of the logged-in language. After the fix, pagination was displayed in the logged-in language.#MOSIP-16382
Bug fix: In admin module, \tags
were visible in the UI. After the fix, \tags
were removed from the UI. #MOSIP-19979
Bug fix: The audit logs were being logged in with incorrect event messages. As a fix, static audit logs were updated to fix the event messages. #MOSIP-19966
Bug fix: In admin module, packet upload was failing. As a fix, data-read role was assigned to the user. #MOSIP-19818
Bug fix: In Admin module, one was able to map Machine and Device to different Center ID which does not belong to that zone. As a fix, a validation was put in place to check if the center ID belongs to the given Zone or not. #MOSIP-19724
Bug fix: Crop and Delete option was not working in Scan document window. After the fix, it was possible to perform the crop and delete action. #MOSIP-19431
Bug fix: Capture Time not displaying in Supervisor/Operator Biometric screen in Registration Client. The “Capture Time” label is removed from UI. #MOSIP-18720
Bug fix: In Registration Client, ""/"" Symbol is displaying before all Registration tasks. Removed slash before the registration tasks to fix the issue. #MOSIP-18649"
Bug fix: UI should be refactored with RTL support when logged in Arabic language, after fixing the issue, able to see all the pages in RTL format when logged in Arabic. #MOSIP-18641
Bug fix: In Registration Client, the biometric correction label was overlapping with the consent screen. As a fix, wrap text was enabled on label. #MOSIP-18077
Bug fix: In PMP UI, the error message logo was missing. As a fix, error icon was added throughout the application. #MOSIP-19976
Bug fix: In FTM details menu button, the name was "create device" instead of "create FTM". As a fix, the name of the button of resource bundle was modified to create FTM instead of create device. #MOSIP-19918
Bug fix: In PMP UI, filter labels were not pointing to logged in language. As a fix, support was added to display label in multi language. #MOSIP-19639
Bug fix: In PMP UI, filter columns for partner menu was not proper. As a fix, the display label was modified. #MOSIP-19414
Bug fix: In PMP UI, user was allowed to create SBI details without mandatory details. After the fix, without mandatory details, SBI creation is not allowed. #MOSIP-17562
Bug fix: In FTM details page, the status should be approve/reject instead of active/de-active. After the fix, approve/reject labels were updated. #MOSIP-19823
Bug fix: In PMP UI, the partner could be mapped to the same policy twice. After the fix, one partner can only be mapped to one policy. #MOSIP-19773
Bugfix: In PMP UI, when a partner is registering themselves, the partner Id should be one single word with no space. After the fix, partner Id was not allowed to be created with space. #MOSIP-19404
Bug fix: In PMP UI, partial search was not working. After the fix, partial search was working with asterisk(*). #MOISIP-19347
Bug fix: In PMP UI, the partner admin should not be allowed to change the SBI details and FTM details after it was approved. After the fix, the SBI details and FTM details were made uneditable. #MOSIP-19309
Bug fix: In PMP UI, the expected error message when the SBI details are added to the pending status device details was "Device details are not yet updated" instead "Device details does not exist" was seen. As a fix, label was updated. #MOSIP-19306
Bug fix: In PMP UI, Search box was case sensitive in partner policy mapping. After the fix, the Search was made to be case insensitive. #MOSIP-19289
Bug fix: In PMP UI, if a partner tries to register using an email which already exists, instead of displaying "email already registered", it was showing a blank page. After the fix, it was correctly showing the message. #MOSIP-19277
Bug fix: Cancel application mails from pre-registration were not being sent and email templates were not being fetched from correct template type code. After the fix, the mail contents were fetched from respective templates and cancel mails were duly sent. #MOSIP-18192
Performance fix: Booking Slots were missing for many centers in cellbox2 env. As a fix, a code change was done in Batch Job to call master data API with sorting by "ID" instead of "createdDateTime". #MOSIP-19942
Security fix: The attacker could potentially see the files from the application or system. Using this, attackers can access other files as well. To mitigate the risk, the URL should not allow path manipulation. The "accept known good" input validation strategy was put in place. Also, a whitelist of acceptable inputs that strictly conforms to specifications was used. #MOSIP-14246
Bug fix: When a center was created without selecting lunch hours, at the center selection page it was showing lunch time as 12:00 AM to 12:00 AM. As a code fix, a condition "if lunchStartTime!= lunchEndTime" was put in place. #MOSIP-18985
Bug fix: PACKET_NOT_FOUND_EXCEPTION packet reprocessed after deleting from the landing zone. Cherry-pick was missed out from older branches(1.1.5), hence the Dev team updated changes in 1.2.0 and now it is working as expected. #MOSIP-19651
Bug fix: DMZ packet servers were not able to handle multiple landing zones. After the fix, DMZ packet servers were able to handle multiple landing zones. #MOSIP-19650Reporter
Bug fix: UIN generation notification email has $name_eng in template body. In the database, the name is not mentioned as per the ID schema, after making appropriate changes, the name is coming correctly in the email notification.G87 #MOSIP-11872
Bug fix: If a RID was inserted twice, referenceId already exists (in ABIS)
error was displayed and the packet was being sent for reprocessing. After the fix, the packet was not passed onto the reprocessing stage. #MOSIP-14191
Bug fix: Even when DEVICE_PROVIDER Id was hot listed, authentication was being performed successfully. As a fix, Client secret key in property mosip.mosip.hotlist.client.secret
was duly configured. #MOSIP-19829
Bug fix: Even with an invalid document Id, UIN was getting activated. As fix a, in ID schema, subType attributes was added. #MOSIP-19338
Bug fix: Authentication was successfully performed even with garbage value of application property of demo service as mosip.env
. As a fix, the only allowed values were restricted to IDA authentication property files. #MOSIP-19160
Bug fix: In the database, when e-KYC was performed, the entries were incorrect as OTP-AUTH, KYC-AUTH. After the fix, the entries are KYC, authentication type (E.g.: KYC-AUTH, OTP-AUTH). #MOSIP-18285
Bug fix: In the database, the column called cr_by
was not being updated and was left empty. This bug was fixed, cr_by
column has the correct value of who created that particular entry. #MOSIP-14291
Bug fix: Once the transaction configuration was changed to "2", the transaction limit in IDA DB did not change. After the code fix, the changes in config
properties were being reflected in the DB. #MOSIP-19736
Bug fix: Notifications were not being sent as per the preferred language. After the fix, notifications for send OTP were received in preferred language. NOTE- UINs generated from IDREPO. #MOSIP-19371
Bug fix: VID was not behaving correctly according to the config properties. Also, OTP was successfully being sent even with a revoked VID. After the fix, both the above issues were resolved and behavior of VID was based on config and also OTP could only be sent with a valid active VID. #MOSIP-19270
Bug fix: In the process of updating the demographic details of the resident from resident API, base exception
errors were displayed. After the code fix, we were able to update the demographic details successfully. #MOSIP-19525
Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.
Developer documentation for repos have also been added for developers to setup in their local systems.
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same. All MOSIP UIs are reference implementations and these were verified through UI automation Test rig for Registration Client and Admin UI.
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
For regression check, “MOSIP Test Rig” - an automation testing suite - which is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end to end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to creation of packet in registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below
Default configuration - with 3 Languages
Virtual countries
1 Language configuration
2 Language configuration
3 Language configuration
Below are the test metrics by performing functional testing using mockMDS and mockABIS. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared inline with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate : 100% with Pass Rate : 93%
Here is the detailed breakdown of metrics
Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Total number of external endpoints : 444 and total tested : 414
Test Rate : 93% with Pass Rate : 99%
Here is the detailed breakdown of metrics
End-To-End flows are a set of stateful test cases that expects the results across multiple modules. The test does not cover the intermediary stages, rather concentrates on the end result for a given data. The test covers both negative scenarios and positive scenarios with real world scenarios. Below are the End-To-End scenarios test metrics by executing MOSIP Automation Framework.
Test Rate : 98% with Pass Rate : 100%
Below are the test metrics by performing functional testing with Tech5 SDK, Syncbyte devices and combination of real and mockABIS based on the scenario being tested. The test cases cover the real device/SDK/ABIS integration points. The responses from the system are validated at the integration points and results are asserted at the end of the flow. The logical endpoint differs depending on the test scenario being executed. These are executed with the help of the MOSIP supported partners.
Test Rate : 86% with Pass Rate : 86%
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Case Coverage: It measures the percentage of passed test cases.(Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Repository-wise sonar report that covers the following:
Code coverage report
Critical Open Bugs
Security vulnerabilities
Security Hotspots
Release Name: Asymmetric Amoeba
Release Version: 1.2.0
Recommended Patch Version: 1.2.0.1 Beta
Release Date: 14th February 2022
Asymmetric Amoeba is a Long Term Support (LTS) release. This release focuses on easy manageability, usability, enhanced performance, robustness, security, inclusivity (supports 2+ languages with no restrictions), and comprehensive documentation.
Major areas of work
Robustness
Partner Management Portal
Administration Portal
Functional bug fixes
Performance fixes
Security fixes
Reporting
Documentation
Repositories Released
Pre-registration
Administration
Partner Management
Test Repositories
List of documents
Total | Passed | Failed | Skipped |
---|---|---|---|
Module | Total | Passed | Failed | Skipped |
---|---|---|---|---|
Module | Total | Passed | Failed | Skipped |
---|---|---|---|---|
The 1.2.0.1 Beta release of MOSIP is the first patch release on top of the Long-Term Support (LTS) release 1.2.0. This patch release mainly contains the fixes for bugs, security and performance. This release also contains minor feature enhancements. One of the major highlights of this patch release is the . Support for legacy V2 deployment is deprecated. The recommended deployment method will be V3 deployment architecture.
To view the list of known issues, click .
Note: The 1.2.0.1-B1 version of Registration Client will not support the latest mock MDS (1.2.1-SNAPSHOT). All the biometrics will be captured fine but exception photo capture fails. To know more, refer .
For complete documentation, refer to .
You can find all our test cases executed in MOSIP .
Repository | Sonar Coverage | Sonar Vulnerabilities | Sonar Bugs | Sonar Hotspots |
---|
As a part of manageability, a fully supported and with the ability to self-register partners is included. To help with the operational needs, a fully-working reference module is included that can be used by the adopters to track and monitor the analytics around MOSIP.
690
632
50
8
Pre-Reg
70
63
6
1
Reg Client
107
99
8
0
Reg proc
143
138
5
0
Resident
85
77
8
0
Admin
114
90
17
7
IDA
122
117
5
0
PMS
49
48
1
0
Pre-Reg
212
205
7
0
Resident
306
279
27
0
Admin
903
897
6
0
IDA
358
354
4
0
PMS
457
456
1
0
SchemaName.Table | Column name | Changes done | Description |
master.loc_holiday |
| removed from composite primary key | This column doesn’t fit well in the primary key as it allows duplicate holidays on same day which is not expected. |
master.loc_holiday |
| added to composite primary key | Adding this constraint restricts the user from creating multiple holidays on the same day. |
master.blocklisted_words |
| removed | Since the “word” column is enough to identify the word uniquely, there is no need for |
pms.ftp_chip_detail |
| added | This column is added to track certificate upload and admin approval. |
regprc.registration_list |
| added | This attribute is needed for packet encryption/decryption. |
prereg.processed_prereg_list |
| dropped the Foreign Key constraint | The table to which the Foreign key was referring to did not exist. |
Total | Passed | Failed | Skipped |
4283 | 4024 | 259 | 0 |
Module | Total | Passed | Failed | Skipped |
Pre Registration | 645 | 632 | 13 | 0 |
Registration Client | 680 | 649 | 31 | 0 |
Registration Processor | 542 | 494 | 48 | 0 |
Resident | 230 | 194 | 36 | 0 |
Admin | 796 | 711 | 85 | 0 |
ID Authentication | 940 | 910 | 30 | 0 |
Partner Management | 450 | 434 | 16 | 0 |
Total | Passed | Failed | Skipped |
1753 | 1745 | 8 | 0 |
Module | End Points | Automated | Test cases | Passed | Failed |
Pre Registration | 47 | 36 | 199 | 196 | 3 |
ID Repository | 21 | 20 | 109 | 108 | 1 |
Master Data | 269 | 257 | 896 | 896 | 0 |
Resident | 17 | 16 | 111 | 107 | 4 |
ID Authentication | 8 | 8 | 142 | 142 | 0 |
Partner Management | 82 | 77 | 296 | 296 | 0 |
Total | Passed | Failed | Skipped |
54 | 53 | 0 | 1 |
Total | Passed | Failed | Skipped |
475 | 356 | 55 | 64 |
commons | 83.4 | 0 | 0 | 11 |
mosip-openid-bridge | 81.7 | 8 | 4 | 1 |
audit-manager | 100 | 0 | 0 | 0 |
keymanager | 22.9 | 0 | 2 | 0 |
khazana | 2.1 | 0 | 6 | 0 |
packet-manager | 0 | 0 | 7 | 0 |
admin-services | 81 | 5 | 0 | 2 |
id-repository | 81.8 | 0 | 11 | 3 |
pre-registration | 81 | 0 | 49 | 0 |
id-authentication | 82.8 | 0 | 0 | 0 |
registration | 82.5 | 2 | 15 | 2 |
resident-services | 73.3 | 0 | 23 | 3 |
admin-ui | 0 | 0 | 61 | 0 |
registration-client | 73.5 | 0 | 23 | 3 |
partner-management-services | 81 | 0 | 0 | 0 |
2.4 | 0 | 8 | 0 |
durian | 84.8 | 0 | 5 | 2 |
pre-registration-ui | 0 | 0 | 102 | 6 |
The reference ID object validator now supports the validation of dynamic field data.
The WebSub has been upgraded
to support multiple ballerina servers.
to have authentication and authorization for all subscribers and publishers.
it also has a health check feature now.
JCE (Java Cryptography Extension) integration in Key Manager Service has been added.
The open ID authentication adaptor has been created to integrate with any open-ID compliant IAM solution.
Using the Admin portal, the administrator can now enter master data in multiple languages (more than two). Earlier, we had a restriction to run only with two languages.
For Fetch APIs of some of the non-sensitive master data, authentication has been disabled and caching has been enabled. The master data APIs that are changed: applicant type, blocklisted words, document categories, document types, dynamic fields, exception holidays, gender types, id types, individual types, languages, locations, location hierarchy levels, templates, template type codes, title, valid documents, weekdays, working days, and zones.
Using the admin portal, the administrator can
map or unmap a user in Keycloak with a center and zone.
view the packets that were paused by the registration processor and resume them for further processing.
add or remove dynamic field data.
retrieve an individual's lost RID or misplaced RID.
control the levels of location hierarchy they require while creating the registration centers. The level of the hierarchy can be configured through configuration property value.
map the users to a registration center and to a zone.
create and update dynamic fields such as Gender, Blood Type, Residence Status, Marital Status etc.
configure the number of kiosks in a particular registration center during the process of creating the registration center.
The UI specification and ID schema are now stored separately in different database tables as well new API has been created to store the UI spec for pre-registration and registration client
UI spec version and ID schema version are independent.
If any new version of UI spec is published, then it will not affect the ID schema version.
If any new version of ID schema is published, the corresponding version of UI spec needs to be republished or updated.
APIs for adding partner ID, individual ID (UIN and VID), and device (serial number, make or model) in the hotlist has been added.
Using the pre-registration, the resident can provide demographic data in multiple languages (more than two). Earlier there was a restriction for only two languages.
In the UI specifications,
“alignmentGroup” property has been added to align multiple UI components horizontally.
“changeAction” property has been added to handle custom change actions between two or more UI components.
“containerStyle” and “headerStyle” properties have been added to override the default CSS.
“transliteration“ property has been added to enable or disable transliteration of an attribute.
Language-specific validators have been added.
Support from a date picker and number spinner has been added for date and ageDate control types.
The document upload screen is now rendered from UI spec.
The captcha service has been enhanced and is available now.
The application now gets locked once the appointment is booked. Post booking, the application details cannot be modified, but the booking can be cancelled or rescheduled.
The notification template now supports having parameters like centre name and center address.
One single bucket is being created to store all the documents of the resident.
During application creation, consent is collected from the resident and stored as a JSON object in the audit table.
Pre-registration packets shared during data sync are now being encrypted with the machine-specific TPM public key.
Pre-registration packets can be synced to the registration client even if the booking is not performed.
Created an error handling framework to handle technical errors thrown from service in the UI.
Added support for displaying custom validation messages in UI components. For example, instead of just displaying 'Invalid email' or 'Invalid phone', it can be made more specific like 'Invalid email format' or 'Phone number cannot exceed 10 digits'.
The Send OTP button on the login page will be disabled till the OTP expiry time elapses.
A pre-registration application will be locked and no further modifications will be allowed on it once an appointment is booked for the same.
Registration Client will be able to perform an on-demand fetch for pre-registration application irrespective of its booking status.
Encryption of pre-registration data during data sync with Registration Client.
The structure of how the documents were stored in MinIO has been changed. Now we will have a single bucket with different folders for each PRID.
The resident's consent is captured as part of the audit table.
Using the Registration Client, the operator can collect demographic data of residents in multiple languages (more than two). Earlier there was a restriction for only two languages.
Using the UI specifications, the order of the screens and in which screen what data needs to be captured can be controlled.
In the UI spec,
the sub-type can be set to RID, UIN or VID to perform validation for RID, UIN and VID using the in-build validator libraries.
regex validation for different languages can be added.
support for multiple age groups has been added.
During operator onboarding, the operator’s VID should be stored in Keycloak instead of RID for authentication.
A control panel has been added in the registration client for biometric devices, non-biometric devices, configurable settings, registration client jobs have been added.
If multiple devices are connected, we can set a particular device as the default.
For some of the local configurations, they can be modified by the operator using the Settings page.
All of the job schedules can be locally modified and the jobs can also be triggered individually.
All operations on the registration client are now performed based on the local time zone.
Any anti-virus or transliteration implementation can be plugged in during the registration client packaging.
The GPS and scanner implementation is moved to separate libraries so that countries can customize these implementations.
The CSS and icon bundles are now moved to the artifactory.
In the CBEFF, now the below flags are being stored under the others section,
RETRIES, for number retries for biometric capture
FORCE_CAPTURED, to identify if forced capture was done
SDK_SCORE, to store the score of the biometric SDK
EXCEPTION, to mark the biometric type as an exception, here BDB will be empty.
CONFIGURED, to store the list of configured attributes in the outer BIR (as per the ID schema)
The link for change and forgot password can be configured, so that, from the UI, the user can be redirected to the corresponding IAM page to perform these operations.
Packets can be auto-uploaded to the server based on a configuration.
There is a regular expression validation in place for multiple languages (earlier the system was able to validate data only for English).
We now have a configurable antivirus that is being used during registration client packaging. This virus scanner will be able to run based on the configuration frequency in the background.
There is a Settings page in Registration Client which can be treated as a control panel window page that manages various kinds of settings such as:
Device selection settings
Sync Settings
Global configuration settings
The registration client is now capable of handling multiple time zones, including the local time zone and the UTC.
The RC is now capable of having multiple themes based on the country's choice. This is possible because now there is separate CSS and icons based on the configuration.
In the RC, the ID schema and UI specs are created and stored separately for each flow (like new registration, UIN update, lost ID) which makes sure that in future if any other flow needs to be added, it can be added with zero code change.
The RC now has the dynamic layouts and dynamic screens as a single screen that supports all Demographic/Documents/Biometrics captured which essentially means that the order of occurrence of the screen is now configurable.
When the password of an operator/supervisor is changed in Keycloak, the operator will be automatically be logged out if he/she is already logged in (in online mode) using the old password. In offline mode, the old password can still be used for creating packets, unless the client application has not synced with the server.
The RC works with both SBI v1.0 and MDS v0.9.5.
Notifications to users are being sent based on the user preferred language set during registration.
The OSI validator stage has been removed and segregated into multiple stages, i.e,
CMD validator stage for verifying centre, machine and device details.
Operator validator stage to validate the operator details.
Supervisor validator stage to validate the supervisor details.
Introducer validator stage to validate the introducer details.
Based on tagging of packets in the packet classifier stage, rules have been added in the workflow configuration for different age groups (Infant, minor and adult). For example, introducer validation is made mandatory for Infants and minors based on camel workflow.
In the quality check stage, the packets having poor quality scores are not being rejected, instead, these packets are tagged for having poor, average or good quality biometrics based on configured thresholds. The final decision to process these packets can be made by the camel workflow.
The external integration stage has been moved to reference implementation and is removed from default camel routes and registration processor deployment.
Once the packet is uploaded to MinIO, the registration processor notifies the registration client so that it can delete the packet.
Trust validation of devices has been added to the registration processor.
The mandatory check, master data validation and biometric check have been removed as these checks are done by the id object validator.
The stages do not make the final decision instead the final decision is made by the workflow and these are the workflow actions set by the stages,
MARK_AS_PAUSED, when the stage requests the workflow to pause the packet processing
COMPLETE_AS_PROCESSED, when the packet is verified and UIN is issued or user data is updated.
COMPLETE_AS_REJECTED, when a duplicate is found or rejected by a manual adjudicator or supervisor.
COMPLETE_AS_FAILED, when a packet fails to process and is not marked for reprocessing
MARK_AS_REPROCESS, when a packet is marked for reprocessing.
Based on the above workflow action set by a stage or tags configured a packet can now be paused during processing and it can be resumed by the administrator. A default time elapse has also been added to auto-resume the packet processing.
The verticles are grouped together to optimize the CPU usage and are executed as a single-stage using the stage executor. The various stage groups and associated verticles are,
Stage group 1: packet receiver stage
Stage group 2: quality classifier, secure zone notification, and message sender stage
Stage group 3: ABIS handler, ABIS middleware, bio deduplication, and manual verification stage
Stage group 4: biometric authentication, and demo deduplication stage
Stage group 5: cmd validator, operator validator, supervisor validator, introducer validator, and packet validator stage
Stage group 6: packet uploader, and packet classifier stage
Stage group 7: uin generator, and printing stage
XSD and biometric signature validations have been added in the packet validator stage.
The internal data share URL for registration processor integration components (i.e. ABIS and manual adjudication system) can be configured from registration processor configurations. The data share for credential issuance can now be different from the data share for the registration processor.
The pause and resume feature was decoupled from hotlisting feature and modified to support any configured tag.
Tagging feature has been enhanced to support more tags on a packet.
Certificate thumbprint will be shared as a part of authentication requests for all internal authentications from the registration processor.
The registration officer/supervisors userId can now be mapped to VID/UIN in Keycloak
An API has been added to the registration processor to find the resident’s lost RID.
Readiness and liveliness probes have been created as part of registration processor service discovery and load-balancing features
A new flow has been added to the registration processor to support and initiate correction. As a reference implementation, we have added a biometric correction flow.
Virus scanner was made as a runtime dependency in the registration processor.
APIs for creating, updating, retrieving and publishing drafts have been added.
A job to re-seed all the credentials for a new ID Authentication instance or change in Datashare policy has been added.
IDA is able to re-trigger the issuance of the credential for the missing active UIN or VID in IDA during startup.
IDA is able to pull the failed web-sub messages and process them during startup.
IDA is able to send notifications to residents based on the preferred language set by the resident during registration.
The dependency for sending only primary and secondary language-based e-KYC responses have been removed. Now in e-KYC, the relying party needs to specify the language codes in the partner policy.
Different configuration properties files have been created for IDA internal authentication, external authentication, e-KYC, OTP services for the web sub callback URL.
Validation of the domain and environment values have been added. These are validated against a list of values added in the configuration.
All validations apart from length and checksum have been removed for UIN and VID in IDA APIs.
The certificate data from partner management is now retrieved via the data share URL.
A new internal authentication API has been built with a different endpoint. This API doesn’t support, encryption, HMAC and biometric hash validation. It only performs signature validation of the header.
IDA now has MOSIP authentication filter interfaces in place which has the capability of controlling the authentication type that will be applicable to the resident on a case basis(since an infant biometric is not captured, the system will only allow demographic authentication for infants).
The hotlist validation can be enabled or disabled for various attributes like partner ID, individual ID (UIN and VID), and device (serial number, make or model) using configurations.
All the master data, partner details and policy information is now being synced to IDA via. web-sub. IDA consumes this information from its database after the sync, hence it is now independent of all MOSIP modules.
The demographic authentication with normalization is now externalized via an API. The implementation for the same is done in a separate library (which is part of our reference implementation) and can be configured easily in IDA.
IDA is publishing events for any fraud management system for,
Validation failures
Authentication failures
Multiple OTP or authentication requests
IDA is now capable of pulling the missing data (data that has been lost since the maximum retry limit has been exceeded once the IDA comes up after being down) such as credentials from the web sub-message store for all the records with the failed delivery status. For other data, such as partner data and master data, pulling of missing data will be done by Kafka.
All the credential requests of UINs/VIDs that are updated/deactivated/revoked/blocked will be invalidated by the system.
IDA database will now store the partner details which include data like partner ID, policy ID, MISP ID and API keys to authenticate the above entities directly from IDA.
IDA can now validate whether the UIN, devices, partners or VIDs are hot listed or not when trying to perform an authentication.
The CBEFF utility has been deprecated and the new implementation has been added.
IDA can now authenticate identity details of the individual corresponding to the UIN in the request with dynamic demographic JSON and ID Schema hence the need to map ID attributes will not be required.
IDA will now send notifications to the residents in the case of events like authentication failed/successful, authentication type lock/unlocked notification is sent to resident service and credential details stored successfully/failed notification is sent to the credential request service.
Every time there is any changes made to the template or title in master data, it will be notified to IDA using web-sub hence updating the cache in IDA.
IDA will now verify the device details when the biometric authentication request is received. It will validate the trust of the device provider & FTM partner, the timestamp in the digital ID, and the status of the device (whether it is active, de-active or hot listed).
The system (IDA/ID repo) will have the ability to set an expiry date on a resident's identity record. This expiry date will control if the resident can perform authentication or not.
An ID issuer will now be able to store the anonymous profile information of a resident in the ID repository. This data will be stored in JSON format. No PII resident data will be stored as a part of this.
The unlock authentication type API has been modified to support auto-lock after x seconds. When the time has passed the authentication type will be auto-locked after the time elapses.
Resident services will now support multiple languages. There will be a list of mandatory languages as well as a list of optional languages for the resident to choose from.
The notifications are being sent to the residents based on the preferred language set during registration.
In this release partner management portal is available. This portal can be used by partner admin, policy admin and various MOSIP partners like authentication partners, device providers, FTM providers, and credential partners.
The partner portal has the below features
Self-registration of partners
Partner specific certificate upload
Partner can add device models, FTM models, policy mapping, SBI details
Partner and policy admins can approve/reject partner requests, create policies and can add MOSIP compliant CA (certificate authorities)
Repositories | Tags Released |
commons |
mosip-openid-bridge |
audit-manager |
keymanager |
khazana |
packet-manager |
admin-services |
id-repository |
pre-registration |
id-authentication |
registration |
resident-services |
admin-ui |
registration-client |
partner-management-services |
mosip-config |
websub |
durian |
partner-management-portal |
mosip-ref-impl |
artifactory-ref-impl |
reporting |
mosip-functional-tests |
mosip-data |
mosip-automation-tests |
keycloak |
biosdk-services |
biosdk-client |
mosip-infra |
mosip-helm |
mosip-file-server |
postgres-init |
mimoto |
SonarCloud is used as a tool for deep code analysis, to explore all source files, whether in branches or pull requests, to reach a green Quality Gate and promote the build.
SonarCloud URL: https://sonarcloud.io/organizations/mosip/projects
Git Branch: 1.2.0-rc2
Code coverage: to be maintained greater than or equal to 80%
Bugs: There should be no critical bugs open
Security Vulnerability: 0
Security Hotspot: 0
Code Duplications to be maintained below 3%
Target : Code coverage to be maintained greater than or equal to 80%
Target: There should be no critical bugs open
Target: There should be no security vulnerabilities and hotspots
Target: Code duplications should be less than 3%
This report contains all the security bugs that were identified in various MOSIP modules. This is a combination of both web application and API related security testing scenarios.
This report is prepared based on the security testing performed on the 1.2.0 version of MOSIP.
For testing the modules we have used state of the art security testing tools such as Burpsuite Professional, owasp ZED attack proxy, wireguard and other Linux tools.
In MOSIP we have three modules that have web-based UI interfaces. These modules are Preregistration, Administration and Partner-management-Portal. All three have been tested thoroughly.
All other modules in MOSIP do not have any web-based interface and these modules communicate with each other using APIs. The details of the APIs in MOSIP 1.2.0 are available here.
Web Security Vulnerability Snapshot
Release Version: 1.2.0.2
Release Date: 5th April 2024
The 1.2.0.2 release addresses critical bugs that were reported, enhancing the stability and usability of the software to ensure a seamless customer experience. Below, you'll find a detailed description of the fixes included in this version:
Major Areas of Work
Registration Client
Partner Management Portal
The scope of testing encompasses the verification of adherence to specifications in terms of:
Functionality
Deployability
Configurability
Customizability
Verification is conducted not only from the perspective of end users, but also taking into consideration the needs of System Integrators (SI). This includes assessing the Configurability and Extensibility of the software to ensure its suitability for use in various countries.
The testing focus of Android Registration Client includes the following processes:
Logging into ARC
Adding machine details
Consent page verification
Demographic data input
Document upload assessment
Biometric data verification
Preview screen evaluation
Authentication screen testing
Acknowledgement screen review
Multi-language support analysis
Syncing/ uploading/ Auto-uploading packets testing.
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on various configurations as mentioned below:
Default configuration - with 2 Languages (Eng, Fra)
Below are the test metrics by performing functional testing using mockSBI and mockABIS. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate: 89% with Pass Rate: 59%
Hash Tag: 19ae6cff54715a2a82011134c6678424620217fa
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Severity | Count |
---|---|
Current Status | Severity | Risk |
---|---|---|
Current Status | Severity | Risk |
---|---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Session was not getting invalidated after logout |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attacker can bypass authentication using SQL injection or LDAP injection. Sometimes due to insufficient data sanitation and testing, attackers can break in. This has a very high security risk. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can monitor the request and response and change the request parameters. If an attacker uses certain proxy tools, he/she will be able to monitor the requests and responses of certain users in the network. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can overload the system by sending thousands of requests |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can try a dictionary attack or a brute force method to get the userId and password. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can put XSS scripts that will be executed on victims browser |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can try to upload malicious files |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try Null Byte upload or try to change the file extension. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can try to attempt to upload oversized files to cause buffer overload. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attackers can try different methods to expose the used server name and version. It is otherwise known as banner grabbing. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try path traversal/Directory Traversal attacks. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try CSRF attacks |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try CORS attacks |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try header manipulation attacks |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker with access to admin UI can try to upload incorrect certificates. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try request smuggling attacks. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try XXE injection attacks |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try to spoof /change biometric data or confidential data |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can try double host header attacks |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Attackers can try to use other user’s PRID to get their PII data(IDOR) |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | An attacker can try privilege escalation attacks. |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Absence of x-content –type header |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Weak ciphers can be decrypted and used for data stealing |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | Without a CSP(content security Policy) a program is never very secure |
---|---|
Current Status | Severity | Risk |
---|---|---|
Description | The pre-registration zip file might cause buffer overload |
---|---|
Issue with Policy Creation: Previously, while attempting to create an Authorization or DataShare policy, the application encountered difficulties in successfully establishing the policy. Issue is resolved now and users can effortlessly define their Authorization or DataShare policies after creating and activating policy groups.
Login Failure in Registration Client: Previously, users were unable to log into Registeration Client as 'Submit' button did not work as expected. Issue is resolved now, users can now successfully log into Registration Client.
Repositories | Tags Released |
---|
Github link for the xls file .
Legend | Status | Description |
---|
Feature | Status |
---|
Feature | Status |
---|
Feature | Status |
---|
Feature | Status |
---|
Feature | Status |
---|
Feature | Status |
---|
Feature | Status |
---|
Module Name
Code Coverage
Commons
84.10%
Admin
80.00%
Pre Registration
80.40%
Registration client
65.80%
Registration Processor
80.00%
ID Authentication
80.80%
ID Repository
62%
Resident Services
64.70%
Partner Management Services
81%
Module Name
Bugs Count
Commons
0
Admin
20
Pre Registration
0
Registration client
46
Registration Processor
12
ID Authentication
0
ID Repository
0
Resident Services
0
Partner Management Services
0
Module Name
Vulnerabilities
Hotspots
Commons
0
0
Admin
5
0
Pre Registration
0
0
Registration client
0
3
Registration Processor
1
2
ID Authentication
0
0
ID Repository
0
0
Resident Services
0
0
Partner Management Services
0
0
High
0
Medium
18
Low
8
Information
0
Total
26
Fixed
Medium
Low
Description
An attacker can steal a JWT cookie from the browser and try to extract any personal information that is available there. 1. Install cookie manager plugin in any browser 2. Login into the application and click cookie manager 3. Select JWT for current page 4. Copy the JWT and go to jwt.io website to decode the token 5. Check if any sensitive information is disclosed in the token's payload as this is mostly base64 encoded
Risk Assessment
For authentication and authorization in MOSIP we use JWT tokens. If any PII data is shared in the token, it would be considered a data breach.
Fix Recommendation
No PII data should be shared in the token.
Fixed
Medium
Low
Description
Attacker can steal JWT cookie from the browser and crack the JWT secret key 1. Get the JWT token using the cookie manager plugin 2. Run an automated tool to crack the JWT token and check if you can break the security key if the security key is weak
Risk Assessment
For authentication and authorization in MOSIP we use JWT tokens. If the token is broken, the secret key can be revealed as well as other important data can be exploited.
Fix Recommendation
A very strong and random secret key should be used and it should be changed at regular intervals.
Fixed
Low
Low
Risk Assessment
If a session doesn't get invalidated after calling the logout API, then the risk of any attacker taking over the session becomes high.
Fix Recommendation
The session must be invalidated as soon as the user calls the logout API. After the token gets invalidated, all the access for the token should be removed.
Fixed
Medium
Medium
Risk Assessment
If an attacker bypasses authentication, then a lot of other vulnerabilities can be exploited by the attacker.
Fix Recommendation
In our modules, we don’t use username and password externally, hence this is inapplicable.
Known issue, not a vulnerability
Medium
Medium
Risk Assessment
It allows the PII data of an individual to be leaked. It can also lead to generation of faulty data and incomplete profiles.
Fix Recommendation
Most of the data should be sent in an encrypted manner.
Known issue, not a vulnerability
Medium
Low
Risk Assessment
A denial of service (DoS) attack can take place if an attacker uses a tool to send thousands of requests each minute, which may cause server to crash or be inefficient.
Fix Recommendation
There should be a limit on number of times an user can send a request, and there must be blacklisting method for disabling users who are sending too many requests.
Known issue, not a vulnerability
Low
Low
Risk Assessment
With a sophisticated tool an attacker can try to brute force through the initial login page. If he is successful, He will be able to further attack all the available options that an admin has.
Fix Recommendation
The passwords have to be strong and authentication should not allow numerous attempts.
Fixed
Medium
Medium
Risk Assessment
If an attacker gets through admin login, he will be able to use malicious scripts through the UI and can take over the server.
Fix Recommendation
All inputs by user’s should be considered as potentially dangerous and must pass through sanity. It should always be treated as text and not scripts. In mosip we use anti-xss configuration as well.
Fixed
Medium
Medium
Risk Assessment
Malicious file upload can be a considered one of the high risk attacks. An attacker can create a malicious file with script sin the file name or scripts hidden inside the meta data of the file and the server may execute it.
Fix Recommendation
In admin portal there are two types of uploads ".CSV" and ".csr". Both of these inputs are sanitized and are validated before being used by the code.
Fixed
Medium
Medium
Risk Assessment
If Null byte injected payloads get through and get executed, there is a good chance malicious files can be uploaded, may even lead to RCE.
Fix Recommendation
Sanitation of every input is done thoroughly, all the filenames and extensions are whitelisted and checked before being used.
Fixed
Low
Medium
Risk Assessment
If buffer overload attacks are tried and are successful it can lead to server crashing and can cause issues with the day to day operation of the project.
Fix Recommendation
In MOSIP,the size limit is set to 4 Megabytes, which is configurable and hence buffer overload threat is mitigated.
Known Issue
Low
Medium
Risk Assessment
Banner grabbing is not a direct vulnerability however it may lead attackers to try newly exposed vulnerability of software or framework that has not been patched yet.
Fix Recommendation
In MOSIP, configurations have been changed and updated so that these values are not accessible to external users. The patches are also updated regularly.
Known Issue
Medium
Medium
Risk Assessment
If path traversal is allowed the attacker will try to find any important files through adding ../../ to the url in the request.
Fix Recommendation
In MOSIP, path traversal is not allowed and all files are secured robustly. We use server configurations to sanitize the URLs.
Fixed
Medium
Medium
Risk Assessment
A CSRF or a Cross Site Request Forgery is a very dangerous vulnerability. In a CSRF attack an attacker can send a malicious link to an authentic user and if the website is susceptible to CSRF attack then it will allow the attacker to steal the token of the user and access to the server.
Fix Recommendation
CSRF is blocked in MOSIP, using anti-CSRF configurations.
Fixed
Medium
Medium
Risk Assessment
CORS or Cross Origin Resource Sharing is equally dangerous. It allows external users to have access to resources that only intended user should have access to.
Fix Recommendation
CORS is also blocked in mosip using anti-CORS configurations.
Known Issue, not a vulnerability.
Low
Medium
Risk Assessment
In a Header manipulation attack an attacker changes the headers of the requests to see if it shows any values or errors in response. Without right validation these Headers can cause unwanted changes in DB and Server.
Fix Recommendation
In MOSIP, each request is whitelisted with only the one header it is required to have and manipulating header values will
Known Issue, not a vulnerability.
Low
Medium
Risk Assessment
The certificates are key to establishing the trust chain among various modules in MOSIP. If an incorrect certificate gets through and replaces a valid one, it may cause the module to stop working all together.
Fix Recommendation
In MOSIP, we require a specific format to upload certificates and before accepting any certificate we match the public key modulus of the certificates.
Fixed
Medium
Medium
Risk Assessment
Request smuggling although uncommon is still a very dangerous vulnerability. In request smuggling we send multiple packets of data in quick succession to try and deceive the server and use the incorrect packet of data.
Fix Recommendation
In MOSIP,we do not allow any external header and all the input are sanitized before being used by the server.
Fixed
Medium
Medium
Risk Assessment
XXE injections are used by attackers to input payloads into the logic of an XML application.
Fix Recommendation
The inputs are robustly sanitized before use and also special characters are not allowed in every field,to minimize risk.
Known issue, not a vulerability
Low
Medium
Risk Assessment
If an attacker is able to successfully spoof or change the data of a person, then he/she would be able to make unwanted changes in the database.
Fix Recommendation
In MOSIP, each piece of data goes through multiple layers if encryption/decryption and signature validation. Hence, any spoofed or changed data will be invalid.
Fixed
Medium
Medium
Risk Assessment
The double host header or multiple header attack allows the attacker to send malicious data or website links in the headers of the request.
Fix Recommendation
In MOSIP, each header value is sanitized and validated before use.
Fixed
Medium
Medium
Risk Assessment
This is an example of horizontal privilege escalation. An attacker with a regular user access tries to get the data of another user.
Fix Recommendation
In MOSIP, horizontal privilege escalation is not possible, each request is accompanied with an unique cookie which an attacker does not have.
Known issue, not a vulnerability.
Medium
Medium
Risk Assessment
In privilege escalation attacks an attacker already has user access and then tries to get admin access. They can try to add extra roles in tokens or use possible admin username and passwords.
Fix Recommendation
In MOSIP, all roles are provided and secured by KeyCloak and each token is validated before use, hence no privilege escalation attacks are probable.
Fixed
Medium
Medium
Risk Assessment
The HTTP 'X-Content-Type-Options' response header prevents the browser from MIME-sniffing a response away from the declared content-type.
Fix Recommendation
In MOSIP, X-content type header is added to configuration to mitigate the vulnerability.
Fixed
Medium
Medium
Risk Assessment
When the used cipher is weak ,it usually tends to fall short in front of brute-force attacks and that leads to data leakage.
Fix Recommendation
In MOSIP we have used hardened ciphers which are highly impossible to break even with sophisticated tools.
Fixed
Medium
Medium
Risk Assessment
The primary benefit of CSP is preventing the exploitation of cross-site scripting vulnerabilities. When an application uses a strict policy, an attacker who finds an XSS bug will no longer be able to force the browser to execute malicious scripts on the page
Fix Recommendation
In MOSIP, we have CSP set in our ngnix configurations along with many other properties to harden our server configuration.
Fixed
Medium
Medium
Risk Assessment
In the registration client, we have an option to import data from preregistered PRIds, which are multiple zip files. If the size and content of the zip files are not regulated, it may lead to buffer overload among other problems.
Fix Recommendation
To mitigate this we have configure a limit of, 1.size of zip file 2.maximum no of files allowed inside a zip 3.The maximum allowed ratio of files and their resultant zip files.
Total | Passed | Failed | Skipped |
386 | 206 | 138 | 42 |
registration-client |
mosip-mock-services |
artifactory-ref-impl |
mosip-infra |
mosip-helm |
K8s-infra |
partner-management-portal |
Passed | Feature(s) working as designed |
Failed | Feature(s) working as designed |
Not Verified | Feature(s) not verified |
Partially Working | Feature(s) not completely working as designed |
Login using email OTP |
Login using SMS OTP |
Captcha |
Create application |
Appointment booking |
Notifications - E-mail |
Notifications - SMS |
Download and print acknowlagement |
Upload document(s) |
Appointment cancellation |
Appointment re-booking |
Group booking |
Discard Application |
Multi-Language support |
Dynamic UI |
Audit |
Master data sync |
First user onboarding |
Operator/Supervisor onboarding |
New registration - using sync'd PRID |
New registration - using online PRID |
New Registration - without PRID |
New Registration - with valid introducer UIN/RID |
New Registration - with exceptions |
Update - Demographics |
Update - Biometrics |
Lost UIN - Adult |
Lost UIN - Child |
Acknowledge preview have related/catpured data |
Child becomes Adult - update biometrics |
Officer biometric update |
Bio Login - Fingerprint/IRIS/Face (MockSDK) |
Packet creation authentication using biometrics (MockSDK) |
EOD authentication using biometrics (MockSDK) |
EOD authentication using password |
Offline Registration |
Password Re-set |
Remap Center |
Auotmatic Upload packet with & without EOD |
Save applications to device |
Application status check |
Dynamic UI |
Multi language support |
Registration client with TPM-enabled |
Registration client without TPM |
Audit |
Demo - De-duplication |
Biometric - De-duplication |
Manual adjudication |
Audit |
Notification based on user preferred language |
Policy based packet processing |
Support for pause resume |
Hotlisting |
Biometric correction |
Auth (Bio/Demo/OTP) using UIN |
Auth (Bio/Demo/OTP) using VID |
Multi-factor auth using UIN |
Multi-factor auth using VID |
e-KYC (Bio/Demo/OTP) using UIN |
e-KYC (Bio/Demo/OTP) using VID |
e-KYC multi-factor auth using UIN |
e-KYC multi-factor auth using VID |
Auth lock/unlock |
Create UIN |
Deactivate/reactivate UIN |
VID generation (Perpetual/Temporary) |
Audit |
Update demo details |
View auth history |
Download UIN card |
Download masked UIN card |
Revoke VIDs |
Lock/Unlock auth (Bio/Demo) |
Generate VID (Perpetual/Temporary) |
Audit |
Check Packet Status |
User mapping - To Zone/RegCenter |
Center - Create/Edit/Activate/Deactivate/Decommission |
Device - Create/Edit/Activate/Deactivate/Decommission |
Machine - Create/Edit/Activate/Deactivate/Decommission |
Packet Status - for given RID |
Packet Pause/Resume - for given RID |
CenterType - Create/Edit/Activate |
CenterType - Cloning to logged in language |
BlockListedWords - Create/Edit/Activate/Deactivate |
HolidayList - Create/Edit/Activate/Deactivate |
HolidayList - Cloning to logged in language |
Template - Create/Edit/Activate/Deactivate |
Template - Cloning to logged in language |
Dynamicfield - Create/Update/Activate/Deactivate |
Device Specification - Create/Edit/Activate/Deactivate |
Machine Specification - Create/Edit/Activate/Deactivate |
Machine Type - Create/Edit/Activate/Deactivate |
Document Type - Create/Edit/Activate/Deactivate |
Document Category- Create/Edit/Activate/Deactivate |
Document Category Type - Create/Edit/Activate/Deactivate |
Device type-Create/Update/Activate/Deactivate |
Bulk upload - Packets |
Bulk upload - MasterData - Insert/Update/Delete to a table |
Keymanager - Generate CSR |
Keymanager - Generate MasterKey |
Keymanager - Get certificate |
Keymanager - Upload certificate for APID and RID |
Keymanager - Upload other domain certificate for APID and RID |
Multi Language support |
Retrieve Lost RID |
Partner - Register/Activate/Deactivate |
Partner Certificates Upload |
Upload CA Certificate |
Download Certificate |
Partner - Policy Mapping |
Policy Group - Create/Edit/Activate/Deactivate |
Auth Policy - Create/Edit/Activate/Deactivate |
Data share Policy - Create/Edit/Activate/Deactivate |
Partner policy mapping - Map policy/Approve/Reject |
Device details - Create/Edit/Activate/Deactivate/SBI details |
FTM details - Create/Edit/Approve/Reject |
Upload CA certificate |
Audit |
Release Name: 1.2.0.1 Beta4
Release Version: 1.2.0.1-B4
Support: Developer Release
Release Date: 12th January, 2024
The MOSIP 1.2.0.1 Beta4 release marks an upgrade from version 1.1.5.x to 1.2.0.1. This release primarily focuses on the migration of all services/modules to V3 architecture along with important bug fixes, enhancements to security, and improvements in performance.
Additionally, this release incorporates enhancements to the existing features in Mock Services, aiming to enhance the user experience. For a comprehensive summary of the modifications, refer here.
To know more about the upgrades, refer Upgrade Runbook.
For complete documentation, refer to 1.2.0 LTS documentation.
To read though the Test Reports, refer here.
Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.
Developer documentation has been included for all repositories to facilitate the setup process on developers' local systems.
Release Version: 1.2.0.1
Release Date: 19th March, 2024
The 1.2.0.1 release incorporates all features previously released in beta, including upgrade of platform to V3 architecture along with several significant fixes requested by the countries. It prioritizes enhancements in testability, usability, and security.
To know more about upgrade, please refer here.
Also included in this release are Domain Specific Language (DSL) automation scripts, which facilitate platform testing. Additionally, several security-related issues have been addressed. Click here for more information on test automation.
Another major highlight of this patch release is the Print Stage. The Print Stage, now re-named as Credential Requestor Stage, additionally manages the initiation of credential requests tailored to partner-specific information needs. Click here to know more about the Credential Requestor Stage.
Implementation of handles in ID Repository is also included as part of this release. Refer here to know more about handles and its implementation.
Major Areas of Work
Credential Requestor Stage
Introduction of Handles in ID Repository
Functional bug fixes
Security bug fixes
Test Automation
Performance fixes
Sonar bug fixes
The scope of testing is to verify fitment to the specification from the perspective of:
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the configurability and extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, the verification scope required comprehensive automation testing for all the MOSIP APIs. An automated Test Rig is created for the same.
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the test scenarios that resemble a real-time implementation.
A Persona is a fictional character/ user profile created to represent a user type that might use a product/ or a service in a similar way. Persona-based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/ scenarios that the customers will execute. The persona's needs may be addressed through any of the following:
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
For regression check, MOSIP Test Rig
, an automation testing suite is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to the creation of the packet in the registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on the configuration mentioned below:
Default configuration- with 1 Language (English)
Deployment testing as per the Upgrade Runbook.
Reprocess the packets (which are generated and paused in 1.1.5.x at various stages) after the upgrade.
Reg.Client 1.1.5.5 and Reg.Client 1.2.0.1
Reg.Client upgraded from 1.1.5.5 to 1.2.0.1
The below section provides details on API test metrics for all modules by executing MOSIP functional automation Framework. All external API test executions were performed at module-level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.
Test Rate: 83.88 with Pass Rate: 76.25%
Here is the detailed breakdown of metrics:
Functional and automation test rig code base branch which is used for the metrics are:
https://github.com/mosip/mosip-functional-tests/tree/release-1.2.0.1
https://github.com/mosip/mosip-automation-tests/tree/release-1.2.0.1
End-to-end flows are a set of stateful test cases that expects the results across multiple modules. The test does not cover the intermediary stages, rather concentrates on the end result for a given data. The test covers both negative scenarios and positive scenarios with real world scenarios. Below are the end-to-end scenarios test metrics by executing MOSIP Automation Framework.
Test Rate: 97.33% with Pass Rate: 56%
Below are the detailed test metrics by performing manual/ automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
This document provides details on the performance measurement approach of prioritized scenarios of MOSIP modules and provides detailed reports on the results.
APIs in all modules are prioritized based on the high load expectation and usage frequency by other modules.
There are 3 types of performance scenarios covered in this report
Prioritized single API performance (For most modules)
End to end UI API sequence performance (For pre-registration module)
End to end message delivery performance (For web-sub module)
All individual test scenarios from the modules are listed below.
The approach to performance testing differs based on the testing scenarios and are detailed as per the categorization as below.
Run a single pod of the application hosting the required API
Run four pods each of the dependent applications to cater the load implied from the test application
Simulate varied load profilers like 10, 30, 50 etc.. concurrent users from Jmeter for that single API for a period of one hour
Record the average and 90th percentile response time metrics specific to each load profiles
Verify that JVMs show stable memory and CPU usage over the increasing load profiles.
Run a single pod for each application hosting the required APIs called directly from Jmeter
Run four pods each of the dependent applications to cater the load implied from the test application
Simulate varied load profilers like 50, 80, 100 etc.. concurrent users from Jmeter for end to end sequence of APIs called from UI for a period of one hour
Record the average and 90th percentile response time metrics for entire end to end API sequence for each load profiles
Verify that JVMs show stable memory and CPU usage over the increasing load profiles.
Run a single pod for each application hosting the required APIs called directly from Jmeter
Run four pods each of the dependent applications to cater the load implied from the test application
Simulate varied load profilers like 10, 30, 50 etc.. concurrent users to publish continues messages to the test application for a period of one hour
Record the average and 90th percentile response time metrics for publish API for each load profiles
Record the average and 90th percentile delivery time metrics for entire end to end message delivery for each load profiles
90th Percentile Response Times
Detailed Metrics for all 14 modules is available below:
Run 1: 50 concurrency
Jmeter Aggregate Report
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time Graph from Kibana
Dependency app graph for auth manager service was empty so not attached.
Run 2: 30 concurrency
Jmeter Aggregate Report
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time Graph from Kibana
Application dependency graph was empty so not attached.
Run 1: 30 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
We only have the graph for Validate token as the previous ones were cleared
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Dependency app graph was empty so so not attached.
Notes:
Keycloak was having issue by end of client id secret key API run, so the keycloak was restarted before the start of user id password API
Run 2: 50 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time Graph from Kibana
Dependency app graph was empty so so not attached.
Notes:
Keycloak was having issue by end of user id password API run, so the keycloak was restarted before the start of validate token API
Run 1: 30 concurrency
Aggregate Report from Jmeter
Note: idgenerator- generate vid api threw error as “VID not available for allocation error”, so it ran only for around 20 mins rest all other api’s ran for the complete 1 hour run.
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Note: idgenerator & pridgenerator services are vertx apps so there are no kibana graphs for the same
Dependent Application Response Time Graph from Kibana
Dependency app graph was empty so above are the graphs for the application services from kibana
Notes: Some of the kernel service api’s failed with oomkilled & authentication failed issues, so restarted the same and then continued the load test from the next set of api’s that’s why we have multiple graphs from jmeter & grafana.
Run 2: 10 & 50 concurrency
Aggregate Report from Jmeter
Note: idgenerator- generate vid api threw error as “VID not available for allocation error”, so it ran only for around 10 mins & also notification manager sms api & rid generator api failed completely with 502 bad gateway errors for 50 concurrency.
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Note: The grafana graphs for the other services like otpmanager, ridgenerator, pridgenerator & id generator services are lost as they were old data
Application Response Time Graph from Kibana
Note: idgenerator & pridgenerator services are vertx apps so there are no kibana graphs for the same
Dependent Application Response Time from Kibana
Dependency app graph was empty so above are the graphs for the application services from kibana
Notes: Some of the kernel service api’s failed with oomkilled & authentication failed issues, so restarted the same and then continued the load test from the next set of api’s that’s why we have multiple graphs from jmeter & grafana.
Run 1: 10 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Grafana graphs were erased for older data
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 2: 30 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Grafana graphs were erased for older data.
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 1: 30 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
No data was captured for registration processor registration status service graph in Kibana for the entire test duration.
Note: Registration processor stage group 1 service is a vertx app so there is no Kibana graph for this.
Dependent Application Response Time from Kibana
Run 2: 10 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
No data was captured for registration processor registration status service graph in Kibana for the entire test duration.
Note: registration processor stage group 1 service is a vertx app, so there is no kibana graph for this.
Dependent Application Response Time from Kibana
Run 1: 30 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 2: 10 & 50 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 1: 30 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
CPU container usage grafana graphs are not available for resident service container
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 2: 10 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
CPU container usage grafana graphs are not available for resident service container
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 1: 30 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 2: 10 & 50 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
Run 1: 30 concurrency
Aggregate Report from Jmeter
Note: Add Identity api threw a lot of duplicate key constraint errors ~27.29 %
\norg.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "uk_uin_reg_id"
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
No data was captured for the Kibana graphs of id repository identity & VID services
Dependent Application Response Time from Kibana
Run 2: 10 & 50 concurrency
Aggregate Report from Jmeter
Note: Add Identity API threw a lot of duplicate key constraint errors ~27.29 %
\norg.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "uk_uin_reg_id"
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
No data was captured for the Kibana graphs of ID repository identity & VID services
Dependent Application Response Time from Kibana
Run 1: 30 & 50 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
No data was captured for the Grafana - CPU & memory container usage graphs
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
No data was captured for dependency apps in kibana
Run 2: 10 & 30 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
No data was captured in Grafana for CPU & memory container usage graphs
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
No data was captured for dependency apps in Kibana.
Run 1: 30 & 50 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
No data was captured in Grafana for CPU & memory container usage graphs.
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
No data was captured for dependency apps in Kibana.
Run 2: 10 & 80 concurrency
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Application Response Time Graph from Kibana
Dependent Application Response Time from Kibana
No data was captured for dependency apps in kibana.
Run 1: 50 concurrency
90th Percentile response time ( End to end UI flow) - 18.9 sec
Aggregate Report from Jmeter
Note: Error percentage for pre-registration is due to the unavailability of slots for 53 unique registration centres.
Slots were generated for 947 unique reg centres and for the rest 53 centres slots were not created so this needs to be debugged further.
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Self-response time graphs from Kibana
Dependent Application Response Time from Kibana
Notes: Prereg is connected to the internal database because when we tried connecting it to the external database we were getting failures while booking appointments manually.
Run 2: 80 concurrency
90th Percentile response time ( End to end UI flow) - 30.9 sec
Aggregate Report from Jmeter
Note:
Error percentage for pre-registration is due to the unavailability of slots for 53 unique reg centres. Slots were generated for 947 unique reg centres and for the rest 53 centres slots were not created so this needs to be debugged further.
Got some 504 gateway timeout errors for a few of the transactions before booking an appointment.
Response Time Percentile Graph using Jmeter
CPU and Memory Utilization Graphs using Grafana
Self-response time graphs from Kibana
Dependent Application Response Time from Kibana
Notes: Pre-registration is connected to the internal database because when we tried connecting it to an external database we were getting failures while booking appointments manually.
90th Percentile response time
Publish (10 subscribers, 8 topics) - 0.221 sec
End to end message delivery (10 subscribers, 8 topics) -
finalAvgNinetiethPercentile=5777.9 sec finalAvgTurnAroundTime=3327.8 sec
Aggregate Report from Jmeter
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
90th Percentile response time
Publish (10 subscribers, 8 topics) - 0.25 sec
End to end message delivery (10 subscribers, 8 topics)
finalAvgNinetiethPercentile = 9810 sec
finalAvgTurnAroundTime = 5719.9 sec
Aggregate Report from Jmeter
Response Time Percentile Graph using Jmeter
Repo Name | Version | Branch Name | Coverage |
---|---|---|---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Label | # Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|
Repositories
Tags Released
bio-utils
commons
mosip-openid-bridge
biosdk-client
biosdk-services
audit-manager
keymanager
khazana
packet-manager
admin-services
id-repository
pre-registration
id-authentication
registration
resident-services
registration-client
partner-management-services
websub
durian
mosip-config
mosip-mock-services
migration-utility
mosip-functional-tests
converters
keycloak
reporting
mosip-ref-impl
artifactory-ref-impl
mosip/mock-smtp-sms
mosip-helm
mosip-infra
K8s-infra
Repositories
Tags Released
admin-ui
artifactory-ref-impl
admin-services
audit-manager
biosdk-client
commons
id-authentication
id-repository
otp-manager
packet-manager
demosdk
durian
keymanager
packet-manager
postres-init
partner-management-services
partner-management-portal
pre-registration
resident-services
registration
registration-client
mosip-openid-bridge
mosip-functional-test
biosdk-services
bio-utils
mosip-config
mosip-helm
keyclock
khazana
mosip-automation-tests
mosip-onboarding
mosip-data
mosip-infra
mosip-ref-impl
mosip-file-server
mosip-mock-services
mock-smtp-sms
migration-utility
k8s-infra
reporting
demosdk
pre-registration-ui
digital-card-service
tusd-server
converters
websub
Total
Passed
Failed
Skipped
3369
2596
230
543
Module
Total
Passed
Failed
Skipped
ID Repository
321
282
39
0
Resident
1132
550
48
534
Master Data
923
837
81
5
ID Authentication
482
433
45
4
Partner Management
511
494
17
0
Total
Passed
Failed
Skipped
150
84
62
4
admin-services
1.2.0.1-B1
release-1.2.0.1
79.2%
admin-ui
1.2.0.1-B2
release-1.2.0.1
0%
audit-manager
1.2.0.1-B2
release-1.2.0.1
100%
id-authentication
1.2.0.1-B5
release-1.2.0.1
70.9%
id-repository
1.2.0.1-B2
release-1.2.0.1
81.2%
commons
1.2.0.1-B2
release-1.2.0.1
82.7%
packet-manager
1.2.0.1-B2
release-1.2.0.1
0%
durian
1.2.0.1-B2
release-1.2.0.1
84.8%
keymanager
1.2.0.1-B3
release-1.2.0.1
21.8%
partner-management-services
1.2.0.1-B4
release-1.2.0.1
74.4%
pre-registration
1.2.0.1-B2
release-1.2.0.1
81%
1.2.0.1-B2
release-1.2.0.1
2.4%
Registration
1.2.0.1-B3
release-1.2.0.1
81.2%
resident-services
1.2.0.1-B3
release-1.2.0.1
77.3%
registration-client
1.2.0.1-B2
release-1.2.0.1
73.7%
mosip-openid-bridge
1.2.0.1-B3
release-1.2.0.1
81%
khazana
1.2.0.1-B2
release-1.2.0.1
2.1%
biosdk-client
1.2.0.1-B3
release-1.2.0.1
100%
Module Name | API Scenario | API Endpoint |
Kernel | Add Audits | v1/auditmanager/audits |
Kernel | Client Id - Secret Key | v1/authmanager/authenticate/clientidsecretkey |
Kernel | User Id Pwd | v1/authmanager/authenticate/internal/useridPwd |
Kernel | Validate Token | v1/authmanager/authorize/admin/validateToken |
Kernel | Generate OTP | v1/otpmanager/otp/generate |
Kernel | Validate OTP | v1/otpmanager/otp/validate?key={keyValidate}&otp={otpValidate} |
Kernel | Send SMS | v1/notifier/sms/send |
Kernel | Send EMAIL | v1/notifier/email/send |
Kernel | Generate PRID | v1/pridgenerator/prid |
Kernel | Generate UIN | v1/idgenerator/uin |
Kernel | Generate VID | v1/idgenerator/vid |
Kernel | Generate RID | v1/ridgenerator/generate/rid/{centerID}/{machineID} |
IDA | Auth with OTP | idauthentication/v1/auth/{mispLicenseKey}/{rpPartnerId}/{rpApiKey} |
IDA | KYC with OTP | idauthentication/v1/kyc/{mispLicenseKey}/{ekycPartnerId}/{ekycApiKey} |
IDA | Auth with bio | idauthentication/v1/auth/{mispLicenseKey}/{rpPartnerId}/{rpApiKey} |
IDA | KYC with bio | idauthentication/v1/kyc/{mispLicenseKey}/{ekycPartnerId}/{ekycApiKey} |
IDA | Send OTP | idauthentication/v1/otp/{mispLicenseKey}/{rpPartnerId}/{rpApiKey} |
Pre-Registration | Prereg UI end to end flow | Prereg UI end to end flow |
Syncdata | Public Key Verify | v1/syncdata/tpm/publickey/verify |
Syncdata | Get Certificate | v1/syncdata/getCertificate?applicationId={appID}&referenceId={refID} |
Syncdata | Get User Details | v1/syncdata/userdetails?keyindex={keyIndex} |
Syncdata | Get Client Settings | v1/syncdata/v2/clientsettings?keyindex={keyIndex} |
Syncdata | Get Configs | v1/syncdata/configs/{name} |
Syncdata | Get LatestID Schema | v1/syncdata/latestidschema?schemaVersion={schemaVersion} |
Syncdata | Get CAcertificates | v1/syncdata/getcacertificates |
Regproc | Sync Registration Packet Details | registrationprocessor/v1/registrationstatus/sync |
Regproc | Get Packet status | registrationprocessor/v1/registrationstatus/search |
Regproc | Upload Registration Packet | registrationprocessor/v1/packetreceiver/registrationpackets |
Resident | Request/Send OTP | resident/v1/req/otp |
Resident | RID Check Status | resident/v1/rid/check-status |
Resident | Auth Lock | resident/v1/req/auth-lock |
Resident | Auth Unlock | resident/v1/req/auth-unlock |
Resident | Credential Request | resident/v1/req/credential |
Resident | Auth History | resident/v1/req/auth-history |
Resident | Generate VID | resident/v1/vid |
Datashare | Create Data Share URL | v1/datashare/create/{policyId}/{subscriberId} |
Datashare | Get Data Share File | v1/datashare/get/{policyId}/{subscriberId}/{randomShareKey} |
IDRepo | Retrieve Identity using UIN | idrepository/v1/identity/idvid/{uin} |
IDRepo | Retrieve Identity using VID | idrepository/v1/identity/idvid/{vid} |
IDRepo | Add Identity | idrepository/v1/identity/ |
IDRepo | Update Identity | idrepository/v1/identity/ |
IDRepo | Auth Type Status | idrepository/v1/identity/authtypes/status |
IDRepo | Create VID | idrepository/v1/vid |
IDRepo | Update VID | idrepository/v1/vid/{vidGenerated} |
Masterdata | Get Registration Centers | v1/masterdata/registrationcenters |
Masterdata | Get Templates | v1/masterdata/templates |
Masterdata | Get Templates By Lang & Temp Code | v1/masterdata/templates/{lang&TempTypeCode} |
Masterdata | Get Latest ID Schema | v1/masterdata/idschema/latest?schemaVersion={schemaVersion} |
Masterdata | Get Dynamic Fields | v1/masterdata/dynamicfields?pageNumber=0&pageSize=10&sortBy=name&orderBy=desc |
Masterdata | Get Users | v1/masterdata/users/{userID}/{time(yyyy-MM-dd'T'HH:mm:ss.sss'Z',)} |
Keymanager | Encrypt Data | v1/keymanager/encrypt |
Keymanager | Encrypt Data With Pin | v1/keymanager/encryptWithPin |
Keymanager | Generate JWT Signature | v1/keymanager/jwtSign |
Keymanager | Decrypt Data | v1/keymanager/decrypt |
Keymanager | Decrypt Data With Pin API | v1/keymanager/decryptWithPin |
Keymanager | Verify JWT Signature | v1/keymanager/jwtVerify |
Tools | Purpose |
Jmeter | To verify the Load and Performance of all the applications. |
Title | Description |
Build Tag Version | 1.2.0-rc2 |
Performance script source location | https://github.com/mosip/mosip-performance-tests-mt/tree/1.2.0 |
CPU (cores) | Memory (GB) | HDD (GB) | OS | Count | Purpose |
8 | 30 | 768 | Cent OS | 1 | Kubernetes console machine |
8 | Kubernetes node machines |
4 | 16 | 500 | Ubuntu | 1 | Database machine |
4 | 16 | 835 | Windows | 3 | Jmeter test machines |
Pod/Application Names | Resource Allocation (Limits) |
Memory (M) | CPU (m) | Heap (M) |
kernel-auditmanager-service | 2500 | 1000 | 1750 |
kernel-auth-service | 2250 | 500 | 1500 |
kernel-otpmanager-service | 1750 | 500 | 1000 |
kernel-notification-service | 1500 | 500 | 1000 |
kernel-pridgenerator-service | 1750 | 300 | 1000 |
kernel-idgenerator-service | 3500 | 500 | 2000 |
kernel-ridgenerator-service | 1750 | 500 | 1000 |
ida-auth-service | 4000 | 4500 | 2000 |
ida-otp-service | 3000 | 3000 | 2000 |
prereg-application-service | 2500 | 1000 | 2000 |
kernel-syncdata-service | 5000 | 500 | 4000 |
regproc-registration-status-service | 4000 | 500 | 2000 |
regproc-stage-group-1 | 5000 | 1000 | 4000 |
resident-service | 3000 | 500 | 2000 |
datashare-service | 3000 | 500 | 2000 |
idrepo-identity-service | 4000 | 1000 | 2000 |
idrepo-vid-service | 3000 | 500 | 1000 |
kernel-masterdata-service | 2250 | 500 | 1500 |
kernel-keymanager-service | 5000 | 1000 | 4000 |
Add Audit API Execution | 231236 | 777 | 395 | 2206 | 2700 | 3402 | 3 | 8420 | 0.00% | 64.22209 | 38.88 | 186.99 |
Add Audit API Execution | 266879 | 403 | 105 | 1199 | 1893 | 2409 | 2 | 3870 | 0.00% | 74.12657 | 44.88 | 215.82 |
Client Id - Secret Key API Execution | 241902 | 449 | 202 | 483 | 597 | 3352 | 9 | 60051 | 0.16% | 66.1073 | 290.08 | 28.49 |
User Id Pwd API Execution | 220878 | 488 | 488 | 680 | 711 | 872 | 70 | 6616 | 0.00% | 61.34721 | 215.9 | 30 |
Validate Token API Execution | 451378 | 239 | 201 | 400 | 496 | 680 | 6 | 3506 | 0.00% | 125.3778 | 582.61 | 235.51 |
Client Id - Secret Key API Execution | 243069 | 740 | 499 | 1694 | 2100 | 2833 | 9 | 7511 | 0.00% | 67.51412 | 296.36 | 29.09 |
User Id Pwd API Execution | 27121 | 5519 | 3290 | 11676 | 22351 | 43894 | 40 | 60047 | 0.39% | 9.05834 | 31.82 | 4.42 |
Validate Token API Execution | 181953 | 989 | 810 | 2107 | 2496 | 3206 | 6 | 8111 | 0.00% | 50.53694 | 234.74 | 94.93 |
Generate OTP API Execution | 87777 | 1229 | 1104 | 2160 | 2496 | 3207 | 5 | 7418 | 0.00% | 24.37841 | 15.57 | 48.04 |
Validate OTP API Execution | 150000 | 1275 | 1128 | 2192 | 2404 | 3196 | 0 | 6268 | 0.02% | 23.4176 | 14.89 | 42.63 |
Notification Manager SMS API Request | 433004 | 246 | 99 | 692 | 808 | 1119 | 2 | 2625 | 0.00% | 120.2695 | 80.92 | 259.67 |
Notification Manager EMAIL API Request | 69727 | 1550 | 1396 | 2992 | 3602 | 5101 | 4 | 13607 | 0.04% | 14.87585 | 9.48 | 41.37 |
PRID Generator API Execution | 102606 | 1052 | 1022 | 1893 | 2073 | 2432 | 5 | 5104 | 0.00% | 28.49246 | 11.74 | 51 |
Generate UIN API Execution | 39971 | 2698 | 2672 | 2813 | 2833 | 3536 | 127 | 8776 | 0.00% | 11.09746 | 26.27 | 23.71 |
Generate VID API Execution | 205377 | 154 | 139 | 266 | 321 | 423 | 5 | 12380 | 6.39% | 193.1971 | 458.89 | 412.75 |
RID Generator API Execution | 368802 | 291 | 193 | 743 | 930 | 1324 | 5 | 5761 | 0.00% | 102.4346 | 63.42 | 221.07 |
Generate OTP API Execution | 768397 | 45 | 9 | 92 | 95 | 100 | 5 | 299 | 0.00% | 213.4406 | 135.9 | 420.63 |
Generate OTP API Request | 90000 | 42 | 8 | 90 | 91 | 94 | 4 | 184 | 0.00% | 225.8061 | 143.77 | 445 |
Validate OTP API Execution | 90000 | 48 | 14 | 92 | 95 | 100 | 6 | 1209 | 0.00% | 201.6066 | 127.78 | 366.99 |
Notification Manager EMAIL API Request | 135462 | 264 | 195 | 606 | 893 | 1198 | 3 | 6299 | 0.00% | 37.62565 | 23.92 | 104.68 |
Notification Manager SMS API Request | 4085605 | 23 | 1 | 2 | 2 | 8 | 1 | 60063 | 99.89% | 1134.873 | 414.17 | 2450.28 |
PRID Generator API Execution | 77782 | 462 | 459 | 792 | 853 | 949 | 8 | 2303 | 0.00% | 21.60354 | 8.86 | 38.67 |
RID Generator API Execution | 1881518 | 86 | 16 | 80 | 97 | 136 | 1 | 60184 | 99.91% | 516.4455 | 1062.7 | 1114.59 |
Generate UIN API Execution | 41290 | 870 | 875 | 896 | 905 | 924 | 87 | 1785 | 0.00% | 11.46714 | 27.12 | 24.5 |
Generate VID API Execution | 1132665 | 157 | 114 | 330 | 355 | 396 | 4 | 3560 | 87.76% | 314.6231 | 763.26 | 672.26 |
Send OTP Execution | 15743 | 2286 | 2396 | 2804 | 2933 | 3192 | 25 | 3855 | 0.01% | 4.371 | 12.22 | 19.2 |
ID Auth Request With OTP | 23060 | 1560 | 1547 | 2058 | 2192 | 2424 | 175 | 3185 | 0.02% | 6.40415 | 17.91 | 33.45 |
EKYC Auth Request With OTP | 22252 | 1616 | 1614 | 2129 | 2265 | 2500 | 294 | 3286 | 0.02% | 6.17927 | 794.05 | 32.46 |
ID Auth Request With Biometrics | 21804 | 1649 | 1639 | 2200 | 2343 | 2611 | 252 | 3794 | 0.02% | 6.05471 | 16.93 | 220.35 |
EKYC Auth Request With Biometrics | 21042 | 1709 | 1691 | 2285 | 2434 | 2728 | 210 | 3712 | 0.02% | 5.84423 | 750.99 | 212.86 |
Send OTP Execution | 13576 | 7958 | 7995 | 8996 | 9308 | 10123 | 4293 | 12046 | 0.03% | 3.76589 | 10.54 | 16.55 |
ID Auth Request With OTP | 20202 | 5348 | 5353 | 6020 | 6261 | 6805 | 2174 | 8238 | 0.02% | 5.60468 | 15.68 | 29.28 |
EKYC Auth Request With OTP | 19889 | 5430 | 5445 | 6142 | 6402 | 6949 | 1027 | 8252 | 0.02% | 5.51885 | 709.21 | 28.99 |
ID Auth Request With Biometrics | 19403 | 5568 | 5581 | 6357 | 6639 | 7252 | 670 | 9007 | 0.02% | 5.38179 | 15.06 | 195.86 |
EKYC Auth Request With Biometrics | 18949 | 5702 | 5726 | 6538 | 6853 | 7509 | 353 | 8850 | 0.02% | 5.25693 | 675.52 | 191.47 |
Sync Registration Packet API Execution | 53535 | 2017 | 1878 | 3029 | 3519 | 4997 | 199 | 14424 | 0.00% | 14.86683 | 15.96 | 51.03 |
Get Packet status API Execution | 87599 | 1232 | 1233 | 1552 | 1630 | 1776 | 243 | 60013 | 0.00% | 24.32718 | 181.49 | 63.17 |
Upload Registration Packet API Execution | 3510 | 30911 | 30991 | 33291 | 34363 | 38198 | 478 | 53099 | 0.00% | 0.96944 | 0.86 | 1948.02 |
Sync Registration Packet API Execution | 64649 | 556 | 550 | 676 | 708 | 909 | 207 | 2110 | 0.00% | 17.95645 | 19.27 | 61.64 |
Get Packet status API Execution | 49530 | 726 | 703 | 978 | 1036 | 1133 | 169 | 60012 | 0.00% | 13.7564 | 145.97 | 35.72 |
Upload Registration Packet API Execution | 6690 | 5386 | 1260 | 11404 | 12258 | 14306 | 123 | 18888 | 0.00% | 1.85473 | 1.65 | 3727.21 |
Public Key Verify API Execution | 435249 | 247 | 209 | 458 | 574 | 866 | 21 | 5613 | 0.00% | 120.8957 | 171.66 | 338.84 |
Get Certificate API Execution | 353275 | 305 | 269 | 546 | 654 | 891 | 20 | 2089 | 0.00% | 98.12497 | 276.26 | 181.01 |
Get User Details API Execution | 11736 | 9213 | 9166 | 9695 | 10276 | 14573 | 730 | 22247 | 0.00% | 3.25181 | 11.79 | 6.16 |
Get Client Settings API Execution | 48931 | 2207 | 1999 | 3703 | 4397 | 5803 | 196 | 10803 | 0.00% | 13.58629 | 2368.66 | 25.82 |
Get Configs API Execution | 20427 | 5290 | 5193 | 5911 | 6286 | 7203 | 1106 | 10596 | 0.00% | 5.66731 | 262.18 | 10.24 |
Get LatestID Schema API Execution | 356781 | 302 | 218 | 651 | 836 | 1276 | 20 | 3355 | 0.00% | 99.10027 | 1510.41 | 179.43 |
Get CAcertificates API Execution | 238505 | 452 | 369 | 878 | 1101 | 1648 | 28 | 4755 | 0.00% | 66.24493 | 7158.97 | 119.1 |
Public Key Verify API Execution | 390125 | 460 | 355 | 947 | 1206 | 1815 | 21 | 6124 | 0.00% | 108.3583 | 153.65 | 303.7 |
Get Certificate API Execution | 300097 | 599 | 500 | 1172 | 1429 | 2005 | 20 | 5102 | 0.00% | 83.34947 | 234.5 | 153.76 |
Get User Details API Execution | 11773 | 3058 | 3054 | 3205 | 3261 | 3534 | 833 | 5279 | 0.00% | 3.2678 | 11.84 | 6.19 |
Get Client Settings API Execution | 52127 | 690 | 692 | 902 | 1001 | 1199 | 79 | 1900 | 0.00% | 14.478 | 2524.09 | 27.51 |
Get Configs API Execution | 18717 | 1923 | 1806 | 2206 | 2386 | 3310 | 1006 | 4100 | 0.00% | 5.19704 | 240.42 | 9.39 |
Get LatestID Schema API Execution | 298200 | 603 | 416 | 1369 | 1780 | 2732 | 21 | 7979 | 0.00% | 82.82468 | 1262.19 | 149.96 |
Get CA certificates API Execution | 220333 | 816 | 599 | 1747 | 2248 | 3424 | 28 | 8297 | 0.00% | 61.19382 | 6613.03 | 110.02 |
Request OTP | 5277 | 20527 | 13618 | 60012 | 60013 | 60021 | 1325 | 60079 | 11.29% | 1.45586 | 1.33 | 2.92 |
RID Check Status | 73109 | 1477 | 1013 | 3220 | 4260 | 6770 | 105 | 21521 | 0.00% | 20.29957 | 12.91 | 40.1 |
Auth Lock API | 16981 | 6364 | 5670 | 10923 | 12893 | 17213 | 567 | 31744 | 0.00% | 4.71056 | 3.19 | 9.53 |
Auth Unlock API | 16223 | 6662 | 5966 | 11496 | 13537 | 17909 | 375 | 33340 | 0.00% | 4.49985 | 3.06 | 9.26 |
Request Credential API | 16253 | 6652 | 5994 | 12227 | 14217 | 19044 | 273 | 38494 | 0.00% | 4.50174 | 2.95 | 9.83 |
Auth History API | 5100 | 21221 | 18707 | 37493 | 44213 | 59170 | 1479 | 60023 | 0.82% | 1.41057 | 0.99 | 2.89 |
Generate VID API Execution | 14410 | 7504 | 6832 | 12998 | 15335 | 20769 | 600 | 37105 | 0.00% | 3.99359 | 2.67 | 8.06 |
Request OTP | 4810 | 7493 | 7549 | 8397 | 8635 | 9405 | 1463 | 13833 | 0.00% | 1.33296 | 0.93 | 2.67 |
RID Check Status | 56043 | 641 | 562 | 1101 | 1379 | 1959 | 103 | 3881 | 0.00% | 15.56573 | 9.91 | 30.75 |
Auth Lock API | 10000 | 2411 | 2010 | 4085 | 4872 | 6406 | 258 | 9587 | 0.02% | 4.12136 | 2.79 | 8.34 |
Auth Unlock API | 10000 | 2438 | 2060 | 4165 | 4900 | 6349 | 401 | 9044 | 0.02% | 4.08215 | 2.77 | 8.4 |
Request Credential API | 10000 | 2440 | 1557 | 5310 | 6421 | 9416 | 215 | 13339 | 0.02% | 4.0734 | 2.67 | 8.9 |
Auth History API | 4490 | 8025 | 7987 | 9591 | 10157 | 11535 | 2059 | 14581 | 0.00% | 1.24482 | 0.85 | 2.55 |
Generate VID API Execution | 10000 | 2720 | 2090 | 5090 | 6213 | 8163 | 385 | 11400 | 0.02% | 3.6507 | 2.45 | 7.37 |
Create Data Share URL Execution | 13434 | 8044 | 7901 | 11306 | 12400 | 14202 | 1421 | 18805 | 0.00% | 3.72685 | 3.44 | 3845.7 |
Get Data Share File Execution | 185315 | 582 | 302 | 804 | 2775 | 4705 | 8 | 12710 | 0.00% | 51.47058 | 4263.17 | 115.79 |
Create Data Share URL Execution | 13253 | 2716 | 2528 | 4035 | 4532 | 5426 | 249 | 12256 | 0.00% | 3.6798 | 3.4 | 3797.15 |
Get Data Share File Execution | 179001 | 1004 | 602 | 2498 | 2899 | 3520 | 10 | 7101 | 0.00% | 49.71529 | 33.6 | 111.84 |
Add Identity (bio) Execution | 9000 | 7407 | 7366 | 9210 | 9878 | 11094 | 110 | 15147 | 27.29% | 4.02176 | 2.88 | 4397.92 |
Retrieve Identity using UIN | 505883 | 213 | 198 | 295 | 358 | 697 | 22 | 1304 | 0.22% | 140.5188 | 243.91 | 303.41 |
Retrieve Identity using VID | 130678 | 825 | 506 | 1701 | 1913 | 2452 | 13 | 3792 | 0.46% | 36.29708 | 62.91 | 78.59 |
Create VID Execution | 105575 | 1022 | 798 | 1992 | 2296 | 2501 | 99 | 3618 | 0.48% | 29.32075 | 20.84 | 69.64 |
Update Identity Execution | 15000 | 3167 | 3085 | 4707 | 5207 | 6402 | 121 | 9115 | 2.49% | 9.3834 | 6.7 | 34.79 |
Update VID Execution | 15000 | 1455 | 1403 | 2388 | 2496 | 2699 | 5 | 3516 | 0.67% | 20.48912 | 15.76 | 49.04 |
Retrieve Identity using UIN | 389893 | 461 | 313 | 994 | 1209 | 1598 | 28 | 2317 | 0.22% | 108.2907 | 187.86 | 233.82 |
Retrieve Identity using VID | 110457 | 325 | 191 | 800 | 914 | 1194 | 12 | 1983 | 0.46% | 30.67593 | 53.14 | 66.42 |
Add Identity (bio) Execution | 15000 | 2868 | 2901 | 3402 | 3750 | 4196 | 140 | 4896 | 26.35% | 3.46978 | 2.48 | 3794.32 |
Update Identity Execution | 20000 | 1269 | 1328 | 1973 | 2276 | 2900 | 14 | 4586 | 3.86% | 7.84082 | 5.57 | 29.07 |
Auth Type Status Execution | 306901 | 586 | 418 | 1198 | 1496 | 1892 | 33 | 2702 | 0.00% | 85.2427 | 53.28 | 226.51 |
Create VID Execution | 77102 | 466 | 302 | 1002 | 1181 | 1513 | 45 | 2271 | 0.48% | 21.41616 | 15.2 | 50.86 |
Update VID Execution | 13950 | 576 | 423 | 1138 | 1282 | 1612 | 0 | 2377 | 0.51% | 17.23997 | 13.23 | 41.26 |
Get Registration Centres API Execution | 21480 | 5030 | 4901 | 7806 | 9098 | 10898 | 253 | 17595 | 0.00% | 5.96056 | 3609.27 | 10.74 |
Get Templates API Execution | 170957 | 1051 | 802 | 2505 | 2992 | 4294 | 4 | 10242 | 0.00% | 47.46712 | 4540.57 | 85.06 |
Get Templates By Lang & Temp Code API Execution | 47241 | 2285 | 2002 | 3885 | 4555 | 5526 | 4 | 9282 | 0.00% | 13.11962 | 16.77 | 23.87 |
Get Latest ID Schema API Execution | 69179 | 2601 | 2501 | 4388 | 5200 | 6573 | 5 | 10700 | 0.00% | 19.20952 | 279.19 | 34.84 |
Get Dynamic Fields API Execution | 55536 | 1944 | 1884 | 2893 | 3098 | 3416 | 14 | 5094 | 0.00% | 15.42405 | 81.76 | 28.45 |
Get Users API Execution | 44399 | 2432 | 2295 | 4196 | 4597 | 5785 | 6 | 9189 | 0.00% | 12.3283 | 9.31 | 22.42 |
Get Registration Centres API Execution | 2281 | 15799 | 15772 | 18399 | 19296 | 21013 | 1904 | 23509 | 0.00% | 0.63243 | 382.95 | 1.14 |
Get Templates API Execution | 93851 | 1149 | 1198 | 2190 | 2533 | 2997 | 4 | 5791 | 0.00% | 26.0657 | 2493.37 | 46.71 |
Get Templates By Lang & Temp Code API Execution | 46088 | 780 | 699 | 1300 | 1403 | 1592 | 4 | 2905 | 0.00% | 12.79908 | 16.36 | 23.29 |
Get Latest ID Schema API Execution | 68743 | 1570 | 1399 | 2694 | 2865 | 3896 | 5 | 5604 | 0.00% | 19.09314 | 277.5 | 34.62 |
Get Dynamic Fields API Execution | 58867 | 611 | 489 | 1113 | 1200 | 1301 | 11 | 1531 | 0.00% | 16.34786 | 86.66 | 30.16 |
Get Users API Execution | 43642 | 824 | 901 | 1320 | 1475 | 1595 | 6 | 2602 | 0.00% | 12.12249 | 9.15 | 22.04 |
Encrypt Data API Execution | 1053790 | 170 | 189 | 287 | 297 | 386 | 6 | 1604 | 0.00% | 292.7122 | 317.26 | 753.15 |
Encrypt Data With Pin API Execution | 10443 | 10346 | 10406 | 13892 | 14705 | 16399 | 1589 | 19495 | 0.00% | 2.89775 | 2.2 | 6.92 |
Generate JWT Signature API Execution | 558466 | 321 | 310 | 437 | 485 | 798 | 14 | 1579 | 0.00% | 155.117 | 417.01 | 392.79 |
Decrypt Data API Execution | 516634 | 348 | 335 | 475 | 528 | 858 | 14 | 1442 | 0.00% | 143.4985 | 93.17 | 428.67 |
Decrypt Data With Pin API Execution | 10349 | 10442 | 10515 | 14208 | 15288 | 17010 | 1704 | 21202 | 0.00% | 2.87069 | 1.86 | 7.13 |
Verify JWT Signature API Execution | 1582654 | 113 | 90 | 209 | 305 | 628 | 3 | 1404 | 0.00% | 439.616 | 297.94 | 1995.87 |
Encrypt Data API Execution | 927329 | 310 | 292 | 583 | 707 | 930 | 6 | 1901 | 0.00% | 257.552 | 279.65 | 662.68 |
Encrypt Data With Pin API Execution | 10361 | 3475 | 3401 | 4305 | 4694 | 5296 | 711 | 6699 | 0.00% | 2.87609 | 2.19 | 6.87 |
Generate JWT Signature API Execution | 521059 | 552 | 531 | 669 | 895 | 1146 | 17 | 2150 | 0.00% | 144.718 | 388.77 | 366.46 |
Decrypt Data API Execution | 488850 | 588 | 549 | 827 | 1051 | 1366 | 15 | 4124 | 0.00% | 135.7712 | 88.16 | 405.59 |
Decrypt Data With Pin API Execution | 10089 | 3568 | 3500 | 4402 | 4699 | 5299 | 1109 | 6497 | 0.00% | 2.80138 | 1.82 | 6.96 |
Verify JWT Signature API Execution | 1214824 | 236 | 95 | 602 | 808 | 1334 | 3 | 2998 | 0.00% | 337.423 | 229.34 | 1531.91 |
PreReg Launch | 2481 | 14 | 6 | 29 | 57 | 151 | 4 | 612 | 0.00% | 0.68942 | 2.5 | 0.34 |
PreReg Send OTP | 2481 | 5400 | 3910 | 12575 | 16399 | 24523 | 34 | 45492 | 0.00% | 0.68841 | 0.48 | 0.29 |
PreReg Validate OTP | 2480 | 3369 | 2189 | 8182 | 11242 | 19216 | 49 | 34813 | 0.00% | 0.68807 | 2.15 | 1.16 |
PreReg Enter Demographic Details And Click Continue | 2473 | 17520 | 15587 | 30322 | 34981 | 45715 | 1175 | 72550 | 0.00% | 0.68645 | 23.3 | 6.15 |
PreReg Upload Documents | 2463 | 7707 | 6095 | 15331 | 18711 | 28729 | 392 | 41042 | 0.00% | 0.68532 | 3.17 | 371.05 |
PreReg Click Continue After Uploading Documents | 2455 | 14692 | 13030 | 26844 | 31673 | 40660 | 243 | 56219 | 0.00% | 0.68426 | 7.93 | 3.53 |
PreReg Preview Document Details And Continue | 2446 | 14298 | 12314 | 25695 | 30528 | 38385 | 1667 | 54085 | 0.00% | 0.68189 | 8.23 | 2.21 |
PreReg Select Center And Continue | 2438 | 3410 | 2213 | 8151 | 10711 | 17372 | 65 | 32880 | 0.00% | 0.68227 | 41.99 | 1.32 |
PreReg Select Slot And Continue | 2438 | 6837 | 5402 | 13687 | 17525 | 25248 | 201 | 38337 | 5.41% | 0.68167 | 4.19 | 2.97 |
PreReg Logout | 2431 | 17 | 11 | 45 | 66 | 84 | 7 | 442 | 0.00% | 0.68089 | 2.45 | 0.87 |
TOTAL | 24586 | 7328 | 4598 | 18901 | 24527 | 35440 | 4 | 72550 | 0.54% | 6.81687 | 95.81 | 388.5 |
PreReg Launch | 2389 | 66 | 9 | 183 | 412 | 707 | 4 | 1084 | 0.00% | 0.66437 | 2.4 | 0.33 |
PreReg Send OTP | 2389 | 8777 | 6358 | 19932 | 25454 | 34345 | 31 | 60013 | 0.08% | 0.66207 | 0.46 | 0.28 |
PreReg Validate OTP | 2385 | 5905 | 4286 | 12937 | 16567 | 28790 | 60 | 46664 | 0.00% | 0.661 | 2.3 | 1.12 |
PreReg Enter Demographic Details And Click Continue | 2381 | 29540 | 26824 | 50104 | 56729 | 70781 | 3687 | 99983 | 0.00% | 0.66017 | 22.78 | 5.89 |
PreReg Upload Documents | 2358 | 13605 | 11462 | 26031 | 32216 | 46567 | 752 | 62849 | 0.04% | 0.6566 | 3.04 | 355.5 |
PreReg Click Continue After Uploading Documents | 2350 | 24769 | 21697 | 42821 | 53048 | 76185 | 764 | 118903 | 0.04% | 0.65785 | 7.62 | 3.39 |
PreReg Preview Document Details And Continue | 2336 | 22505 | 19701 | 39685 | 47397 | 67283 | 1633 | 96086 | 0.13% | 0.65444 | 7.89 | 2.12 |
PreReg Select Center And Continue | 2319 | 5791 | 3802 | 13131 | 18470 | 29293 | 63 | 60365 | 0.04% | 0.65156 | 39.94 | 1.26 |
PreReg Select Slot And Continue | 2316 | 11313 | 9361 | 21756 | 27996 | 39136 | 303 | 61613 | 5.70% | 0.65044 | 3.99 | 2.83 |
PreReg Logout | 2309 | 139 | 25 | 499 | 648 | 986 | 8 | 1387 | 0.00% | 0.65443 | 2.36 | 0.84 |
TOTAL | 23532 | 12254 | 7990 | 30921 | 39493 | 57968 | 4 | 118903 | 0.60% | 6.51774 | 91.88 | 371.52 |
Publish Messages | 605668 | 177 | 173 | 221 | 239 | 295 | 5 | 1759 | 0.00% | 168.2339 | 52.74 | 333.1 |
Publish Messages | 861179 | 208 | 202 | 252 | 270 | 316 | 4 | 2083 | 0.00% | 239.2059 | 74.99 | 473.62 |