| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This will allow users to specify the realm when generating
or archiving a request. No interface change is needed (yet)
because the extra parameter is passed through the request.
Part of Ticket #2041
|
|
|
|
|
|
|
|
|
| |
This patch does the following:
* it adds in the kra request an extra field called "delayLDAPCommit"
* when the request comes in to be processed, it sets this field to "false"
* by default, if this field does not exist, the updateRequest() method will just write to ldap, just like before; however, if this field exists and it contains "true" then it will delay the write
* once the request is processed and all unwanted fields are cleared from the request record, it will set "delayLDAPCommit" to "false", and call updateRequest(), which will then do the actual write to ldap
* In addition, I also screened through both KRA and TPS code and removed debug messages that contain those fields.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket # 1597
Currently, KRA allows sites to opt for doing encryption/decryption instead of
wrapping/unwrapping for key archival and recovery.
The new cli code was later added without such support. We should honor the
same flags when cli is called to do key archival and recovery.
This feature was due to a specific customer request.
Here is what is now supported:
1. When the pki cli tool is used to recover a asymmetric private key,
support is there to do so with encrypt / decrypt.
2. The passphrase and generic data facility already uses
encrypt / decrypt so nothing here was needed. Calling it out since
this will possibly be a customer issue.
3. While under the hood, it made sense to add this functionality to the
Symmetric key archival and recovery operations.
4. All tests in DRMTest.java worked successfully when the kra was
configured to support this feature and configured to not observe this feature.
What is missing:
We have since added a method to do a server side key generation of an
asymmetric key pair in the kra and also archive it there at the same time.
In order to do encrypt / decrypt in this case we need to extract the key
contents out of a key object that is used to generate this key. It proved
problematic to extract said key. This should be ok since the customer only
needs to recover an asymmetric key in their test cases. We could look into
doing this later if a pressing need arises.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keys archived through the KRA connector in CA have null data type
attribute which causes a NPE during retrieval using the key-retrieve
CLI. The SecurityDataRecoveryService has been modified to consider
null data type attribute as asymmetric key type.
The KeyRetrieveCLI and KeyService have been modified to generate
better debugging messages to help troubleshooting.
https://fedorahosted.org/pki/ticket/1481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the 2nd phase of the externalReg feature, it makes the
following improvements:
* added feature: recovery by keyid (v.s. by cert)
* fixed some auditing message errors
* added some missing ldapStringAttributes needed for delegation to work
properly
* added missing externalReg required config parameters
* made corrections to some externalReg related parameters to allow
delegation to work properly
* added handle of some error cases
* made sure externalReg enrollment does not go half-way (once fails,
bails out)
tested:
* enrollment of the three default TPS profiles (tokenTypes)
* format of the tokens enrolled with the three default tps profiles
* delegation enrollments
* cuid match check
next phase:
* cert/key retention (allow preserving existing certs/keys on the token)
note:
* some of the activity log and cert status related issues that are not
specifically relating to externalReg will be addressed in other more
relevant tickets.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds methods to key client to generate asymmetric keys using
algorithms RSA and DSA for a valid key sizes of 512, 1024, 2048,4096.
The generated keys are archived in the database.
Using the CLI, the public key(base64 encoded) can be retrieved by using
the key-show command.
The private key(base64 encoded) can be retrieved using the key-retrieve
command.
Ticket #1023
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the new security data storage and retrieval, and for symmetric
key generation, we need to store the identity of the agent that is
requesting and approving each operation, both in the ldap record
and in the audit logs. (Tickets 806 and 807)
This patch also adds required logic to check that the owner of the
recovery request is the same agent that retrieves the key. It also
adds missing audit log constants for symmmetric key generation so that
they will show up in the audit log.
|
|
|
|
|
|
|
|
| |
The REST service classes have been moved into org.dogtagpki.server
namespace. A new upgrade script has been added to update existing
instances.
Ticket #114
|
| |
|
|
|
|
|
|
| |
With this patch, you can now either send a pkiArchiveOptions object
or the exploded parameters. This reduces the processing required on
the client side.
|
|
|
|
|
|
|
|
|
| |
1) Added error checking in python client calls.
2) Allow symmetric key generation with default params. Fix bug for
when usages is not defined.
3) Fix bug when requesting key recovery - must check if key exists.
4) Extend key gen to allow for providing trans_wrapped_session_key
5) added constants to python client for key status
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the archival, recovery and generation code for symmetric keys,
we use functions that require knowledge of the symmetric keys algorithm
and key size. These were hardcoded to DES3, and so only DES3 worked.
We added those parameters to the archival request, save them in the
KeyRecord and retrive them when recovering the key.
Tests have been added to DRMTest for the relevant usages.
|
|
|
|
|
|
|
|
|
| |
1. Remove Link attribute from ResourceMessage,
2. Rename KeyDataInfo and KeyDataInfoCollection.
3. Move KEYGEN_ALGORITHMS
4. Fix missing space in PKIException
5. Move properties to attributes in ResourceMessage
6. Add missing code to update the request and set IRequest.RESULT
|
|
|
|
|
|
| |
Refactor ResourceMessage to include classname instead of Request Type.
Also changed PKIException.Data to extend ResourceMessage.
Modifications to the server code to get the tests working.
|
| |
|
| |
|
|
|
|
|
|
| |
TPS-rewrite effort):
http://pki.fedoraproject.org/wiki/TPS_-_New_Recovery_Option:_External_Registration_DS
|
|
|
|
|
|
|
|
|
|
| |
New ACL has been added to allow only the administrators to access
TPS authenticators.
The set of interceptors in each application has been modified to
preserve the order.
Ticket #652
|
|
|
|
|
|
|
| |
Due to a regression RESTEasy is unable to find some sub-resources properly.
As a workaround some resources need to be merged into the parent resource.
The UserCertResource and UserMembershipResource have been merged into
UserResource. The GroupMemberResource has been merged into GroupResource.
|
|
|
|
| |
* TRAC Ticket #667 - provide option for ca-less drm install
|
|
|
|
|
|
|
| |
A new REST service and clients have been added to manage the audit
configuration in all subsystems.
Ticket #652
|
|
|
|
|
|
|
| |
New REST service and clients have been added for managing selftests
in all subsystems.
Ticket #652
|
|
|
|
| |
Ticket 97
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch provides basic support for DRM Transport Key Rotation described
in http://pki.fedoraproject.org/wiki/DRM_Transport_Key_Rotation
This patch provides implementation for tickets:
- 729 - CA to include transport certificate when submitting archival request to DRM
- 730 - DRM to detect presence of transport certificate attribute in submitted archival
request and validate transport certificate against DRM's transport key list
- 731 - DRM to provide handling for alternative transport key based on detected
and validated transport certificate arriving as a part of extended archival request
|
|
|
|
|
|
| |
The ACLInterceptor and AuthMethodInterceptor interceptors only run
on the server, so they have been moved from the base package into
the server package.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new mechanism has been added to specify the authentication methods that
can be used to invoke the REST methods. The AuthMethodMapping annotation
maps each REST method to a list of allowed authentication methods. When a
client calls a REST method, the AuthMethodInterceptor will intercept the
call and verify that the client uses an allowed authentication method.
Most REST methods that require authentication have been configured to
require client certificate authentication. Authentication using username
and password will only be used to get the installation token from security
domain.
Ticket #477
|
|
|
|
|
|
|
|
| |
New CLI's have been added to search, add, and remove user membership.
The group member management code has been refactored into a processor
to allow reuse.
Ticket #190
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously ACL checking was done in PKIRealm by matching the URL.
This code has been replaced by ACLInterceptor which will intercept
RESTEasy method invocations. This allows more precise mapping of
REST methods to ACL entries in acl.ldif.
Ticket #287
|
|
|
|
|
|
|
|
|
| |
A REST account service has been added to allow client to login
to establish a session and to logout to destroy the session. This
way multiple operations can be executed using the same session
without having to re-authenticate.
Ticket #357
|
| |
|
|
|
|
| |
recovering, wrapping unwrapping keys should be done in the token
|
|
|
|
| |
TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The shutdown() methods in several classes have been fixed to allow
more graceful shutdown and clean restart. There are two types of
object attributes that need to be handled differently.
Attributes that are initialized by the constructor should not be
nulled during shutdown because they won't be reinitialized during
restart. If they require a cleanup (e.g. emptying collections,
closing LDAP connections) it's not necessary to check for null
before calling the cleanup method because they're never null.
For attributes that are initialized during init(), it may not be
necessary to do a cleanup or null the attribute since they might
still be used by other threads and they will be reinitialized
during restart so the old objects will be garbage collected. If
they do need a cleanup they should be checked for null because
they might still be null due to init() failure or initialization
conditionals.
If the attributes are initialized conditionally, the logic has been
modified to ensure the attributes are either initialized or set to
null.
Ticket #247
|
|
|
|
|
|
|
| |
The common classes used by REST client and services have been moved
into the com.netscape.certsrv.<component> packages.
Ticket #215
|
|
|
|
|
|
|
| |
The REST common classes have been renamed for better clarity
and consistency.
Ticket #259
|
|
|
|
|
|
|
| |
The REST server classes have been renamed for better clarity
and consistency.
Ticket #259
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|