Avoid PrincipalName with realm == null

[Weijun Wang]

On 06/08/2012 02:09 PM, Henry B. Hotz wrote:
> 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.  ;-)

I've met something similar, at the realm field is a string 
"X-CACHECONF:". We have to skip that entry.

In fact, how can one tell if a principal inside a ccache has or hasn't a 
realm? It's just an array of strings there. Who knows if the first one 
is for realm or the first component?

-Max


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