| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
The escapeDN() has been renamed into escapeRDNValue() for better
clarity.
Ticket #193
|
|
|
|
| |
Ticket 314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We create a user that can be used to connect to the database using the
subsystem cert for client auth. We identified this user, using the seeAlso
attribute and provided certmap rules to this effect.
For this user, we used to reuse the uid = user CA-hostname-port, which is already
created for inter-system communication. But this is problematic if more than one
dbuser exists, as the directory server may bind as the incorrect user. In any
replication topology, there must be only one dbuser using the subsystem cert.
To simplify things, we create a new user specifically for this purpose
(pkidbuser), and we remove the seeAlso attribute from the older dbusers.
A script is needed to convert existing dogtag 9 istances to use the new user,
and set the relevant acls. This will be done in a separate commit.
|
|
|
|
|
|
|
| |
The UGSubsystem has been modified to escape values used in DN or
filter according to LDAP standard.
Ticket #193
|
|
|
|
| |
internal db in cert status thread.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CMS engine is a singleton and it's used by PKI realm to authenticate
users accessing the subsystem. Since a Tomcat instance may contain
multiple subsystems, each having separate realm, the PKI JAR links
need to be moved into WEB-INF/lib so that they will run inside
separate class loaders.
Tomcat also requires that the authenticator and realm classes be
available in common/lib. To address this a new package pki-tomcat.jar
has been added. The package contains the authenticator and a proxy
realm. When the subsystems start running, they will register their
own realms into the proxy realms such that the authentications will
be forwarded to the appropriate subsystems.
Ticket #89
|
|
|
|
| |
This allow server to come up with DS where anon binds are turned off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 PKI JNDI realm has been modified to utilize the authentication
and authorization subsystems in PKI engine directly. It's no longer
necessary to define the LDAP connection settings in Tomcat's
configuration files.
Ticket #126
|
|
|
|
|
|
|
|
| |
A custom Tomcat authenticator has been added to authenticate users
using client certificate if provided, otherwise it will fallback to
BASIC/FORM authentication.
Ticket #107
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Integration of Tomcat 7
* Introduction of dependency upon tomcatjss 7.0
* Removal of http filtering configuration mechanisms
* Introduction of additional slot substitution to
support revised filesystem layout
* Addition of 'pkiuser' uid:gid creation methods
* Inclusion of per instance '*.profile' files
* Introduction of configurable 'configurationRoot'
parameter
* Introduction of default configuration of 'log4j'
mechanism (alee)
* Modify web.xml to use new Application classes to
bootstrap servers (alee)
* Introduction of "Wrapper" logic to support
Tomcat 6 --> Tomcat 7 API change (jmagne)
* Added jython helper function to allow attaching
a remote java debugger (e. g. - eclipse)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Coverity fix for Forward NULL cases in DogTag 10.
|
|
|
|
| |
Addressed review coments.
|
|
|
|
|
|
|
|
|
|
| |
Generally the user LDAP entry does not contain a seeAlso attribute
unless it's a special database user. The UGSubsystem.removeUserCert()
would fail because it tried to remove the seeAlso attribute. Now the
code has been fixed to remove the seeAlso using a separate modify
operation and ignore the error if it fails due to missing attribute.
Ticket #182
|
| |
|
| |
|
|
|
|
| |
REVERSE_INULL,Wrong_Map_Iterators
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The group REST service is based on UsrGrpAdminServlet. It provides an interface
to manage groups and group members.
Ticket #160
|
|
|
|
|
|
|
| |
The user REST service is based on UsrGrpAdminServlet. It provides an interface
to manage users and user certificates.
Ticket #160
|
|
|
|
|
|
|
|
|
| |
A new Auditor service has been added to replace the audit service that was
previously only available to subclasses of AdminServlet. The new service
can be used by other components including REST services. The AdminServlet
will be modified to use the Auditor service separately.
Ticket #160
|
| |
|
|
|
|
| |
FB.SBSC_USE_STRINGBUFFER_CONCATENATION --Remaining
|
| |
|
|
|
|
| |
FB.DM_STRING_CTOR, FB.DM_STRING_VOID_CTOR
|
| |
|
| |
|
|
|
|
|
|
| |
Currently the realm only returns the last acl result in a multiple entry ACL. Since most of them only have one entry, this is mistly ok. This simple fix allows the code to handle multiple entries correctly.
Ticket #123.
|
|
|
|
|
|
|
| |
The Thread.stop() is deprecated, so the key status update thread is now
implemented with executor service to allow stopping the task gracefully.
Ticket #3
|
|
|
|
|
|
|
| |
Most of unused private fields have been removed because they generate
warnings in Eclipse. Some are kept because it might be useful later.
Ticket #139
|
|
|
|
|
|
| |
Unnecessary type casts have been removed using Eclipse Quick Fix.
Ticket #134
|
|
|
|
|
|
|
|
| |
Whitespaces in Java code have been removed with the following command:
find . -not -path .git -name *.java -exec sed -i 's/[[:blank:]]\+$//' {} \;
Ticket #134
|
|
|
|
|
|
|
| |
The VLV control can be obtained directly from the list of response
controls by checking its type.
Ticket #3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the ECC plan and the different phases, please refer to
http://pki.fedoraproject.org/wiki/ECC_in_Dogtag
Design for each phase is on the same wiki page.
Note: the designs beyond phase 2 were more like a brain dump. Although I said
"Do Not Review," you are free to take a peak at what's intended down the road.
I will go back and take a closer look and refine/adjust the designs when I
begin implementation for each new phase.
What you need to know:
* Problem 1 - nethsm issue:
On the server side, if you turn on FIPS mode, in addition to nethsm, you need
to attach certicom as well to have ECC SSL working on the server side. This
problem has already been reported to Thales last year and they said they'd look
into putting the item on their next release. Recently through a different
contact, we learned there might be a way to "turn it on" (still waiting for
their further instruction)
* Problem 2- Certicom issue:
This is a show-stopper for deployment. Initially, on the client side, I used Kai's special
version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF
requests can be generated with key archival option. However, I encountered
(or, re-encountered) an issue with certicom token. Certicom generates ECC keys
with the wrong format (not PKCS7 conforming), which makes ECC key archival
impossible on the server side if you use non-certicom token with DRM (but we
expect an HSM in most product deployment). I have contacted Certicom for this
issue, and they confirmed that they indeed have such issue. We are hoping they will fix it.
But then you might ask, "I thought I saw some ECC enrollment
profiles/javascripts being checked in? How were the tests done?" The tests for
those profiles were done against this ECC key archival/recovery DRM prototype I
implemented last year (needs to be turned on manually in 8.1), where I
"cheated" (yeah, that's why it's called a prototype) by decrypting the private
key in the CRMF on DRM, and then manipulating the byte array to strip off the
offending bytes before archival.
In the real, non-prototype implementation, which is what's in this patch, for
security reasons, private keys are unwrapped directly onto the token during key
archival, so there is no way to manipulate the keys in memory and bypass the
Certicom issue.
A word about Kai's special version of Xulrunner/Firefox. It is not yet
publicly available (due out in Firefox 10.0.4 on RHEL 5.8).
* Problem 3- Firefox with nethsm issue:
Another option was to connect Kai's special version firefox with an HSM to test
my DRM/JSS code. However, for whatever reason, I could not get SSL going
between such Firefox and ECC CA ( I did not try very hard though, as I have one
other option -- writing my own ECC CRMF generation tool. I might come back to
try the nethsm Firefox idea later)
My solution (how I work on this official implementation):
* I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current
releases), gutting out the RSA part of the code, and replacing it with ECC
code. I call it CRMFPopClientEC. Two types of ECC key pairs could be
generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I
don't know if you can select which type to generate in the Javascript... maybe
you can, I just don't know). I'm in no way condoning archival of signing
keys!! This is just a test tool.
This tool takes a curve name as option (along with others), generates an ECC
key pair, crafts up an CRMF request with key archival option, and sends request
directly to the specified CA. You will see a "Deferred" message in the HTML
response (see attachment for example)
Once CA agent approves the request, the archival request goes to DRM and the
user private key is archived.
For recovery, DRM agent selects key recovery, etc, and you get your pkcs12.
I did some sanity test with the pkcs12 recovered:
* Import the recovered pkcs12 into a certicom library:
pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12
I also tested by retrieving a p12, importing it into a browser, and adding the
user as an agent and the user could act as agent via ssl client auth to the CA.
Finally, much of the RSA-centric code had been cleared out of the way at the
time when I worked on the DRM ECC prototype, so you don't see much of that in
this round.
How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up
with a nethsm (like I did), or write your own tool, you can't really test it
until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to
work with ceriticom, although you would run into the same issue I mentioned
above)
|
|
|
|
|
|
|
| |
The deprecated authenticate() method in LDAPConnection has been
replaced with another authenticate() method with different signature.
Ticket #3
|
|
|
|
|
|
|
| |
The deprecated getAlgorithmId() method in AlgorithmId has been replaced
with get().
Ticket #3
|