IBM® JGSS application programming steps

There are multiple steps required to develop a JGSS application, including using transport tokens, creating the necessary JGSS objects, establishing and deleting context, and using per-message services.

Operations in a JGSS application follow the Generic Security Service Application Programming Interface (GSS-API) operational model. For information about concepts important to JGSS operations, see JGSS concepts.

JGSS transport tokens

Some of the important JGSS operations generate tokens in the form of Java™ byte arrays. It is the responsibility of the application to forward the tokens from one JGSS peer to the other. JGSS does not constrain in any way the protocol that the application uses for transporting tokens. Applications may transport JGSS tokens together with other application (that is, non-JGSS) data. However, JGSS operations accept and use only JGSS-specific tokens.

Sequence of operations in a JGSS application

JGSS operations require certain programming constructs that you must use in the order listed below. Each of the steps applies to both the initiator and the acceptor.

Note: The information includes snippets of example code that illustrate using the high-level JGSS APIs and assume that your application imports the org.ietf.jgss package. Although many of the high-level APIs are overloaded, the snippets show only the most commonly used forms of those methods. Of course, use the API mehods that best suit your needs.
  1. Creating a GSSManager

    An instance of GSSManager acts as a factory for creating other JGSS object instances.

  2. Creating a GSSName

    A GSSName represents the identity of a JGSS principal. Some JGSS operations can locate and use a default principal when you specify a null GSSName.

  3. Creating a GSSCredential

    A GSSCredential embodies the mechanism-specific credentials of the principal.

  4. Creating a GSSContext

    A GSSContext is used for context establishment and subsequent per-message services.

  5. Selecting optional services on the context

    Your application must explicitly request optional services, such as mutual authentication.

  6. Establishing context

    The initiator authenticates itself to the acceptor. However, when requesting mutual authentication, the acceptor in turn authenticates itself to the initiator.

  7. Using per-message services

    The initiator and the acceptor exchange secure messages over the established context.

  8. Deleting context

    The application deletes a context that is no longer needed.

  1. Creating a GSSManager
    The GSSManager abstract class serves as a factory for creating JGSS objects.
  2. Creating a GSSName
    GSSName represents the identity of a GSS-API principal. A GSSName may contain many representations of the principal, one for each supported underlying mechanism. A GSSName that contains only one name representation is called a Mechanism Name (MN).
  3. Creating a GSSCredential
    A GSSCredential contains all the cryptographic information necessary to create a context on behalf of a principal and can contain credential information for multiple mechanisms.
  4. Creating GSSContext
    IBM® JGSS supports two methods provided by GSSManager for creating a context.
  5. Requesting optional security services
    Your application can request any of several optional security services. IBM® JGSS supports several services.
  6. Establishing context
    The two communicating peers must establish a security context over which they can use per-message services.
  7. Using per-message services
    After establishing a security context, two communicating peers can exchange secure messages over the established context.
  8. Deleting context
    A peer deletes a context when the context is no longer needed. In JGSS operations, each peer unilaterally decides when to delete a context and does not need to inform its peer.
Parent topic: Developing IBM JGSS applications
Related reference
Using JAAS with your JGSS application