-
Enhancement
-
Resolution: Not an Issue
-
P4
-
None
-
8u45
-
generic
-
generic
A DESCRIPTION OF THE REQUEST :
The current implementation of the Krb5LoginModule uses System properties and a shared single Krb5.conf file that maps the current hostname/domain to a realm. There can only be one Kerberos Realm configured per JVM at a time.
JUSTIFICATION :
This is an unnecessary restriction. If you have a multi-threaded service written in Java that supports multiple Realms which are not in a cross realm trust then you must serialize access to the Krb5LoginModule when changing configuration as the one configuration is shared. There are lots of environments with multiple realms, especially mixed realms such as one Microsoft Active Directory for Windows machines and one MIT Kerberos KDC for Linux machines. If using SPNEGO for example it is desirable for a web application to support users from either realm. This is given that cross realm trusts aren't desired / possible, perhaps because administrators don't want full realm trust (just web applications can share auth).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You can create multiple independent and concurrent Krb5LoginModule contexts / configurations for a single JVM.
ACTUAL -
You can only have one Kerberos configuration and realm at a time.
CUSTOMER SUBMITTED WORKAROUND :
You can create multiple independent applications (JVM instances) - one for each realm. This doesn't work well with SPNEGO web applications as you would have to have multiple application server instances. Another alternative is to use cross-realm trusts. This is not always desirable though as it means all services now must trust the other realm. Finally, another option is to pick one of the realms and tell users in the other realm they are out of luck (sorry).
The current implementation of the Krb5LoginModule uses System properties and a shared single Krb5.conf file that maps the current hostname/domain to a realm. There can only be one Kerberos Realm configured per JVM at a time.
JUSTIFICATION :
This is an unnecessary restriction. If you have a multi-threaded service written in Java that supports multiple Realms which are not in a cross realm trust then you must serialize access to the Krb5LoginModule when changing configuration as the one configuration is shared. There are lots of environments with multiple realms, especially mixed realms such as one Microsoft Active Directory for Windows machines and one MIT Kerberos KDC for Linux machines. If using SPNEGO for example it is desirable for a web application to support users from either realm. This is given that cross realm trusts aren't desired / possible, perhaps because administrators don't want full realm trust (just web applications can share auth).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You can create multiple independent and concurrent Krb5LoginModule contexts / configurations for a single JVM.
ACTUAL -
You can only have one Kerberos configuration and realm at a time.
CUSTOMER SUBMITTED WORKAROUND :
You can create multiple independent applications (JVM instances) - one for each realm. This doesn't work well with SPNEGO web applications as you would have to have multiple application server instances. Another alternative is to use cross-realm trusts. This is not always desirable though as it means all services now must trust the other realm. Finally, another option is to pick one of the realms and tell users in the other realm they are out of luck (sorry).