Re: [Pki-devel] [PATCH] Stand-alone DRM (manual GUI configuration only)

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