Set Cruz

Jeffrey, what I would do is just rename the new jks file from jetty's import tool (which I'm not familiar with) and give it the name of the keystore with the invalid key pair.

Mark, I would declare my remote to take a Principal argument, and intercept the call to authenticate/authorize.

I haven't used it. I have no plans to try it out.

Let me share my opinion as to why. I understand that the raw API's are not convenient, but I'm not sure that adding a level of abstraction is best. The documentation keyczar link promises to select algorithm recipes that are "safe " for the developer. Without further looking into keyczar, I would warn that such "safety" is a dynamic quantity, subject to research trends and discoveries. For instance, SHA1 fell out of favor after collisions had been discovered by researchers. At best, a developer would have to depend on the keyczar release cycle to bring their code to the next level of safety in such an event. At worst, a vulnerability discovered today will simply go unnoticed in an abstracted API.

I've read this and I see a vulnerability. I wonder if trust establishment is less of an issue in the context of a custom class loader.

Hi -
I'd like to see the documentation where you read this, would you please provide a link?

Hi
"What are providers?"
Read this from the Security FAQs

Hi -
A text search on "keystore" yielded the following thread, which may be relevant keystore discussion

Hi -
What I'd do is figure out all the jar files involved in the stack for the setSystemProperty() call in Syfact.java line 67, and make sure that I give relevant permissions to code in all those jar files.

If I had to outline the steps for JBoss/Tomcat:
- SSL enable your port with client authentication turned on in server.xml
- Alternatively, configure your web.xml with a <login-config> element and <auth-method>CLIENT-CERT</auth-method>
-Create a JBoss callback handler class that implements org.jboss.security.CertificatePrincipal
-Declare your callback handler class in the "certificatePrincipal" attribute of the "Realm" element in server.xml

You'll notice that CertificatePrincipal will pass in the certificate chain in an array X509Certificate[].

- call getSubjectDN() on the relevant X509Certificate
- use the String API to capture the CN

Cheers

I was hoping you'd say your app server is JBoss/Tomcat. Does Websphere allow you to configure authorization realms where you can declare a callback handler where the cert chain is passed in?

Imagine somebody wants to exploit your system. They may hijack your query for a user certificate and return a fairly large binary query result. But you are not validating or verifying so you max out the "storage space", card, etc. From then on, depending on your system, of which I'm just barely learning some details, you may have an availability problem.

Hi -
I'm assuming:

1) "get hold of client certificate" = read a cert into memory
2) "extract the 'Common Name'" = parse the distinguished name

I'm not familiar with the Entrust API. I don't know whether you need it.

To answer #1, which application server are you using?

To answer #2, once you have a certificate chain in memory, preferably in an array of X509Certificate objects, call getSubjectDN() on the X509 object and use the String API to locate the CN.

Cheers.

I suggest you validate and verify certificate chains. What do you plan to do with the certificates once you retrieve them?

I understand there is a proverbial "chicken and egg" problem here, if I'm reading your design correctly. To address this, your application may support a collection of certificate authorities, and you may iterate through that collection until one of them returns a certificate chain. If your search returns no certificates then the user interface may ask the user which certificate authority holds their certificate.

By far the most manageable way to get a certificate chain from a user, however, is to SSL enable the connection to your site.

Hi -
I would call (or email) VeriSign and explain that you user has stored their certificate with them and that you'd like to do an LDAP lookup of this certificate using an email address.
Cheers