Avoid PrincipalName with realm == null

[Henry B. Hotz]

Thanks for checking.  I was remembering some early discussion of possibilities that obviously didn't make it to the final version.

I'm also wrestling with an oddball application that stores some data in the ccache with a principal name without a realm.  The data isn't a ticket though, so that's really completely off the reservation.  ;-)

On Jun 7, 2012, at 7:53 PM, Weijun Wang wrote:

> 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
>>