Details
-
Type:
Epic
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: EJBCA 6.12.0
-
Component/s: None
-
Labels:None
-
Epic Name:Implement UnidFnr as a module
Description
Background:
Fnr is Norway's equivalent to the Swedish personnummer. We currently support a custom built OCSP extension, which can be activated through ocsp.properties. Fnr is in the current implementation stored in an external datasource, which is handled by EJBCA outside of the EJB context.
Customer Requirements
Customer has requested that the UnidFnr table be given row protection functionality in the same way as other tables in EJBCA.
PrimeKey Requirements
Handling database communication outside of EJB is not good practice, and this is a good chance to stop doing so.
- Defining OCSP extensions in configuration files is outdated and should no longer be done. Instead extensions should exist as a result of plugins being present. This would also allow this extension (and future OCSP extensions) to be used on the Appliance.
- The extension, if present, should be activated in the OcspKeybinding in the UI
- We do not want to re-implement row protection in the current hack, rather we should implement the database object as an extension of ProtectedData
- Naturally, EJBCA should work seamlessly if the extension is not present
- The extension module should be Enterprise only.
Deadline
This feature needs to be implemented before the end of Q1
Questions and Answers:
Q: Will customer be continuing use of a current table?
A: No, customer will be filling the UnidFnr table anew, so we're not in anyway dependent on the legacy design.
Q: Do we need to import the data ourselves?
A: Nope, customer will be doing so for us, and signing it.
Q: Do we need to connect to an external database?
A: Yes, it'll be handled in an external database.