The GSS-API does not perform any communication with the peer. It merely
produces tokens that the application must somehow transport to the
other end.
The GSS-API itself does not dictate how an underlying mechanism
obtains the credentials that are needed for authentication. It is
assumed that prior to calling the GSS-API, these credentials are
obtained and stored in a location that the mechanism provider is
aware of. However, the default model in the Java platform will be
that mechanism providers must obtain credentials only from the private
or public credential sets associated with the
{@link javax.security.auth.Subject Subject} in the
current access control context. The Kerberos v5
mechanism will search for the required INITIATE and ACCEPT credentials
({@link javax.security.auth.kerberos.KerberosTicket KerberosTicket} and
{@link javax.security.auth.kerberos.KerberosKey KerberosKey}) in
the private credential set where as some other mechanism might look
in the public set or in both. If the desired credential is not
present in the appropriate sets of the current Subject, the GSS-API
call must fail.
This model has the advantage that credential management
is simple and predictable from the applications point of view. An
application, given the right permissions, can purge the credentials in
the Subject or renew them using standard Java API's. If it purged
the credentials, it would be sure that the JGSS mechanism would fail,
or if it renewed a time based credential it would be sure that a JGSS
mechanism would succeed.
This model does require that a {@link
javax.security.auth.login JAAS login} be performed in order to
authenticate and populate a Subject that the JGSS mechnanism can later
utilize. However, applications have the ability to relax this
restiction by means of a system property:
javax.security.auth.useSubjectCredsOnly. By default
this system property will be assumed to be true (even when
it is unset) indicating that providers must only use the credentials
that are present in the current Subject. However, if this property is
explicitly set to false by the application, then it indicates that
the provider is free to use any credentials cache of its choice. Such
a credential cache might be a disk cache, an in-memory cache, or even
just the current Subject itself.