|GSSContext||This interface encapsulates the GSS-API security context and provides the security services that are available over the context.||code | html|
|GSSCredential||This interface encapsulates the GSS-API credentials for an entity.||code | html|
|GSSName||This interface encapsulates a single GSS-API principal entity.||code | html|
|GSSManager||This class serves as a factory for other important GSS-API classes and also provides information about the mechanisms that are supported.||code | html|
|ChannelBinding||This class encapsulates the concept of caller-provided channel binding information.||code | html|
|GSSException||This exception is thrown whenever a GSS-API error occurs, including any mechanism specific error.||code | html|
|MessageProp||This is a utility class used within the per-message GSSContext
methods to convey per-message properties.
When used with the GSSContext interface's wrap and getMIC methods, an instance of this class is used to indicate the desired Quality-of-Protection (QOP) and to request if confidentiality services are to be applied to caller supplied data (wrap only).
|code | html|
|Oid||This class represents Universal Object Identifiers (Oids) and their
Oids are hierarchically globally-interpretable identifiers used within the GSS-API framework to identify mechanisms and name formats.
The structure and encoding of Oids is defined in ISOIEC-8824 and ISOIEC-8825.
|code | html|
An application starts out by instantiating a
which then serves as a factory for a security context. An application
can use specific principal names and credentials that are also created
using the GSSManager; or it can instantiate a
context with system defaults. It then goes through a context
establishment loop. Once a context is established with the
peer, authentication is complete. Data protection such as integrity
and confidentiality can then be obtained from this context.
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.
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 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.
For an online tutorial on using Java GSS-API, please see Introduction to JAAS and Java GSS-API.@since 1.4