You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Countries can customise the countryconfig /event-registration endpoint in order to customise the BRN. Tonga wish their BRN to be incremental - A sequence. (001, 002, 003...) and they wish to do this by searching the OpenCRVS database in the /event-registration endpoint.
The IET team advised the SI to have a database in country config where they could store each BRN as it is created, then they could search this DB in order to increment the next one. We advised that this DB would have to be persistent and backed up. A volume could be created that the countryconfig container has access to via docker-compose and the back up and restore of that DB could be configured independently by editing the backup/restore scripts.
But the SI found it easier to use the Registar's JWT to search existing records using the Record Search API rather than create the database.
Recently, in this PR, the token that is used to communicate with the /event-registration endpoint has been refactored so that it only has scope necessary for the MOSIP integration. It appears logical but now restricts this SI to have to do one of the following:
1: Implement the database approach as previously recommended
2. Create a system client that is able to perform a record search. Save the client_id and client_secret as Github secret env vars in the relevant Github environment and send them to the countryconfig microservice in docker-compose for the environment. Then you can authenticate as a record search client using that token in order to search core in /event-registration.
Pitch
We understand that all record searches of OpenCRVS must be audited. We are looking for any recommendations on how to proceed. Would it be possible to add any other scopes to the token or would that be a bad idea from a security stand point.
We understand that other countries have implemented incremental BRNs and wonder how their approaches may or may not be affected.
Which feature of OpenCRVS your enhancement concern?
/evnt-registration customisable API for customising the BRN
To understand the problem
Login as a Registrar and register an event
In the /event-registration endpoint attempt to use the Record Search API using the token received in the headers. Notice that it fails.
OpenCRVS Core Version:
v1.7.0 (Git branch: release-v1.1.0)
Country Configuration Version:
v1.7.0 (Git branch: release-v1.7.0)
The text was updated successfully, but these errors were encountered:
euanmillar
changed the title
The Single Record Token introduced for MOSIP integration comms with event-registration doesnt provide enough scope to countries
The Single Record Token introduced for MOSIP integration comms with event-registration may not provide enough scope to countries
Feb 25, 2025
Describe the improvement
Countries can customise the countryconfig /event-registration endpoint in order to customise the BRN. Tonga wish their BRN to be incremental - A sequence. (001, 002, 003...) and they wish to do this by searching the OpenCRVS database in the /event-registration endpoint.
The IET team advised the SI to have a database in country config where they could store each BRN as it is created, then they could search this DB in order to increment the next one. We advised that this DB would have to be persistent and backed up. A volume could be created that the countryconfig container has access to via docker-compose and the back up and restore of that DB could be configured independently by editing the backup/restore scripts.
But the SI found it easier to use the Registar's JWT to search existing records using the Record Search API rather than create the database.
Recently, in this PR, the token that is used to communicate with the /event-registration endpoint has been refactored so that it only has scope necessary for the MOSIP integration. It appears logical but now restricts this SI to have to do one of the following:
1: Implement the database approach as previously recommended
2. Create a system client that is able to perform a record search. Save the client_id and client_secret as Github secret env vars in the relevant Github environment and send them to the countryconfig microservice in docker-compose for the environment. Then you can authenticate as a record search client using that token in order to search core in /event-registration.
Pitch
We understand that all record searches of OpenCRVS must be audited. We are looking for any recommendations on how to proceed. Would it be possible to add any other scopes to the token or would that be a bad idea from a security stand point.
We understand that other countries have implemented incremental BRNs and wonder how their approaches may or may not be affected.
Which feature of OpenCRVS your enhancement concern?
/evnt-registration customisable API for customising the BRN
To understand the problem
OpenCRVS Core Version:
Country Configuration Version:
The text was updated successfully, but these errors were encountered: