Elytron and Kerberos using gssproxy
02 Jan 2018This tutorial describes how to configure WildFly to use Elytron to use gssproxy for Kerberos authentication.
WARNING: The GS2-* SASL mechanisms will not work with native Kerberos in latest Oracle JDK (JKD8u121 and upstream JDK9). There is patch for OpenJDK (jkalina-openjdk-native-gss.patch), but it is going to be merged into JDK 11 in November 2018. (see OpenJDK mailing list)
Testing environment
For needs of this tutorial you can use simple Kerberos server and keytab generator by Josef Cacek:
Generate keytab file both.keytab
(which will contain key for both, remoting and HTTP) to be used by gssproxy for WildFly:
Lets start testing Kerberos server:
Gssproxy
Prepare following gssproxy.conf
and keytab both.keytab
in directory readable only by root:
The gssproxy.conf
file:
Note: Even through only krb5
is supported in mechs
, this does not affect possibility to use gssproxy for SPNEGO authentication.
Configuring WildFly to use Kerberos
Start the WildFly server with following parameters:
The *.debug
properties should be omitted in production environment.
As the gssproxy will be used, there is no need to configure java.security.krb5.conf
property.
The path
to the keytab in kerberos-security-factory
will not be used when native Kerberos is enabled, but this property is currently required, so let dummy.keytab
here for now:
Now can be required mechanisms added into authentication factory:
As Kerberos provides authentication only, in practical deployment this would be done in combination with obtaining users from LDAP. Check Kerberos tutorial to configure it.
In this tutorial this will be simplified by using predefined properties-realm
. You need to ensure users exists in appropriate security realm - add them into mgmt-users.properties
:
Enabling Elytron for management authentication
To use authentication factories above we need to switch to them from legacy security realms:
(http-upgrade defines parameters for using SASL in HTTP connections)
Simple workaround for JDK bug
In latest Oracle JDK and OpenJDK there is bug JDK-8194073, which needs to be workarounded if you get messages like following:
GSSException: Provider SunNativeGSS does not support mechanism 1.2.840.113554.1.2.2
To resolve, enable workaround implemented in Elytron - set wildfly.sasl.gssapi.server.create-name-gss-init to true for GSSAPI SASL server or org.wildfly.security.http.create-name-gss-init for SPNEGO HTTP mechanism:
Just note that this workaround workarounds JDK-8194073 only, which will allow you to use SASL GSSAPI and HTTP SPNEGO mechanisms. To use GS2-* SASL mechanism you need to apply OpenJDK patch for JDK-8194630 mentioned in the top of this tutorial. (GS2 mechanism requires channel binding, which is broken for native Kerberos otherwise.)
Testing using CLI or Firefox
At first use kinit
to log-in:
Now you can run :whoami
command, authenticated using Kerberos:
Firefox
In about:config set network.negotiate-auth.trusted-uris to contain localhost - individual hostnames needs to be delimited by comma AND space - for example:
Run Firefox with KRB5_CONFIG property set:
(In this tutorial we has setup gssproxy only for server-side - Firefox still needs krb5.conf
)
Because the SPNEGO is now last in order, you need to press Cancel to cancel BASIC/DIGEST authentication. Now you should be logged into the management console as hnelson@JBOSS.ORG.
Getting debug output
We can specify property to enable Kerberos debug in Oracle JDK:
Trace messages from Elytron and from remoting will be also useful:
Add following to the JAVA_OPTS
to obtain debug messages of the Kerberos from Oracle JDK:
(Some properties needs to be set on start of the JVM - are ignored when set in standalone.xml
)
To get debug output from gssproxy add following into gssproxy section:
Often error messages
No server entry found for kerberos principal name HTTP/127.0.0.1@JBOSS.ORG
You are accessing the WildFly server from browser by different hostname (127.0.0.1) then for which kerberos account exists (localhost).
KrbException: Fail to create credential. (63) - No service creds
Probably wrong mapping of hostname to realm in [domain_realm]
section of krb5.conf
- or wrong path to krb5.conf
on client.
GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
Probably property javax.security.auth.useSubjectCredsOnly
not set to false
while trying to use local-kerberos
credential.
GSSException: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm)
Wrong path to the krb5.conf
file.
Config file(s) not found!
Invalid path to the gssproxy.conf
when starting gssproxy, OR invalid content of the file.
Key table file ‘/root/both.keytab # the keytab’ not found
Remove comments after end of the line in gssproxy.conf - are not supported correctly by gssproxy.
Encryption type not permitted
Add non-weak encryption type into krb5.conf, into default_tgs_enctypes
and default_tkt_enctypes
- for example aes128-cts-hmac-sha1-96
.