Package org.ietf.jgss
The GSS-API is defined in a language independent way in RFC 2743. The Java language bindings are defined in RFC 2853
    An application starts out by instantiating a GSSManager
    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.
Credential Acquisition
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 theSubject in the
    current access control context.  The Kerberos v5  
    mechanism will search for the required INITIATE and ACCEPT credentials 
    (KerberosTicket and
     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 JAAS login be performed in order to
    authenticate and populate a Subject that the JGSS mechanism can later 
    utilize. However, applications have the ability to relax this
    restriction 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.
Related Documentation
For an online tutorial on using Java GSS-API, please see Introduction to JAAS and Java GSS-API.
- Since:
- 1.4
- 
Interface Summary Interface Description GSSContext This interface encapsulates the GSS-API security context and provides the security services that are available over the context.GSSCredential This interface encapsulates the GSS-API credentials for an entity.GSSName This interface encapsulates a single GSS-API principal entity.
- 
Class Summary Class Description ChannelBinding This class encapsulates the concept of caller-provided channel binding information.GSSManager This class serves as a factory for other important GSS-API classes and also provides information about the mechanisms that are supported.MessageProp This is a utility class used within the per-message GSSContext methods to convey per-message properties.Oid This class represents Universal Object Identifiers (Oids) and their associated operations.
- 
Exception Summary Exception Description GSSException This exception is thrown whenever a GSS-API error occurs, including any mechanism specific error.