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

Christina Fu cfu at redhat.com
Wed Sep 4 17:13:05 UTC 2013


I'm sorry if I have missed the announcement, but where is the design for 
stand-alone DRM?  Is it okay if I take a look?

thanks,
Christina


On 09/04/2013 08:14 AM, Nathan Kinder wrote:
> 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
>
> _______________________________________________
> 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