Description of problem: Using Kerberos authentication in following code results in NullPointerException Api api = new ApiBuilder() .url("https://engine_url:443/api") .kerberos(true) .noHostVerification(true) .build(); System.out.println("Authentication successful"); api.shutdown(); The problem occurs after successful login to engine while building the api. Using username and password for authentication work fine. See also bug 1145237. Version-Release number of selected component (if applicable): ovirt-engine-sdk-java-3.6.0.0-0.12.20150623.gite9a4212.fc20.noarch How reproducible: 100% Steps to Reproduce: 1. set your environment as described in RFE from description 2. Use code from description Actual results: NullPointerException Expected results: Successful run
The NPE was cause by content of /etc/krb5.conf file where two domains end with the same string. After leaving only the needed realm there is no NPE anymore. The issue now is that the SDK asks for Kerberos credentials interactively. After entering them the authentication is ok and everything works as it should.
Apparently what is happening in your environment is that the Java virtual machine doesn't support the AES cipher with 256 bits keys. That is the algorithm used by the TGT that was in the credentials cache (18 corresponds to AES with 256 bits keys): >>>DEBUG <CCacheInputStream> key type: 18 >>> unsupported key type found the default TGT: 18 But then apparently the Java virtual machine that you are using doesn't support it, only 17, 16 and 23: Using builtin default etypes for default_tkt_enctypes default etypes for default_tkt_enctypes: 17 16 23. For some reason the AES 256 algorithm is disabled in your environment. As far as I know this used to be an issue when the Unlimited Strength Jurisdiction Policy Files of the JRE aren't installed, but in Fedora 20 (I think you are using that OS) these files are installed by default. I'd suggest you to check the integrity of the package that provides those files: # rpm -ql java-1.7.0-openjdk-headless | grep policy.jar # rpm -V java-1.7.0-openjdk-headless If you really need to run with the limited stregth policy files then you can disable the strong algorithms in the Kerberos client configuration file krb5.conf, for example: [libdefaults] ... default_tgs_enctypes = aes128-cts-hmac-sha1-96 des3-cbc-sha1-kd rc4-hmac default_tkt_enctypes = aes128-cts-hmac-sha1-96 des3-cbc-sha1-kd rc4-hmac This should avoid the use of the strong algorithm which isn't apparently supported. Anyhow, in this situation the SDK shouldn't ask interactively to the user, it should just throw an exception, that needs to be fixed.
I can confirm now that using the Oracle JDK 7 instead of OpenJDK 7 causes this issue. The reason is that the Oracle JDK ships with the restricted strength policy files and OpenJDK ships with the unrestricted strength ones. If you still need or want to use the Oracle JDK you will need to install the unrestricted strenth policy files, available from Oracle here: http://download.oracle.com/otn-pub/java/jce/7/UnlimitedJCEPolicyJDK7.zip As I wrote in the previous comment we will change the SDK so that in this case it throws an exception instead of asking interactively to the user.
The component that is requesting the Kerberos user name and password interactively is the Krb5LoginModule, which is part of the Kerberos implementation of the Java virtual machine. To disable this the "doNotPrompt" parameter has to be added to the jaas.conf file. So it should look like this: ---8<--- com.sun.security.jgss.login { com.sun.security.auth.module.Krb5LoginModule required client=true useTicketCache=true doNotPrompt=true; }; com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required client=true useTicketCache=true doNotPrompt=true; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required client=true useTicketCache=true doNotPrompt=true; }; --->8--- I'm documenting this in bug 1145237, so that it will be added to the release notes. In addition to that the SDK needs to be modified in order to avoid NPEs when authentication fails. The way to do that is to register the athentication schemes only when the caller has provided the relevant configuration: sdk: Register only relevant auth schemes https://gerrit.ovirt.org/43764
Verified on rhevm-sdk-java-javadoc-3.6.0.0-0.15.20150623gite9a4212.el6ev.noarch
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one.