Dogtag Future Directions

From Dogtag
Jump to: navigation, search

We are going to standardize and simplify the URL scheme for communication with the Dogtag components.

Related Documents

  • REST based interface design for a programmatic interface to dogtag
  • REST/flows Rough flows for standard use cases
  • GITSVN We will be switching over to git, but until we do, the central repo is still Subversion
  • SCEP in IPA SCEP in IPA using the CA and dogtag-RA
  • File:Pki-eclipse.pdfA presentation regarding Eclipse for PKI development.
  • File:Pki-eclipse-tomcat.pdf A presentation on how to run PKI Tomcat in Eclipse.
  • PKI Eclipse Distilling the previous two presentations into a usable How-To


A = Tasks performed up front. B = Milestone 1: January 31, 2011 C = Milestone 2: Summer 2012 D = Prior to GA


We've identified three tracks that while interdependent, can be performed by different team members in parallel. They are:

  1. Code Clean up
  2. Simplification of the installation code and Merging the PKI and IPA directory servers
  3. DRM integration and Key archival

Code Clean Up

In addition, external actors can aid with the creation of a continuous integration process to aid development. A stretch goal is the ability to deploy the IPA PKI instance inside of JBoss, and is discussed at the end. Code Clean Up We've run the Code base through Coverity and is has generated a list of warnings. These overlap with the warnings generated by Eclipse, but there are some additional items. In addition, we should clean as we go. The code does not meet the coding standards. We should review and revise the coding standards. Then, during the course of other work, each of the file should be reformatted to conform to the coding standards. This process can be automated via Eclipse. When submitting a patch, first submit a patch that formats the files IAW with the standard, and then a second patch that implements the functionality desired. All code changes that modify functionality should be accompanied by a unit test. Fix Coverity and Eclipse warnings (A) Review and revise project coding standards (A) Add a project specific code format to Eclipse project (A) Continue to reformat and clean up code (B) All code meets project coding standards (C)


the pkicreate code can be greatly simplified, and in doing so, will make it easier to work with. We've identified a safe series of steps that are each individually valuable. The PKISilent code needs significant cleanup and refactoring. One issue we want to make explicit is that the Server Setup code called by pkisilent changes config files controlled by Tomcat. HTTPD does not allow this, and typically Sysadmins do not want this, but existing customers expect the code to behave as it does now. This needs further discussion .

Simplify pkicreate (B)

  1. no choice of ports or locations (initially two separate instances for CA and DRM )
  2. move CA and DRM into single Tomcat instance if they are deployed on same machine
  3. move to the default tomcat instance - eliminating need for startup scripts.
  4. rewrite remainder in python
  5. Combine IPA and CS databases (C)
  6. deal with issues related to schema conflict, plugin configuration,indexes etc.
  7. initial installation - including initial users to be done by DM
  8. generate pki-DM certificate and change CS to use this certificate to
  9. communicate with the DS on startup
  10. how to create initial users? (admin, IPA agent, IPA DRM agent)
  11. provide CS with config option to use roles/users instead of groups/users

Rework pkisilent (D)

  1. Make IPA specific configuration files
  2. Use IPA/ ldap steps to configure database and replication
  3. Use IPA/ldap steps to configure users
  4. User python written tools to generate certs and do remaining tasks

Programmatic Interface and IPA

Highest priority is supporting the DRM based use cases. As such, we will start a track of development that uses a manual install of the DRM, so that work can be done in parallel to the PKICreate and PKISilent work listed above. The API into the server has evolved over time. Different actions have different approaches. In the interest of simplifying integration and conforming to standards we will standardize a REST style interface.

In order to take advantage of the wisdom embedded in the current code base, the existing APIs will be changed by Refactoring: their behavior will stay the same, but we will revise their internal structure. A good starting point is the ProfileSubmitServlet. The “process” function a couple thousand lines long, and has marshaling, error handling, and multiple business process/use cases all intertwined. The end result of a refactoring of just this piece of code would collect up the error and reporting code in to a common area, a split of the renew code based on “replace conditional with polymorphism”, using a generic routine for the XML marshaling, and so forth. A precondition is a body of unit tests that can be run either in a web or offline manner (we can try both) that confirm that a given refactoring does not break the current functionality.

As part of standardizing the interface, we will make better use of the Java standards around Servlet deployment. The Authentication (AuthN) and Authorization (AuthZ ) code has been implemented directly from the servlet code by calls into the JSS layer. None of the existing Tomcat Realms provide the same mechanism that we need and use. We have the opportunity to extract our approach from our code base and make it easier for people to use JSS with Tomcat in a standardized way. We will create a new implementation of, or potentially a filter, if it provides us with the ability to deploy into multiple containers.

  1. Build Unit tests for the DRM Servlets (A)
  2. Use standard libraries to generate both XML and JSON output from a single code base (A)
  3. Start refactoring of servlet code (A).
  4. Review RESTful interface approach and establish standards (A)
  5. Enable a Tomcat Realm that implements Certificate based authentication IAW standard Tomcat webapps (A)
  6. Extract Authentication code into Tomcat Realm. (B)
  7. Create RPMS for the Jersey components and extend Build system to require/ install them(B)
  8. Provide RESTful external interface for Key archival required by IPA (B)
  9. Refactor the current DRM servlets to extract necessary common components to support Key archival and recovery (B)
  10. Integrate DRM into the IPA install. (B)
  11. Add a Key archival plugin to IPA (B)
  12. Build a set of unit tests around the current DRM interfaces for Key archival and recovery(B)
  13. Build unit tests for all current servlets (C)
  14. Use RESTful API for all Certificate operations required by IPA (C)
  15. Add supported PKCS based formats to REST interface (C)
  16. Provide RESTful external interface for all Subsystems (D)
  17. Replacing all current RPCs with REST APIs (D)
  18. Create a set of REST interfaces for Certificate based operations (C)
  19. Convert IPA to using the REST API for certificate operations. (C)

Continuous Integration and Build

We want to make it possible for people to use Eclipse if they want, but provide as good if not better support for Console based development. As such, everything we do from the GUI should first be done from the command line. In addition, we want to provide feedback of build issues as quickly as possible. Set up continuous integration server such as Hudson(A)

  1. JUnit support in Cmake (A)
  2. Warfile Support in Cmake (B)
  3. Grow the body of automated regression tests for IPA based functionality (B)
  4. Build from one one/smaller subset of SRPMs (B)


As a Java EE App, the difference between deploying in Tomcat and JBoss is minimal. Many applications require certificate management, and have partial implementations of a PKI infrastructure. Examples: RHEV-M, Candlepin/Katello. In addition, we need to be able to deploy IPA on the same server as RHEV-M, if only for demonstration purposes, and the RPM managed Tomcat instance and JBoss managed Servlet engine will be competing for the same ports. Tomcat and JBoss both expect the authentication mechanism to extend the Java security Realm abstract class. NSS backed by LDAP is a powerful Auth mechnism, and should be reusable by other Enterprise applications as well. Splitting this piece out will make it possible to deploy to JBoss, simplify the Tomcat deployments, and produce a path for people to use the PKI components as the foundation for the Authentication mechanism for their own applications, not just the SSL layer.

  1. Packaging and deployment within JBoss (C)

Backward Compatibility

There are different areas and levels of "Backward Compatibility" (BC) that fall under this topic in regards to interoperability of CS subsystems (Dogtag or RHCS) running off difference releases/platforms. As Dogtag development group, we have discussed the following:

  • RHEL v.s. Fedora
  • manual migration v.s. auto-upgrade
  • minor releases v.s. major releases
  • small/easily revertible changes v.s. major/massive changes

and come to agree that we will keep a list of things that are incompatible for each release for the purpose of supporting migration. We will keep a page for each release we work on. On each page, we keep a Migration List and an Incompatibility List. The Incompatibility List is for things we decide to not keep compatible unless absolutely necessary.