code review request: 6894072: always refresh keytab

[Valerie (Yu-Ching) Peng]

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