GSSCredential inside Subject?
Wang Weijun
weijun.wang at oracle.com
Thu May 29 04:22:25 UTC 2014
On May 29, 2014, at 7:25, Valerie (Yu-Ching) Peng <valerie.peng at 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
>>
>
More information about the security-dev
mailing list