Apache
CXF supports Kerberos for
web services both via the Kerberos Token Profile of WS-Security, where
the kerberos ticket is conveyed as a BinarySecurityToken in the security
header of the client request, and over HTTP via the Negotiate
authentication scheme. If you are developing kerberos-enabled web
services using a framework like Apache CXF, a natural question to ask is how to set up a Kerberos KDC to test your web services prior to deployment. This is the first of two blog posts that shows two different ways to easily set up a KDC using open source projects for kerberos integration testing.
At ApacheCon EU 2014 in Budapest, I attended a great talk by Emmanuel Lécharny entitled "
Testing LDAP Implementations". The talk covered how the Apache
Directory project can be used to easily deploy Kerberos and LDAP servers in your test-code via annotations. This was music to my ears, as I had written a bunch of tests in Apache CXF for both LDAP and kerberos that were not run as part of the normal build, as they required a local KDC to run successfully. After this talk I got involved in the Apache Directory project, and converted the tests in Apache CXF to use Apache Directory instead, so they could be run as part of the normal build cycle. I also made some small improvements which I'll describe as part of this post.
I've created a project in github that shows how to use Apache Directory to set up a KDC, and how to use Apache CXF to authenticate to a web service using Kerberos, for both JAX-RS and JAX-WS:
- cxf-kerberos: This project contains a number of tests that show how to use Kerberos with
Apache CXF.
Both test-cases use an annotation to load a
kerberos.ldif file, containing the information required to set up Kerberos principals in the KDC for testing:
Another annotation sets up the Directory Service:
Finally, an annotation adds a KDC server:
The "KRB" protocol was added as part of
DIRSERVER-2031 in the
2.0.0-M20 release. Previously, you could specify either "TCP" or "UDP" for the protocol attribute when testing Kerberos. However, this meant that they could not share the same port. The "KRB" protocol generates both TCP and UDP transports on the port provided, or otherwise on a random port. Previously, the random port generation was not working, as it always defaulted to 1024. Random port generation is an essential feature for testing as part of a build cycle, as hard-coded ports tend to cause problems on continuous integration platforms. Using a random port also means that the krb5.conf file used by the CXF clients must be read in, and the random port substituted into the file before writing it out again, as otherwise the clients would have no way of knowing the port the KDC was running on.
Have you written tests that use keytab files instead of username/password?
ReplyDeleteAlso, I've retrofitted some very low-level tests to use this approach instead of an external KDC. They're so low-level that they create the GSSContext and LoginContext themselves. Their purpose is solely to verify proper configuration for things like one-way and mutual authentication - it's one less uncertainty when tracking down problems at a higher level.
ReplyDeleteThe external KDC tests work but the ApacheDS test throws a "PortUnreachableException: ICMP Port Unreachable" exception. I've verified that the updatePort() method is being called and I'm running the tests inside of Eclipse.
Any ideas?
You could try either hard-coding the port (both krb5.conf + the Directory annotation), or try running the test via maven to see if it works. Running the tests above in eclipse work fine for me. To answer your first question: no I haven't tried with keytabs.
ReplyDelete