On May 29, 2014, at 7:25, Valerie (Yu-Ching) Peng <valerie.p...@oracle.com>
wrote:
>
> AFAIK, this searchSubject utility function is looking for the requested
> GSSCredentialSpi objects (not GSSCredentialImpl object which contains a
> Hashtable of GSSCredentialSpi objects and their keys).
The method returns GSSCredentialSpi but what is stored inside the subject is
GSSCredentialImpl
Iterator<GSSCredentialImpl> iterator =
accSubj.getPrivateCredentials
(GSSCredentialImpl.class).iterator();
Since GSSCredentialImpl is GSSCredential which is public, applications are able
to manipulate them. That's what I am worried about.
>
> When creating the Subject object ourselves, we only convert and stores
> Kerberos-specific creds and ignores non-Kerberos creds (including native GSS
> cred since all we have is native GSS cred handle which can't be converted
> into KerberosKey/Ticket).
>
> However, the app can do whatever they want when constructing their own
> Subject objects. Although I am not sure if any such usage exists.
I'll read more code history to see if there is a convention.
Thanks
Max
>
> Valerie
>
> On 05/27/14 03:50, Wang Weijun wrote:
>> Hi Valerie
>>
>> I am working on breaking JGSS into modules and is now looking at
>> sun/security/jgss/GSSUtil.java. There is a method
>>
>> public static<T extends GSSCredentialSpi> Vector<T>
>> searchSubject(final GSSNameSpi name,
>> final Oid mech,
>> final boolean initiate,
>> final Class<? extends T> credCls) {
>>
>> which goes inside a Subject's priv cred sets looking for GSSCredentialImpl
>> objects. I searched thru other JDK codes and cannot see who is putting those
>> objects there. Do you remember anything? Or we are thinking about
>> applications putting them there? I cannot think of any such convention.
>>
>> In fact, all I can see JAAS/JGSS/krb5 doing with a Subject is putting
>> KerberosPrincipal into princ set and KerberosKey/KerberosTicket/KeyTab into
>> priv cred set. Nothing else.
>>
>> Thanks
>> Max
>>
>
