This interface encapsulates the GSS-API security context and provides the security services that are available over the context. Security contexts are established between peers using locally acquired credentials. Multiple contexts may exist simultaneously between a pair of peers, using the same or different set of credentials. GSS-API functions in a manner independent of the underlying transport protocol and depends on its calling application to transport the tokens that are generated by the security context between the peers.

If the caller instantiates the context using the default GSSManager instance, then the Kerberos v5 GSS-API mechanism is guaranteed to be available for context establishment. This mechanism is identified by the Oid "1.2.840.113554.1.2.2" and is defined in RFC 1964.

Before the context establishment phase is initiated, the context initiator may request specific characteristics desired of the established context. Not all underlying mechanisms support all characteristics that a caller might desire. After the context is established, the caller can check the actual characteristics and services offered by that context by means of various query methods. When using the Kerberos v5 GSS-API mechanism offered by the default GSSManager instance, all optional services will be available locally. They are mutual authentication, credential delegation, confidentiality and integrity protection, and per-message replay detection and sequencing. Note that in the GSS-API, message integrity is a prerequisite for message confidentiality.

The context establishment occurs in a loop where the initiator calls initSecContext and the acceptor calls acceptSecContext until the context is established. While in this loop the initSecContext and acceptSecContext methods produce tokens that the application sends over to the peer. The peer passes any such token as input to its acceptSecContext or initSecContext as the case may be.

During the context establishment phase, the isProtReady method may be called to determine if the context can be used for the per-message operations of wrap and getMIC. This allows applications to use per-message operations on contexts which aren't yet fully established.

After the context has been established or the isProtReady method returns true, the query routines can be invoked to determine the actual characteristics and services of the established context. The application can also start using the per-message methods of wrap and getMIC to obtain cryptographic operations on application supplied data.

When the context is no longer needed, the application should call dispose to release any system resources the context may be using.

A security context typically maintains sequencing and replay detection information about the tokens it processes. Therefore, the sequence in which any tokens are presented to this context for processing can be important. Also note that none of the methods in this interface are synchronized. Therefore, it is not advisable to share a GSSContext among several threads unless some application level synchronization is in place.

Finally, different mechanism providers might place different security restrictions on using GSS-API contexts. These will be documented by the mechanism provider. The application will need to ensure that it has the appropriate permissions if such checks are made in the mechanism layer.

The example code presented below demonstrates the usage of the GSSContext interface for the initiating peer. Different operations on the GSSContext object are presented, including: object instantiation, setting of desired flags, context establishment, query of actual context flags, per-message operations on application data, and finally context deletion.

// Create a context using default credentials
    // and the implementation specific default mechanism
    GSSManager manager ...
    GSSName targetName ...
    GSSContext context = manager.createContext(targetName, null, null,
                                           GSSContext.INDEFINITE_LIFETIME);

    // set desired context options prior to context establishment
    context.requestConf(true);
    context.requestMutualAuth(true);
    context.requestReplayDet(true);
    context.requestSequenceDet(true);

    // establish a context between peers

    byte []inToken = new byte[0];

    // Loop while there still is a token to be processed

    while (!context.isEstablished()) {

        byte[] outToken
            = context.initSecContext(inToken, 0, inToken.length);

        // send the output token if generated
        if (outToken != null)
            sendToken(outToken);

        if (!context.isEstablished()) {
            inToken = readToken();
    }

     // display context information
     System.out.println("Remaining lifetime in seconds = "
                                          + context.getLifetime());
     System.out.println("Context mechanism = " + context.getMech());
     System.out.println("Initiator = " + context.getSrcName());
     System.out.println("Acceptor = " + context.getTargName());

     if (context.getConfState())
             System.out.println("Confidentiality (i.e., privacy) is available");

     if (context.getIntegState())
             System.out.println("Integrity is available");

     // perform wrap on an application supplied message, appMsg,
     // using QOP = 0, and requesting privacy service
     byte [] appMsg ...

     MessageProp mProp = new MessageProp(0, true);

     byte []tok = context.wrap(appMsg, 0, appMsg.length, mProp);

     sendToken(tok);

     // release the local-end of the context
     context.dispose();

Called by the context initiator to start the context creation phase and process any tokens generated by the peer's acceptSecContext method. This method may return an output token which the application will need to send to the peer for processing by its acceptSecContext method. The application can call isEstablished to determine if the context establishment phase is complete on this side of the context. A return value of false from isEstablished indicates that more tokens are expected to be supplied to initSecContext. Upon completion of the context establishment, the available context options may be queried through the get methods.

Note that it is possible that the initSecContext method return a token for the peer, and isEstablished return true also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.

Some mechanism providers might require that the caller be granted permission to initiate a security context. A failed permission check might cause a SecurityException to be thrown from this method.

Called by the context initiator to start the context creation phase and process any tokens generated by the peer's acceptSecContext method using streams. This method may write an output token to the OutpuStream, which the application will need to send to the peer for processing by its acceptSecContext call. Typically, the application would ensure this by calling the flush method on an OutputStream that encapsulates the connection between the two peers. The application can determine if a token is written to the OutputStream from the return value of this method. A return value of 0 indicates that no token was written. The application can call isEstablished to determine if the context establishment phase is complete on this side of the context. A return value of false from isEstablished indicates that more tokens are expected to be supplied to initSecContext. Upon completion of the context establishment, the available context options may be queried through the get methods.

Note that it is possible that the initSecContext method return a token for the peer, and isEstablished return true also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.

The GSS-API authentication tokens contain a definitive start and end. This method will attempt to read one of these tokens per invocation, and may block on the stream if only part of the token is available. In all other respects this method is equivalent to the byte array based initSecContext.

Some mechanism providers might require that the caller be granted permission to initiate a security context. A failed permission check might cause a SecurityException to be thrown from this method.

The following example code demonstrates how this method might be used:

InputStream is ...
     OutputStream os ...
     GSSContext context ...

     // Loop while there is still a token to be processed

     while (!context.isEstablished()) {

         context.initSecContext(is, os);

         // send output token if generated
         os.flush();
     }

Called by the context acceptor upon receiving a token from the peer. This method may return an output token which the application will need to send to the peer for further processing by its initSecContext call.

The application can call isEstablished to determine if the context establishment phase is complete for this peer. A return value of false from isEstablished indicates that more tokens are expected to be supplied to this method. Upon completion of the context establishment, the available context options may be queried through the get methods.

Note that it is possible that acceptSecContext return a token for the peer, and isEstablished return true also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.

Some mechanism providers might require that the caller be granted permission to accept a security context. A failed permission check might cause a SecurityException to be thrown from this method.

The following example code demonstrates how this method might be used:

byte[] inToken;
     byte[] outToken;
     GSSContext context ...

     // Loop while there is still a token to be processed

     while (!context.isEstablished()) {
         inToken = readToken();
         outToken = context.acceptSecContext(inToken, 0,
                                             inToken.length);
         // send output token if generated
         if (outToken != null)
             sendToken(outToken);
     }

Called by the context acceptor to process a token from the peer using streams. It may write an output token to the OutputStream, which the application will need to send to the peer for processing by its initSecContext method. Typically, the application would ensure this by calling the flush method on an OutputStream that encapsulates the connection between the two peers. The application can call isEstablished to determine if the context establishment phase is complete on this side of the context. A return value of false from isEstablished indicates that more tokens are expected to be supplied to acceptSecContext. Upon completion of the context establishment, the available context options may be queried through the get methods.

Note that it is possible that acceptSecContext return a token for the peer, and isEstablished return true also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.

The GSS-API authentication tokens contain a definitive start and end. This method will attempt to read one of these tokens per invocation, and may block on the stream if only part of the token is available. In all other respects this method is equivalent to the byte array based acceptSecContext.

Some mechanism providers might require that the caller be granted permission to accept a security context. A failed permission check might cause a SecurityException to be thrown from this method.

The following example code demonstrates how this method might be used:

InputStream is ...
     OutputStream os ...
     GSSContext context ...

     // Loop while there is still a token to be processed

     while (!context.isEstablished()) {

         context.acceptSecContext(is, os);

         // send output token if generated
         os.flush();
     }

Used to determine limits on the size of the message that can be passed to wrap. Returns the maximum message size that, if presented to the wrap method with the same confReq and qop parameters, will result in an output token containing no more than maxTokenSize bytes.

This call is intended for use by applications that communicate over protocols that impose a maximum message size. It enables the application to fragment messages prior to applying protection.

GSS-API implementations are recommended but not required to detect invalid QOP values when getWrapSizeLimit is called. This routine guarantees only a maximum message size, not the availability of specific QOP values for message protection.

Applies per-message security services over the established security context. The method will return a token with the application supplied data and a cryptographic MIC over it. The data may be encrypted if confidentiality (privacy) was requested.

The MessageProp object is instantiated by the application and used to specify a QOP value which selects cryptographic algorithms, and a privacy service to optionally encrypt the message. The underlying mechanism that is used in the call may not be able to provide the privacy service. It sets the actual privacy service that it does provide in this MessageProp object which the caller should then query upon return. If the mechanism is not able to provide the requested QOP, it throws a GSSException with the BAD_QOP code.

Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping of zero-length messages.

The application will be responsible for sending the token to the peer.

Applies per-message security services over the established security context using streams. The method will return a token with the application supplied data and a cryptographic MIC over it. The data may be encrypted if confidentiality (privacy) was requested. This method is equivalent to the byte array based wrap method.

The application will be responsible for sending the token to the peer. Typically, the application would ensure this by calling the flush method on an OutputStream that encapsulates the connection between the two peers.

The MessageProp object is instantiated by the application and used to specify a QOP value which selects cryptographic algorithms, and a privacy service to optionally encrypt the message. The underlying mechanism that is used in the call may not be able to provide the privacy service. It sets the actual privacy service that it does provide in this MessageProp object which the caller should then query upon return. If the mechanism is not able to provide the requested QOP, it throws a GSSException with the BAD_QOP code.

Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping of zero-length messages.

Used to process tokens generated by the wrap method on the other side of the context. The method will return the message supplied by the peer application to its wrap call, while at the same time verifying the embedded MIC for that message.

The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP, whether confidentiality was applied to the message, and other supplementary message state information.

Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping and unwrapping of zero-length messages.

Uses streams to process tokens generated by the wrap method on the other side of the context. The method will return the message supplied by the peer application to its wrap call, while at the same time verifying the embedded MIC for that message.

The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP, whether confidentiality was applied to the message, and other supplementary message state information.

Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping and unwrapping of zero-length messages.

The format of the input token that this method reads is defined in the specification for the underlying mechanism that will be used. This method will attempt to read one of these tokens per invocation. If the mechanism token contains a definitive start and end this method may block on the InputStream if only part of the token is available. If the start and end of the token are not definitive then the method will attempt to treat all available bytes as part of the token.

Other than the possible blocking behavior described above, this method is equivalent to the byte array based unwrap method.

Returns a token containing a cryptographic Message Integrity Code (MIC) for the supplied message, for transfer to the peer application. Unlike wrap, which encapsulates the user message in the returned token, only the message MIC is returned in the output token.

Note that privacy can only be applied through the wrap call.

Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support derivation of MICs from zero-length messages.

Uses streams to produce a token containing a cryptographic MIC for the supplied message, for transfer to the peer application. Unlike wrap, which encapsulates the user message in the returned token, only the message MIC is produced in the output token. This method is equivalent to the byte array based getMIC method. Note that privacy can only be applied through the wrap call.

Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support derivation of MICs from zero-length messages.

Verifies the cryptographic MIC, contained in the token parameter, over the supplied message.

The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP indicating the strength of protection that was applied to the message and other supplementary message state information.

Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support the calculation and verification of MICs over zero-length messages.

Uses streams to verify the cryptographic MIC, contained in the token parameter, over the supplied message. This method is equivalent to the byte array based verifyMIC method. The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP indicating the strength of protection that was applied to the message and other supplementary message state information.

Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support the calculation and verification of MICs over zero-length messages.

The format of the input token that this method reads is defined in the specification for the underlying mechanism that will be used. This method will attempt to read one of these tokens per invocation. If the mechanism token contains a definitive start and end this method may block on the InputStream if only part of the token is available. If the start and end of the token are not definitive then the method will attempt to treat all available bytes as part of the token.

Other than the possible blocking behavior described above, this method is equivalent to the byte array based verifyMIC method.

Exports this context so that another process may import it.. Provided to support the sharing of work between multiple processes. This routine will typically be used by the context-acceptor, in an application where a single process receives incoming connection requests and accepts security contexts over them, then passes the established context to one or more other processes for message exchange.

This method deactivates the security context and creates an interprocess token which, when passed to GSSManager.createContext in another process, will re-activate the context in the second process. Only a single instantiation of a given context may be active at any one time; a subsequent attempt by a context exporter to access the exported security context will fail.

The implementation may constrain the set of processes by which the interprocess token may be imported, either as a function of local security policy, or as a result of implementation decisions. For example, some implementations may constrain contexts to be passed only between processes that run under the same account, or which are part of the same process group.

The interprocess token may contain security-sensitive information (for example cryptographic keys). While mechanisms are encouraged to either avoid placing such sensitive information within interprocess tokens, or to encrypt the token before returning it to the application, in a typical GSS-API implementation this may not be possible. Thus the application must take care to protect the interprocess token, and ensure that any process to which the token is transferred is trustworthy.

Implementations are not required to support the inter-process transfer of security contexts. Calling the isTransferable method will indicate if the context object is transferable.

Calling this method on a context that is not exportable will result in this exception being thrown with the error code GSSException.UNAVAILABLE.

Requests that mutual authentication be done during context establishment. This request can only be made on the context initiator's side and it has to be done prior to the first call to initSecContext.

Not all mechanisms support mutual authentication and some mechanisms might require mutual authentication even if the application doesn't. Therefore, the application should check to see if the request was honored with the getMutualAuthState method.

Requests that replay detection be enabled for the per-message security services after context establishment. This request can only be made on the context initiator's side and it has to be done prior to the first call to initSecContext. During context establishment replay detection is not an option and is a function of the underlying mechanism's capabilities.

Not all mechanisms support replay detection and some mechanisms might require replay detection even if the application doesn't. Therefore, the application should check to see if the request was honored with the getReplayDetState method. If replay detection is enabled then the MessageProp.isDuplicateToken and MessageProp.isOldToken methods will return valid results for the MessageProp object that is passed in to the unwrap method or the verifyMIC method.

Requests that sequence checking be enabled for the per-message security services after context establishment. This request can only be made on the context initiator's side and it has to be done prior to the first call to initSecContext. During context establishment sequence checking is not an option and is a function of the underlying mechanism's capabilities.

Not all mechanisms support sequence checking and some mechanisms might require sequence checking even if the application doesn't. Therefore, the application should check to see if the request was honored with the getSequenceDetState method. If sequence checking is enabled then the MessageProp.isDuplicateToken, MessageProp.isOldToken, MessageProp.isUnseqToken, and MessageProp.isGapToken methods will return valid results for the MessageProp object that is passed in to the unwrap method or the verifyMIC method.

Requests that the initiator's credentials be delegated to the acceptor during context establishment. This request can only be made on the context initiator's side and it has to be done prior to the first call to initSecContext. Not all mechanisms support credential delegation. Therefore, an application that desires delegation should check to see if the request was honored with the getCredDelegState method. If the application indicates that delegation must not be used, then the mechanism will honor the request and delegation will not occur. This is an exception to the general rule that a mechanism may enable a service even if it is not requested.

Requests that the initiator's identity not be disclosed to the acceptor. This request can only be made on the context initiator's side and it has to be done prior to the first call to initSecContext. Not all mechanisms support anonymity for the initiator. Therefore, the application should check to see if the request was honored with the getAnonymityState method.

Requests that data confidentiality be enabled for the wrap method. This request can only be made on the context initiator's side and it has to be done prior to the first call to initSecContext. Not all mechanisms support confidentiality and other mechanisms might enable it even if the application doesn't request it. The application may check to see if the request was honored with the getConfState method. If confidentiality is enabled, only then will the mechanism honor a request for privacy in the MessageProp object that is passed in to the wrap method.

Enabling confidentiality will also automatically enable integrity.

Requests that data integrity be enabled for the wrap and getMICmethods. This request can only be made on the context initiator's side and it has to be done prior to the first call to initSecContext. Not all mechanisms support integrity and other mechanisms might enable it even if the application doesn't request it. The application may check to see if the request was honored with the getIntegState method.

Disabling integrity will also automatically disable confidentiality.

Requests a lifetime in seconds for the context. This method can only be called on the context initiator's side and it has to be done prior to the first call to initSecContext.

The actual lifetime of the context will depend on the capabilities of the underlying mechanism and the application should call the getLifetime method to determine this.

Determines if credential delegation is enabled on this context. It can be called by both the context initiator and the context acceptor. For a definitive answer this method must be called only after context establishment is complete. Note that if an initiator requests that delegation not be allowed the requestCredDeleg method will honor that request and this method will return false on the initiator's side from that point onwards.

Determines if mutual authentication is enabled on this context. It can be called by both the context initiator and the context acceptor. For a definitive answer this method must be called only after context establishment is complete. An initiator that requests mutual authentication can call this method after context completion and dispose the context if its request was not honored.

Determines if replay detection is enabled for the per-message security services from this context. It can be called by both the context initiator and the context acceptor. For a definitive answer this method must be called only after context establishment is complete. An initiator that requests replay detection can call this method after context completion and dispose the context if its request was not honored.

Determines if sequence checking is enabled for the per-message security services from this context. It can be called by both the context initiator and the context acceptor. For a definitive answer this method must be called only after context establishment is complete. An initiator that requests sequence checking can call this method after context completion and dispose the context if its request was not honored.

Determines if the context initiator is anonymously authenticated to the context acceptor. It can be called by both the context initiator and the context acceptor, and at any time. On the initiator side, a call to this method determines if the identity of the initiator has been disclosed in any of the context establishment tokens that might have been generated thus far by initSecContext. An initiator that absolutely must be authenticated anonymously should call this method after each call to initSecContext to determine if the generated token should be sent to the peer or the context aborted. On the acceptor side, a call to this method determines if any of the tokens processed by acceptSecContext thus far have divulged the identity of the initiator.

Determines if data confidentiality is available over the context. This method can be called by both the context initiator and the context acceptor, but only after one of isProtReady or isEstablished return true. If this method returns true, so will getIntegState

Determines if data integrity is available over the context. This method can be called by both the context initiator and the context acceptor, but only after one of isProtReady or isEstablished return true. This method will always return true if getConfState returns true.

Determines what the remaining lifetime for this context is. It can be called by both the context initiator and the context acceptor, but for a definitive answer it should be called only after isEstablished returns true.