[Pki-devel] [PATCH] Stand-alone DRM (manual GUI configuration only)
Nathan Kinder
nkinder at redhat.com
Wed Sep 4 15:14:50 UTC 2013
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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
More information about the Pki-devel
mailing list