August 2013 - Pki-devel - Dogtag PKI List Archives

[PATCH] 278 Storing authentication info in session.
by Endi Sukma Dewata 11 Oct '13

11 Oct '13

The authenticator configuration has been modified to store the authentication info in the session so it can be used by other servlets. An update script has been added to update the configuration in existing instances. The SSLAuthenticatorWithFalback was modified to propagate the configuration to the actual authenticator handling the request. -- Endi S. Dewata

1 2

[PATCH] Stand-alone DRM (manual GUI configuration only)
by Matthew Harmsen 04 Sep '13

04 Sep '13

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.

4 3

Design page for automation of shared secret generation between TKS and TPS
by Ade Lee 03 Sep '13

03 Sep '13

Hey guys, As requested by cfu, I've written up how we plan to change how the TKS-TPS shared secret is generated and shared. The design is here: http://pki.fedoraproject.org/wiki/Automated_generation_of_Shared_Secret Please review and provide comments. Thanks, Ade

2 1

[PATCH] 299 Added TPS authenticator resource.
by Endi Sukma Dewata 03 Sep '13

03 Sep '13

A skeleton for TPS authenticator services and the clients have been added. The service implementation will be added later. Ticket #652 -- Endi S. Dewata

2 2

[PATCH] 298 Added TPS connection resource.
by Endi Sukma Dewata 03 Sep '13

03 Sep '13

A skeleton for TPS connection services and the clients have been added. The service implementation will be added later. Ticket #652 -- Endi S. Dewata

2 3

[PATCH] 297 Reorganized TPS classes.
by Endi Sukma Dewata 03 Sep '13

03 Sep '13

The TPS classes have been reorganized as follows: * common: com.netscape.certsrv.tps * CLI: com.netscape.cmstools.tps * server: org.dogtagpki.server.tps TPSConnection and TPSMessage were moved from server package into common package. The build script and configuration files have been modified accordingly. -- Endi S. Dewata

2 2

[PATCH] 147 - provide enrollment template per profile.
by Ade Lee 03 Sep '13

03 Sep '13

This patch adds an API call to the ProfileService interface to obtain an enrollment template for a particular profile. The template is simply a CertEnrollmentRequest with the relevant inputs for the profile filled in. The user would then need to simply enter the relevant values and submit the request using the REST API cert-request-submit. I think that someone who is using this interface would do one of two things: 1. Manually edit the template to generate the request. 2. Write client code to add the relevant data to the CertEnrollmentRequest object. In fact, I plan to submit a patch that will extend the pki CLI to allow you to enter the data for a request interactively or through command line arguments. It would go something like this: 1. pki cert-request-submit --profile caCertUser 2. CLI will contact Profile service and get the relevant template which is a CertEnrollmentRequest object. 3. CLI will then iterate through the attributes (which are all uniquely named) and prompt for their value. The descriptor metadata can be used to help generate the prompt. 4. CLI will take these results, populate the CertEnrollmentRequest and send to server. 5. CLI can also take an invocation that looks like this perhaps: pki cert-request-submit --profile caCertUser --profileArgs [--sn_e alee(a)redhat.com --sn_cn "Ade Lee" ... ] so that you can do it all on the command line. Please review. Ade

1 1

[PATCH] 146 - Add audit logging to the Profile interface.
by Ade Lee 03 Sep '13

03 Sep '13

This patch adds audit logging to the profile interface. I used the same logging categories (scope, op, id, messages) as for the old interface. More needs to be added - in particular, when an input, output or policy is added, modified or removed, the details of the attributes in that object should probably be logged, rather than just the id's. I'll fix this in a subsequent patch. A comprehensive review of the audit logs will likely be done when we do common criteria testing. Please review. Ade

2 2

[PATCH] 148 - Move status marker from CS.cfg to a variable
by Ade Lee 03 Sep '13

03 Sep '13

This patch moves the cs.status marker to a variable in CMSEngine.java instead, so that we are not writing/reading to CS.cfg on startup. Please review. Ade

1 1

[PATCH] 150 fix for revocation reason
by Ade Lee 03 Sep '13

03 Sep '13

Fixed filter code for revocationReason Filter was incorrectly setting ldap query to revocationReason* resulting in a reach for revocationReason 1 returning 1 and 10 Ticket 712 Please review. Ade

1 2