KerberosAuthnConfiguration

Current File(s): conf/authn/password-authn-config.xml, conf/authn/krb5-authn-config.xml (V4.0), conf/authn/authn.properties (V4.1+)

Format: Native Spring, Properties, Kerberos

Overview

This CredentialValidator back-end for the password authentication login flow uses the Kerberos library built into Java for password-based authentication instead of using the JAAS module that traditionally wraps those calls.

General Configuration

If desired, it's possible to directly configure the various settings within the validator bean instead of or in addition to relying on the defaults. Refer to the KerberosCredentialValidator javadoc for a complete summary, along with the example below.

Kerberos Configuration

The actual Kerberos library configuration is managed in a conf or ini file that can be placed in a number of different locations. On non-Windows servers, using a system-wide configuration in /etc/krb5.conf is generally advised. It's possible to have Java-specific configurations and/or provide the path to a configuration using a system property. Refer to the Java documentation for details.

It is of critical concern that you consider the impact of foreign realm usage. Operating the Java Kerberos client in its default configuration without including a service principal is inherently dangerous because Java defaults to locating foreign realm KDCs via DNS. Therefore you MUST do one of the following to prevent inadvertent access by principals in realms other than your own:

1. Set dns_lookup_kdc = false in the [libdefaults] section of the Kerberos configuration file.

2. Supply a service principal and keytab to ensure that the IdP shares a key with the KDC that responds to it.

It is also possible to implement rules within the IdP controlling the permissible usernames, but these are workarounds at best and one of the above is more strongly recommended.

Examples

Chaining Validators

One complication of chaining Kerberos KDCs together is that the overall realm configuration is global to Java, so you can't just have separate krb5.conf files in each case. That means you have to manipulate the user's input to ensure that the values will be explicitly realm-qualified.

Under the assumption that principal names in the two realms are unique (without which, things get much more complex and dangerous obviously), something like this would allow chaining of the two. The example considers two realms, "FOO.EXAMPLE.ORG" and "BAR.EXAMPLE.ORG", and the transforms applied strip the username if it's entered in the form of an email address before appending the realm.

password-authn-config.xml

<util:list id="shibboleth.authn.Password.Validators">
	<!-- Default bean uses the settings defined in authn/authn.properties -->
    <ref bean="custom.KerberosValidatorFoo" />
    <ref bean="custom.KerberosValidatorBar" />
</util:list>

<bean id="custom.KerberosValidatorFoo" parent="shibboleth.KerberosValidator"
		p:keytabPath="%{idp.home}/credentials/foo.keytab" p:servicePrincipal="HTTP/idp.example.org">
    <property name="transforms">
    	<list>
        	<bean parent="shibboleth.Pair" p:first="^(.+)@example\.org$" p:second="$1" />
        	<bean parent="shibboleth.Pair" p:first="^(.+)$" p:second="$1@FOO.EXAMPLE.ORG" />
    	</list>
    </property>
</bean>

<bean id="custom.KerberosValidatorBar" parent="shibboleth.KerberosValidator"
		p:keytabPath="%{idp.home}/credentials/bar.keytab" p:servicePrincipal="HTTP/idp.example.org">
    <property name="transforms">
    	<list>
        	<bean parent="shibboleth.Pair" p:first="^(.+)@example\.org$" p:second="$1" />
        	<bean parent="shibboleth.Pair" p:first="^(.+)$" p:second="$1@BAR.EXAMPLE.ORG" />
    	</list>
    </property>
</bean>

Reference