...
| Warning |
|---|
The primary advantage of this approach is the capability to prevent a rogue KDC from spoofing responses by validating its knowledge of a service principal key configured locally in a keytab file, which is a standard practice for safe use of Kerberos in server-side scenarios. It is STRONGLY urged that this feature be used when possible. |
General Configuration
| Localtabgroupexpand |
|---|
| Localtab live |
|---|
|
Configuring Kerberos as a back-end in the simplest fashion relies on beans defined via an import in authn/password-authn-config.xml: Import in authn/password-authn-config.xml| Code Block |
|---|
| <import resource="krb5-authn-config.xml" /> |
A few beans are defined in this file to globally configure this back-end by setting some Kerberos-related options. With V4, these beans are chiefly used for backward compatibility, and as default settings that can be overridden on specific instances of beans inheriting from shibboleth.KerberosValidator defined in authn/password-authn-config.xml in the shibboleth.authn.Password.Validators bean. In the simple case of a single back-end: Defining use of Kerberos in password-authn-config.xml| Code Block |
|---|
| <util:list id="shibboleth.authn.Password.Validators">
<!-- Default bean uses the settings defined in krb5-authn-config.xml -->
<ref bean="shibboleth.KerberosValidator" />
</util:list> |
| Localtab live |
|---|
|
| active | true |
|---|
| Expand |
|---|
|
Configuring Kerberos as a back-end relies on beans internally that are configured using authn/authn.properties along with the OS-supplied Kerberos configuration. Older releases included an authn/krb5-authn-config.xml file; this remains supported but is no longer required or provided. Adding additional beans may be needed in very advanced cases where a higher degree of control is required, and you are welcome to place them within authn/password-authn-config.xml. In the simple case of a single back-end: Defining use of Kerberos in password-authn-config.xml| Code Block |
|---|
| <util:list id="shibboleth.authn.Password.Validators">
<!-- Default bean uses the settings defined in authn/authn.properties -->
<ref bean="shibboleth.KerberosValidator" />
</util:list> |
|
...
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.
...
.
...
| Expand |
|---|
| title | password-authn-config.xml |
|---|
|
| Code Block |
|---|
| <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
| Localtabgroup |
|---|
localtab-live| Expand |
|---|
|
The beans defined in authn/krb5-authn-config.xml follow. These are defaults that can be overridden per-validator in whole or in part. Bean ID | Type | Default | Description |
|---|
shibboleth.authn.Krb5.RefreshConfig | Boolean | False | Whether to reload the underlying Kerberos configuration (generally in /etc/krb5.conf) on every login attempt | shibboleth.authn.Krb5.PreserveTicket | Boolean | False | Whether to preserve the resulting Kerberos TGT in the Java Subject's private credential set | shibboleth.authn.Krb5.ServicePrincipal | String |
| Name of a service principal to use to verify the KDC supplying the TGT, by requesting and verifying a service ticket issued for it | shibboleth.authn.Krb5.Keytab | Path | | Path to a keytab file containing keys belonging to the service principal defined above |
| Localtab live |
|---|
| active | true
|---|
| Expand |
|---|
|
The following properties are usable in authn/authn.properties to control Kerberos use. These are defaults that can be overridden per-validator in whole or in part. Name | Default | Description |
|---|
idp.authn.Krb5.refreshConfig | false | Whether to reload the underlying Kerberos configuration (generally in /etc/krb5.conf) on every login attempt | idp.authn.Krb5.preserveTicket | false | Whether to preserve the resulting Kerberos TGT in the Java Subject's private credential set | idp.authn.Krb5.servicePrincipal | | Name of a service principal to use to verify the KDC supplying the TGT, by requesting and verifying a service ticket issued for it | idp.authn.Krb5.keytab | | Path to a keytab file containing keys belonging to the service principal defined above |
|