CLI for editing profiles
by Fraser Tweedale
Along with LDAP profiles, we will be adding modules to the CLI for
adding and editing profiles in the ConfigStore format that was used
for file-based profiles. For more info, see:
http://pki.fedoraproject.org/wiki/LDAP_Profile_Storage#Command-line_utili...
There is an existing CLI for adding and modifying profiles, in the
XML format, e.g. ``pki ca profile add caCustomProfile.xml``. The
XML format carries information including the profile ID and
class_id, but these data must be supplied out-of-band when dealing
with the ConfigStore format.
Because of this, I intend to:
- add new commands to the existing profile CLI for working with the
"raw" (i.e., ConfigStore) format, e.g. "edit-raw", "add-raw".
Where necessary, these commands will take compulsory
``--profile-id`` and/or ``--class-id`` arguments, to account for
the absense of such information in the profile ConfigStore format;
and
- transport this information in the XML format - not in the "raw"
format - so that it will be unnecessary to make changes to
ProfileClient or the ProfileService API.
As usual, I welcome feedback - especially if you feel I am going the
wrong way ^_^
9 years, 3 months
ProfileSubsystem configuration with LDAPConnection
by Fraser Tweedale
With the introduction of LDAP-based profiles, the ProfileSubsystem
needs access to the profile configuration. When spawning a new
instance, the CMS tries to start its subsystems, but the
ProfileSubsystem cannot start because it requires the LDAP
connection details, which are not yet configured (this action is
performed by SystemConfigService.configureDatabase).
OK, so what to do? I see two options:
1) Remove the profile subsystem from the initial CS.cfg, so that it
doesn't start up. Add it back into CS.cfg as a configuration step;
on the next startup, it will run and be happy, because the database
configuration is there.
2) Handle the absense of database configuration in ProfileSubsystem
itself. That is, keep track of whether initialisation has been
successfully performed, and try again "just-in-time" when it is
needed. This probably violates semantics of the IProfileSubsystem
API.
Feedback or other ideas are appreciated. I'm going to push ahead
with option (1). Both options feel like hacks but (2) seems like a
worse hack ^_^
Cheers,
Fraser
9 years, 11 months
[PATCH] first cut of tokendb management, policy, and activities
by Christina Fu
This patch is the first cut of tokendb management, policy, and
activities. It
* adds and updates token entries in the tokendb
* checks policies when necessarily (note: bug filed:
https://fedorahosted.org/pki/ticket/1085
* logs activities
Certificate related tokendb updates will be in the next patch. There may
still be a few more activities to be logged (such as pin reset, etc,
once complete.). Policy checks re ticket#1085 will be provided after
ticket 1085 is addressed.
Please review.
thanks,
Christina
9 years, 11 months
[PATCH] Fix independent pkispawn installation and configuration
by Matthew Harmsen
Please review the following attached patch which addresses:
* PKI TRAC Ticket #905 - 2 Step Configuration of CA instance using
pkispawn fails <https://fedorahosted.org/pki/ticket/905>
This was tested by first "installing" a CA using the following command:
* *pkispawn -s CA -f ca-gui-install.cfg -vvv*
where 'ca-gui-install.cfg' contained the following:
[DEFAULT]
pki_admin_password=<password>
pki_client_pkcs12_password=<password>
pki_skip_configuration=True
Then, the CA was 'configured' by running the following command:
* *pkispawn -s CA -f ca-gui-config.cfg -vvv*
where 'ca-gui-config.cfg' contained the following:
[DEFAULT]
pki_admin_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
pki_security_domain_password=<password>
pki_client_database_purge=False
pki_skip_installation=True
9 years, 12 months
[pki-devel][PATCH] 0016-Implement-Symmetric-Key-Changeover-Feature.patch
by John Magne
[PATCH] Implement Symmetric Key Changeover Feature
1. Created code to actually change the key over to a new key set.
2. Made calls to the code from the format and enrollment operations,
the Pin Reset processor will do so when completed.
3. Tested with real card. Was able to change to key set #2 and then back to stock
Ticket #878.
10 years
[pki-devel][PATCH] 0015-First-cut-of-enrollment-feature.patch
by John Magne
First cut of enrollment feature.
The following features implemented for enrollment.
1. Standard enrollment of a list of RSA certificates.
2. Certificates are only done with token side keygen.
3. Minimual enrollment based pin reset functionality implemented to create
a pin for the enrolled token.
4. Much work done to the PKCS11 object code, which allows us to write the
compressed object blob to the token, allowing coolkey to access it and use
the certs and keys on the token.
5. Tested with Bob Relyea's "smartcard" utility to prove that signing and encryption
operations worked as expected.
6. Some work done to get authentication working with esc.
7. Created of stub of standalone Pin Reset Processor. Now it returns an error from
esc but the pin reset command is accepted.
To Do.
1. We need to support server side keygen.
2. Symmetric Key Changeover in another ticket.
3. Finish up the stand alone Pin Reset Processor in another ticket.
10 years
[PATCH] pki-cfu-0020-TPSRewrite-credential-match-fix.patch
by Christina Fu
This patch is to fix an issue that Jack reported some time ago regarding
authentication in Java TPS.
It was speculated that it had to do with ESC and tpsclient not expecting
same credential names, etc.
(note: I understand that Jack worked out something that was to get him
through what he was working on, but it was not meant as a permanent
solution, hence my investigation and separate patch)
I spent some time investigating to find out the root cause and a final
solution.
Here is what I discovered:
In the old TPS, in case of "ExtendedLoginRequest", the uid/pwd are
called "UID" and "PASSWORD";
where as in case of "LoginRequest", the uid/pwd are called "screen_name"
and "password"
In tpsclient, BOTH "ExtendedLoginResponse" and "LoginResponse" are coded
to put "screen_name". My suspicion is with the old TPS the
"ExtendedLoginRequest" never worked.
So, in summary, it's the difference between "extended" and "not
extended" rather than the clients. The clients just happened to specify
extended/not extended by default so it appears that way.
Note: In this patch, I added changes to tpsclient in an attempt to make
extendedLogin work but I learned later from jack that tpsclient never
does that, so please ignore that part of the patch. I made some attempt
to restore that part of tpsclient with a new patch but couldn't get it.
I will sort it out with our git experts later.
This works with tpsclient, but I am still waiting for jack to test it
out with ESC.
thanks,
Christina
10 years
