Avoid PrincipalName with realm == null

[Weijun Wang]

Hi Henry

We haven't supported the anonymous feature in Java yet.

Anyway, if I read RFC6111/6112 correctly, an anonymous principal name 
uses well-known values in its nameStrings and nameRealm fields, so they 
are still neither null nor empty. This does not conflict with my 
proposal. Also, it seems the KDC (or a service) recognizes the client 
being anonymous mainly by looking at the KDCOptions or TicketFlags, not 
the name itself.

If we want to support anonymous in Java's kerberos, we can make use of 
the current requestAnonymity/getAnonymityState methods. The getSrcName 
method will also return a GSSName whose isAnonymous() might return true. 
The PrincipalName here is a sun.security.* internal class.

Thanks
Max


On 06/08/2012 02:39 AM, Henry B. Hotz wrote:
> Doesn't this interact with the new anonymity standards?
>
> On Jun 6, 2012, at 5:55 PM, Weijun Wang wrote:
>
>> Hi Valerie
>>
>> The krb5 PrincipalName class has a realm field and the class says
>>
>>    If null, means the default realm
>>
>> Ideally this means if the realm of a name is null then this field can be null. Otherwise, it must be filled when created.
>>
>> In fact, inside our codes, the field is often filled (using setRealm()) after it's created. This leads to several strange coding styles that make the codes confusing and error-prone.
>>
>> 1. a lot of setRealm() calls that's far from the creation of the principal name only when the field needs to be used
>> 2. a lot of if (realm == null) checks
>> 3. a lot of "unresolved" names that never has a realm but is definitely not in the default realm (just because the realm field is not used inside JDK)
>>
>> I am planning to fix this to make the PrincipalName immutable and always with a non-null non-empty realm. I also plan to make Realm immutable and remove the ServiceName class (it's quite useless).
>>
>> A brief look into the code and protocol suggests this is quite feasible. In every krb5 message and serialized data (I mean ccache and keytab) defined, there is always a realm beside name. This is also true for most Java methods. And I don't think a name with an "unresolved" realm should exists at all. If we have to deal with something like this, I'd rather invent a new class for it.
>>
>> The code change will be mostly refactoring, removing a lot of realm arguments/fields and merging it into name. One behavior change is that there will be no name with "unresolved" realm anymore, but I think this should never be true in a real production environment. In fact, the public API KerberosPrincipal has
>>
>>      *  @throws IllegalArgumentException if name is improperly
>>      * formatted, if name is null, or if name does not contain
>>      * the realm to use and the default realm is not specified
>>      * in either a Kerberos configuration file or via the
>>      * java.security.krb5.realm system property.
>>
>> What's your suggestion? I've been haunted by this several times, mostly because a setRealm() is not called.
>>
>> Thanks
>> Max
>