The following patch addresses the installation and configuration of a stand-alone DRM (i. e. - a DRM that exists as the sole subsystem in a PKI deployment -- no corresponding Dogtag CA, and no corresponding Security Domain). Eventually, this DRM will be able to be installed and configured (as a two step process) using nothing more than 'pkispawn' and the REST interface (Phase II). As a preliminary step, this patch allows a stand-alone DRM to be installed using 'pkispawn' and manually configured using the GUI panel interface via a Firefox browser (Phase I). Although this patch only addresses Phase I of a stand-alone DRM, the patch does contain some additional code changes for Phase II, and although incomplete at this time, none of these changes should conflict with existing subsystems. Finally, although this patch only addresses Phase I of configuring a stand-alone DRM, I thought it prudent to send out the existing code changes due to the relatively healthy size of this effort. The attached patch addresses the following TRAC tickets: * https://fedorahosted.org/pki/ticket/667 TRAC Ticket #667 - provide option for ca-less drm install (Phase I) * https://fedorahosted.org/pki/ticket/641 TRAC Ticket #641 - Incorrect interface labels in pkidaemon output * https://fedorahosted.org/pki/ticket/707 TRAC Ticket #707 - Do not "require" the following pkispawn parameters for GUI-based configuration The attached patch has been used to successfully install a Stand-alone DRM using the manual GUI panels. The DRM was installed using the following command: * pkispawn -s KRA -f kra.cfg -vvv where 'kra.cfg' contained the following: * [DEFAULT] pki_admin_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_skip_configuration=True [KRA] pki_standalone=True The DRM was then manually configured from a Firefox browser using the GUI panels where: * this DRM is not part of any security domain, * this DRM's transport, storage, sslserver, and audit_log_signing certificates were all submitted and externally signed by a separate pre-installed Dogtag CA using the appropriate profiles, * a cert request for this DRM's Admin certificate was saved in its CS.cfg to be used later Although I have no tests to verify that this stand-alone DRM functions correctly, the standalone DRM server can be successfully installed, manually configured by the GUI panels, and started: * pkidaemon status tomcat pki-tomcat Status for pki-tomcat: pki-tomcat is running .. [DRM Status Definitions] Unsecure URL = http://dogtag19.example.com:8080/kra/ee/kra Secure Agent URL = https://dogtag19.example.com:8443/kra/agent/kra Secure EE URL = https://dogtag19.example.com:8443/kra/ee/kra Secure Admin URL = https://dogtag19.example.com:8443/kra/services PKI Console Command = pkiconsole https://dogtag19.example.com:8443/kra Tomcat Port = 8005 (for shutdown) [DRM Configuration Definitions] PKI Instance Name: pki-tomcat PKI Subsystem Type: DRM (Stand-alone) Please review this patch, so that Phase I of this effort may be checked-in. _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On 09/04/2013 06:33 AM, Ade Lee wrote: > I realize that we decided that a DRM did not need a security domain, but > after looking at the code, I'm beginning to wonder if we are making > things harder for ourselves by doing it this way. > > The fact is that the very first thing someone is going to ask for, once > this standalone DRM is complete, is for a mechanism to clone the DRM. > We already have a mechanism in place to authenticate to the master > (tokenAuth) so as to copy over all the relevant parameters needed for > cloning. By removing the security domain, we are forcing ourselves to > have to reinvent that entire framework. > > If on the other hand, the KRA or standalone OCSP can host a security > domain, then we can leverage the existing infrastructure to do cloning. > > What is a security domain? > 1. A list of all the subsystems in the domain (stored in ldap) > 2. A list of all the installation sessions and tokens (stored in ldap) > 3. A list of enterprise users (with passwords) (stored in ldap, in > specific groups). > 4. A place where systems get their subsystem certificate issued. > Because all subsystems trust the security domain CA cert as part of the > install, then there are no trust issues when systems communicate with > each other. Recall that the subsystem cert is used for intersystem > communication. > 5. Servlets to get security domain data, get installation tokens, > authenticate installation tokens. > > We can have the standalone KRA host items 1,2,3 and 5 - which makes up > the bulk of the security domain. > > Adding the security domain to the KRA is easy. Basically, you will need > to conditionally add some entries in web.xml, and in > KRAApplicationService.java. We can discuss the details when you get in. > > I realize this invalidates a lot of your patch, but I do believe this is > probably the right way to go. This makes a lot of sense. A standalone KRA that can't be cloned would not be very useful for anything other than testing or development work. Allowing the KRA to be a security domain does sound like the easiest approach. -NGK > > Ade > > > > On Fri, 2013-08-30 at 16:59 -0700, Matthew Harmsen wrote: >> The following patch addresses the installation and configuration of a >> stand-alone DRM (i. e. - a DRM that exists as the sole subsystem in a >> PKI deployment -- no corresponding Dogtag CA, and no corresponding >> Security Domain). Eventually, this DRM will be able to be installed >> and configured (as a two step process) using nothing more than >> 'pkispawn' and the REST interface (Phase II). As a preliminary step, >> this patch allows a stand-alone DRM to be installed using 'pkispawn' >> and manually configured using the GUI panel interface via a Firefox >> browser (Phase I). >> >> Although this patch only addresses Phase I of a stand-alone DRM, the >> patch does contain some additional code changes for Phase II, and >> although incomplete at this time, none of these changes should >> conflict with existing subsystems. >> >> Finally, although this patch only addresses Phase I of configuring a >> stand-alone DRM, I thought it prudent to send out the existing code >> changes due to the relatively healthy size of this effort. >> >> The attached patch addresses the following TRAC tickets: >> * https://fedorahosted.org/pki/ticket/667 TRAC Ticket #667 - >> provide option for ca-less drm install (Phase I) >> * https://fedorahosted.org/pki/ticket/641 TRAC Ticket #641 - >> Incorrect interface labels in pkidaemon output >> * https://fedorahosted.org/pki/ticket/707 TRAC Ticket #707 - Do >> not "require" the following pkispawn parameters for GUI-based >> configuration >> >> The attached patch has been used to successfully install a Stand-alone >> DRM using the manual GUI panels. >> >> >> The DRM was installed using the following command: >> * pkispawn -s KRA -f kra.cfg -vvv >> >> where 'kra.cfg' contained the following: >> >> >> * [DEFAULT] >> pki_admin_password=XXXXXXXX >> pki_client_pkcs12_password=XXXXXXXX >> pki_skip_configuration=True >> [KRA] >> pki_standalone=True >> >> The DRM was then manually configured from a Firefox browser using the >> GUI panels where: >> >> >> * this DRM is not part of any security domain, >> * this DRM's transport, storage, sslserver, and >> audit_log_signing certificates were all submitted and >> externally signed by a separate pre-installed Dogtag CA using >> the appropriate profiles, >> * a cert request for this DRM's Admin certificate was saved in >> its CS.cfg to be used later >> >> Although I have no tests to verify that this stand-alone DRM functions >> correctly, the standalone DRM server can be successfully installed, >> manually configured by the GUI panels, and started: >> >> >> * pkidaemon status tomcat pki-tomcat >> Status for pki-tomcat: pki-tomcat is running .. >> [DRM Status Definitions] >> Unsecure URL = >> http://dogtag19.example.com:8080/kra/ee/kra >> Secure Agent URL = >> https://dogtag19.example.com:8443/kra/agent/kra >> Secure EE URL = >> https://dogtag19.example.com:8443/kra/ee/kra >> Secure Admin URL = >> https://dogtag19.example.com:8443/kra/services >> PKI Console Command = pkiconsole >> https://dogtag19.example.com:8443/kra >> Tomcat Port = 8005 (for shutdown) >> [DRM Configuration Definitions] >> PKI Instance Name: pki-tomcat >> PKI Subsystem Type: DRM (Stand-alone) >> >> Please review this patch, so that Phase I of this effort may be >> checked-in. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel