We are going to standardize and simplify the URL scheme for communication with the Dogtag components.
Overview#
We’ve identified three tracks that while interdependent, can be performed by different team members in parallel. They are:
Code Clean up
Simplification of the installation code and Merging the PKI and IPA directory servers
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)
Installation: PKICREATE and PKISILENT#
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 .
no choice of ports or locations (initially two separate instances for CA and DRM )
move CA and DRM into single Tomcat instance if they are deployed on same machine
move to the default tomcat instance - eliminating need for startup scripts.
rewrite remainder in python
Combine IPA and CS databases (C)
deal with issues related to schema conflict, plugin configuration,indexes etc.
initial installation - including initial users to be done by DM
generate pki-DM certificate and change CS to use this certificate to
communicate with the DS on startup
how to create initial users? (admin, IPA agent, IPA DRM agent)
provide CS with config option to use roles/users instead of groups/users
Make IPA specific configuration files
Use IPA/ ldap steps to configure database and replication
Use IPA/ldap steps to configure users
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 javax.security.Realm, or potentially a filter, if it provides us with the ability to deploy into multiple containers.
Build Unit tests for the DRM Servlets (A)
Use standard libraries to generate both XML and JSON output from a single code base (A)
Start refactoring of servlet code (A).
Review RESTful interface approach and establish standards (A)
Enable a Tomcat Realm that implements Certificate based authentication IAW standard Tomcat webapps (A)
Extract Authentication code into Tomcat Realm. (B)
Create RPMS for the Jersey components and extend Build system to require/ install them(B)
Provide RESTful external interface for Key archival required by IPA (B)
Refactor the current DRM servlets to extract necessary common components to support Key archival and recovery (B)
Integrate DRM into the IPA install. (B)
Add a Key archival plugin to IPA (B)
Build a set of unit tests around the current DRM interfaces for Key archival and recovery(B)
Build unit tests for all current servlets (C)
Use RESTful API for all Certificate operations required by IPA (C)
Add supported PKCS based formats to REST interface (C)
Provide RESTful external interface for all Subsystems (D)
Replacing all current RPCs with REST APIs (D)
Create a set of REST interfaces for Certificate based operations (C)
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)
JUnit support in Cmake (A)
Warfile Support in Cmake (B)
Grow the body of automated regression tests for IPA based functionality (B)
Build from one one/smaller subset of SRPMs (B)
JBoss#
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.
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.