code review request: 6894072: always refresh keytab

[Weijun Wang]

Hi Valerie

Sorry for the late reply. I've considered some alternatives.

A "to-be-resolved" KerberosKey is quite difficult. When it's resolved, 
we have a list of keys with different etypes as the private credentials. 
If it's not resolved, we can only create one, whose encoding and etype 
are both unresolved, and when it finally gets resolved, it's resolved 
into multiple keys. Also, there was a simple mapping between KerberosKey 
and EncryptionKey. The resolving process is not always at the same time 
as the mapping (converting from one to another) time, so it seems 
EncryptionKey might also needs to be unresolved.

Another solution is to revert back to my original KeyTab without an 
intended user. This means several changes:

In my latest version of ServiceCreds, there were multiple keys and *one* 
keytab, now we also need multiple keytabs, because there might be 
multiple keytabs in the subject's private credentials set and we cannot 
tell which is for who. Therefore we collect all of them, when the keys 
are needed at AP-REP time, we call getKeys() on all of them, and return 
the combination. Hopefully there won't be two keys for the same 
principal with same kvno and same etype. I regard that as an abuse.

Currently when there is no serverPrincipal specified in the 
Krb5AcceptCredential construction, we pick a KerberosKey from the 
private credentials set and use the KerberosPrincipal info inside, and 
then get all KerberosKeys for the same principal. We have never really 
looked at any KerberosPrincipal objects in the subject's principal set. 
I had tried to do the same to KeyTabs in my webrev.02. Now this will 
have a big change: the first step is always finding a KerberosPrincipal 
in the principal sets first. If serverPrincipal is specified, we find a 
matched one, otherwise, we just pick one and use it. And then, from the 
private credentials set, we fetch all KerberosKeys for this principal 
and all KeyTabs.

I think this is the correct way to go. Of course, for compatibility 
reason, we assume there are third party codes that put KerberosKeys 
inside a subject's private credentials set but hasn't put any 
KerberosPrincipal there. Our Krb5LoginModule will never do it, but we 
can accept it.

Here is a partial webrev:

http://cr.openjdk.java.net/~weijun/6894072/webrev.03

It only contains changes for Krb5Util.java, and hasn't included the 
compatibility codes I mentioned above. As you can see, the KeyTab 
objects are now retrieved by

+            sc.ktabs = SubjectComber.findMany(
+                        subj, null, null, KeyTab.class);

so no principal name is used, and we retrive "many".

If you think this is OK, I'll clean up other codes. One benefit is that 
we don't need to update CCC with this solution. Yes we do introduce new 
hashCode/equals/toString methods, but I think they do not deserve a CCC.

Thanks
Max


On 03/26/2011 08:20 AM, Valerie (Yu-Ching) Peng wrote:
> Max,
>
> Well, I find it a bit awkward that the KeyTab class has to have the
> KerberosPrincipal info which "intends" to use it.
> Have you considered a different approach like:
> Instead of adding the whole KeyTab object into the Subject's private
> credential set, we add a "to-be-resolved" KerberosKey object. When we
> need to use this kind of key, we'd check the associated KeyTab object to
> re-fresh its value if needed. This approach is conceptually closer to
> what we had and the changes aren't as dramatic and seems to meet the
> need required by 6894072.
>
> I'll continue to review your webrev, but just want to kick this idea off
> w/ you and see if it may work.
> Valerie
>
> On 03/23/11 02:00 AM, Weijun Wang wrote:
>> Hi Valerie
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~weijun/6894072/webrev.02
>>
>> Changes since last version:
>>
>> 1. A KerberosPrincipal inside javax..KeyTab class. New getInstance()
>> arguments, new getPrincipal() method.
>>
>> It can only be non-null now, but I didn't say anything in the spec.
>> I'm hoping it can be null in the future to support multiple service
>> principal in a single service.
>>
>> 2. toString(), hashCode(), equals() for KeyTab, since it will be put
>> inside private credentials set.
>>
>> 3. Enhancement to SubjectComber:
>> a) Generics for find() and findMany()
>> b) findAux() now support Krb5AcceptCredential
>>
>> 4. Krb5Util.ServiceCreds: since principal is already inside both
>> KeyTab and KerberosKey, no more KerberosPrincipal argument in
>> getInstance(), there is still a field inside to save the value.
>>
>> 5. sun..KeyTab and javax..KeyTab: isMissing==true is now valid.
>> Changes to the javadoc of javax..KeyTab.getKeys().
>>
>> 6. New TwoPrinces.java test, a subject with 2 KerberosPrincipal after
>> JAAS commit.
>>
>> This time I'd like to first make sure implementation is correct, and
>> then I'll update the CCC. Is this OK?
>>
>> Thanks
>> Max
>