Uploaded image for project: 'EJBCA'
  1. EJBCA
  2. ECA-6514

Create test + pilot export with basic End Entity Profiles export using YAML


    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: EJBCA 6.12.0
    • Component/s: None


      This would be a prototype of the framework + a basic export of some different types of fields, e.g.

      • Username
      • Password
      • Subject DN (use, required, modifyable, validation)
      • Notifications
      • Default CA
      • Available CAs

      Verify using a unit test. The CLI interface will be written in a separate issue.

      Notes from review:

      1. What happened with annotations?
      2. We should make it really, really easy (for me ;) or anyone else) to dump additional objects in ejbca without having to understand how the Configdump project works. Preferably, the workflow could be something like:
          a. Add a new class in the objects namespace implementing the 'ConfigdumpExportable' interface.
          b. Implement the correspoding unit test for this class
          c. Add the new ConfigdumpExportable to a list of exportables in ConfigdumpSessionBean.
      3. How are upgrades in the output format handled? For example, if the format is different between EJBCA 6.12 and EJBCA 6.13 how do we upgrade from the old format to the new format? I don't think this would happen 
      very often since even if we refactor the underlying objects in EJBCA, this won't necessarily affect the output format (which is not the case with old statedump). The only way to handle this (as far as I can tell) without writing 
      an upgrade routine is to upgrade EJBCA itself 
          a Import a dump with the old YAML format into an old EJBCA instance supporting this format
          b Upgrade to new  EJBCA
          c Export the configuration using the new YAML format
      From what I understand, this is not what we want i.e. we need to be able to upgrade an old YAML file to a new one. To do this we would need the following:
          a Metadata which tells Configdump how to handle the two possible cases outlined below
              - A field exists in dump but not in EJBCA
              - A field exists in EJBCA but not in the dump
          Additionally we should consider the case where
              - A field exists twice (violates the YAML spec)
              - A field has an invalid value
              - Fields have an invalid combination of values
              - A YAML object (for example an internal key binding) refers to another YAML object (for example a crypto token) which does not exist
          b A version field telling Configdump which version of the format we're dealing with. This should preferably be defined on file level, to allow a user to mix configuration files from different installations.
         This would only be problem during import, not during export. But if we don't take these things into consideration now, we may have to waste time refactoring later.
      4. How should one YAML object refer to another YAML objects? 
          a By name - they are not guaranteed to be unique in an EJBCA installation
          b By ID (which is not human readable and can cause confusion if a user changes them). Also adds additional implementation complexity if they already exists during import and need to be changed
          c Using YAML anchors, this introduces dependencies e.g. if an internal key binding is exported you also need to export the corresponding crypto token since you'll need to refer to something which exists. Not sure if 
      anchors work if you export into several different files. In that case you would have to merge all files before an import
      Add some missing javadoc before shipping (i.e. can be done later).
      I would prefer to take some classes apart even more, Configdump core could be split into YamlExporter, ConfigdumpConfiguration and ConfigdumpCore where
      YamlExporter is responsible for exporting to YAML (invoking SnakeYAML, creating directory tree and writing files to the correct directories), ConfigdumpConfiguration contains the configuration (e.g. loaded from a YAML file) and 
      ConfigdumpCore contains some functions for mapping between names and ids ect.


          Issue Links



              samuel Samuel Lidén Borell
              samuel Samuel Lidén Borell
              Verified by:
              Bastian Fredriksson
              0 Vote for this issue
              2 Start watching this issue



                  Time Tracking

                  Original Estimate - 3 days Original Estimate - 3 days
                  Remaining Estimate - 0 minutes
                  Time Spent - 3 days, 6 hours, 14 minutes
                  3d 6h 14m