[PATCH] 278 Storing authentication info in session.
by Endi Sukma Dewata
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
10 years, 9 months
[PATCH] Stand-alone DRM (manual GUI configuration only)
by Matthew Harmsen
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.
10 years, 10 months
[PATCH] 298 Added TPS connection resource.
by Endi Sukma Dewata
A skeleton for TPS connection services and the clients have been added.
The service implementation will be added later.
Ticket #652
--
Endi S. Dewata
10 years, 10 months
[PATCH] 297 Reorganized TPS classes.
by Endi Sukma Dewata
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
10 years, 10 months
[PATCH] 147 - provide enrollment template per profile.
by Ade Lee
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
10 years, 10 months
[PATCH] 146 - Add audit logging to the Profile interface.
by Ade Lee
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
10 years, 11 months
[PATCH] 150 fix for revocation reason
by Ade Lee
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
10 years, 11 months
