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

Wed Sep 4 13:33:17 UTC 2013

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.

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