8:22 a.m.
Thanks Darran and Peter for the insight!
I've just noticed that generating JKS files is one thing but we will also
need to pre-process RealmRepresentation and replace all private/public keys
(like this one for example [1]) with values from keystores/truststores.
At the moment I'm thinking about replacing [1] with something like this:
"jwt.credential.certificate" :
"certificate:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
similarly to private keys (if needed):
"privateKey" :
"private-key:keystore=classpath:keystore.jks,password=password,alias=secure-portal,type=pkcs12"
Later on, while converting JSON to RealmRepresentation I plan to traverse
all nodes and replace replace those which start with private-key or
certificate.
Let me know if you have a better idea.
[1]
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-ar...
On Wed, Jul 25, 2018 at 2:07 PM Peter Skopek <pskopek(a)redhat.com> wrote:
Hi Sebastian,
I think that generation of Keystore on the fly is the only way to go.
You can use Java Keystore API generate it entirely from Java code (no
need to run maven).
Here [1] is an example of utility class used in wildfly testsuite to
generate Vault (basically just keystore).
It will be easy to strip vault related stuff and use it in our testsuite.
Note that there is one more drawback of storing generated JKS files,
which is that in some cases they are not binary compatible between
different JDK (particularly Oracle and IBM).
HTH,
Peter
[1]
https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/...
On Wed, Jul 25, 2018 at 1:23 PM Sebastian Laskawiec <slaskawi(a)redhat.com>
wrote:
>
> Hey,
>
> Together with Sebi we are working on Certificate-based authentication for
> the clients. Our work will require adding at least 2-3 keystores to the
> codebase with different DNs and I think this might be a good opportunity
to
> revisit the way we handle JKS files in the tests.
>
> Currently we push JKS files directly into our repo, which has a couple of
> drawbacks:
> - it is hard to figure out what's inside the JKS, it requires looking up
> for password (usually in some JSON configuration file or hardcoded in the
> test) and using keytool (or some similar one) to explore its content.
> - It is not git-friendly. Every time we update JKS content we effectively
> store another binary file (git doesn't understand binary file changes and
> can not diff it).
> - we use many different naming and password schemes in our tests.
> - it is hard to migrate all keystores to pkcs12 at the same time (JKS
> format is deprecated) [0]
>
> I believe most of the issues could be addressed by generating JKS files
on
> the fly - during the build. In Infinispan we did it with Maven Ant Plugin
> [1]. I already created a very limited POC for Keycloak and you can check
it
> out here [2]. Unfortunately, the process of reverse engineering all those
> files is quite time-consuming, so I would like to know your opinion
before
> moving on.
>
> Of course, generating JKS files on the fly has some drawbacks:
> - It increases build time (~1s per keytool invocation, and we probably
will
> have more than 30 of them).
> - it makes testing from IDE a bit harder, you need to run Maven and
process
> test resources before doing anything. A common workaround is to use `mvn
> clean install -DskipTests` and then opening your IntelliJ.
>
> Please let me know what you think.
>
> Thanks,
> Sebastian
>
> [0]
>
https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to...
> [1]
>
https://github.com/infinispan/infinispan/blob/master/server/integration/t...
> [2] https://github.com/keycloak/keycloak/pull/5410
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev