Package org.ietf.jgss

Contents
This package presents a framework that allows application developers to make use of security services like authentication, data integrity and data confidentiality from a variety of underlying security mechanisms like Kerberos, using a unified API.

See: Description

  • 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.

      

Package org.ietf.jgss Description

This package presents a framework that allows application developers to make use of security services like authentication, data integrity and data confidentiality from a variety of underlying security mechanisms like Kerberos, using a unified API. The security mechanisms that an application can chose to use are identified with unique object identifiers. One example of such a mechanism is the Kerberos v5 GSS-API mechanism (object identifier 1.2.840.113554.1.2.2). This mechanism is available through the default instance of the GSSManager class.

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 the Subject 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 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

Document created the 11/06/2005, last modified the 04/03/2020
Source of the printed document:https://www.gaudry.be/en/java-api-rf-org/ietf/jgss/package-summary.html

The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.

References

  1. View the html document Language of the document:fr Manuel PHP : https://docs.oracle.com

These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.

Contents Haut