8:33 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel