RFC2853 - Generic Security Service API Version 2 : Java Bind(2)

时间:2005-02-16 来源: 作者: 点击:
supplied. DEFECTIVE_TOKEN 9 A supplied token was invalid. DEFECTIVE_CREDENTIAL 10 A supplied credential was invalid. CREDENTIALS_EXPIRED 11 The referenced credentials have expired. CONTEXT_EXPIRED 12
  
supplied.

DEFECTIVE_TOKEN 9 A supplied token was invalid.

DEFECTIVE_CREDENTIAL 10 A supplied credential was
invalid.

CREDENTIALS_EXPIRED 11 The referenced credentials
have expired.

CONTEXT_EXPIRED 12 The context has expired.

FAILURE 13 Miscellaneous failure,
unspecified at the GSS-API level.

BAD_QOP 14 The quality-of-protection
requested could not be provided.

UNAUTHORIZED 15 The operation is forbidden by
local security policy.

UNAVAILABLE 16 The operation or option is
unavailable.

DUPLICATE_ELEMENT 17 The requested credential
element already exists.

NAME_NOT_MN 18 The provided name was not a
mechanism name.

OLD_TOKEN 19 The token's validity period has
expired.

DUPLICATE_TOKEN 20 The token was a duplicate of an
earlier version.

The GSS major status code of FAILURE is used to indicate that the
underlying mechanism detected an error for which no specific GSS
status code is defined. The mechanism-specific status code can
provide more details about the error.

The different major status codes that can be contained in the
GSSException object thrown by the methods in this specification are
the same as the major status codes returned by the corresponding
calls in RFC2743 [GSSAPIv2-UPDATE].

4.12.2. Mechanism-specific status codes

Mechanism-specific status codes are communicated in two ways, they
are part of any GSSException thrown from the mechanism specific layer
to signal a fatal error, or they are part of the MessageProp object
that the per-message calls use to signal non-fatal errors.

A default value of 0 in either the GSSException object or the
MessageProp object will be used to represent the absence of any
mechanism specific status code.

4.12.3. Supplementary status codes

Supplementary status codes are confined to the per-message methods of
the GSSContext interface. Because of the informative nature of these
errors it is not appropriate to use exceptions to signal them.
Instead, the per-message operations of the GSSContext interface
return these values in a MessageProp object.

The MessageProp class defines query methods which return boolean
values indicating the following supplementary states:

Table: Supplementary Status Methods

Method Name Meaning when "true" is returned

isDuplicateToken The token was a duplicate of an
earlier token.

isOldToken The token's validity period has
expired.

isUnseqToken A later token has already been
processed.

isGapToken An expected per-message token was
not received.

"true" return value for any of the above methods indicates that the
token exhibited the specified property. The application must
determine the appropriate course of action for these supplementary
values. They are not treated as errors by the GSS-API.

4.13. Names

A name is used to identify a person or entity. GSS-API authenticates
the relationship between a name and the entity claiming the name.

Since different authentication mechanisms may employ different
namespaces for identifying their principals, GSS-API's naming support
is necessarily complex in multi-mechanism environments (or even in
some single-mechanism environments where the underlying mechanism
supports multiple namespaces).

Two distinct conceptual representations are defined for names:

1) A GSS-API form represented by implementations of the GSSName
interface: A single GSSName object may contain multiple names from
different namespaces, but all names should refer to the same
entity. An example of such an internal name would be the name
returned from a call to the getName method of the GSSCredential
interface, when applied to a credential containing credential
elements for multiple authentication mechanisms employing
different namespaces. This GSSName object will contain a distinct
name for the entity for each authentication mechanism.

For GSS-API implementations supporting multiple namespaces,
GSSName implementations must contain sufficient information to
determine the namespace to which each primitive name belongs.

2) Mechanism-specific contiguous byte array and string forms:
Different GSSName initialization methods are provided to handle
both byte array and string formats and to accommodate various
calling applications and name types. These formats are capable of
containing only a single name (from a single namespace).
Contiguous string names are always accompanied by an object
identifier specifying the namespace to which the name belongs, and
their format is dependent on the authentication mechanism that
employs that name. The string name forms are assumed to be
printable, and may therefore be used by GSS-API applications for
communication with their users. The byte array name formats are
assumed to be in non-printable formats (e.g. the byte array
returned from the export method of the GSSName interface).

A GSSName object can be converted to a contiguous representation by
using the toString method. This will guarantee that the name will be
converted to a printable format. Different initialization methods in
the GSSName interface are defined allowing support for multiple
syntaxes for each supported namespace, and allowing users the freedom
to choose a preferred name representation. The toString method
should use an implementation-chosen printable syntax for each
supported name-type. To obtain the printable name type,
getStringNameType method can be used.

There is no guarantee that calling the toString method on the GSSName
interface will produce the same string form as the original imported
string name. Furthermore, it is possible that the name was not even
constructed from a string representation. The same applies to name-
space identifiers which may not necessarily survive unchanged after a
journey through the internal name-form. An example of this might be
a mechanism that authenticates X.500 names, but provides an
algorithmic mapping of Internet DNS names into X.500. That
mechanism's implementation of GSSName might, when presented with a
DNS name, generate an internal name that contained both the original
DNS name and the equivalent X.500 name. Alternatively, it might only
store the X.500 name. In the latter case, the toString method of
GSSName would most likely generate a printable X.500 name, rather
than the original DNS name.

The context acceptor can obtain a GSSName object representing the
entity performing the context initiation (through the usage of
getSrcName method). Since this name has been authenticated by a
single mechanism, it contains only a single name (even if the
internal name presented by the context initiator to the GSSContext

object had multiple components). Such names are termed internal
mechanism names, or "MN"s and the names emitted by GSSContext
interface in the getSrcName and getTargName are always of this type.
Since some applications may require MNs without wanting to incur the
overhead of an authentication operation, creation methods are
provided that take not only the name buffer and name type, but also
the mechanism oid for which this name should be created. When
dealing with an existing GSSName object, the canonicalize method may
be invoked to convert a general internal name into an MN.

GSSName objects can be compared using their equal method, which
returns "true" if the two names being compared refer to the same
entity. This is the preferred way to perform name comparisons
instead of using the printable names that a given GSS-API
implementation may support. Since GSS-API assumes that all primitive
names contained within a given internal name refer to the same
entity, equal can return "true" if the two names have at least one
primitive name in common. If the implementation embodies knowledge
of equivalence relationships between names taken from different
namespaces, this knowledge may also allow successful comparisons of
internal names containing no overlapping primitive elements.

When used in large access control lists, the overhead of creating an
GSSName object on each name and invoking the equal method on each
name from the ACL may be prohibitive. As an alternative way of
supporting this case, GSS-API defines a special form of the
contiguous byte array name which may be compared directly (byte by
byte). Contiguous names suitable for comparison are generated by the
export method. Exported names may be re-imported by using the byte
array constructor and specifying the NT_EXPORT_NAME as the name type
object identifier. The resulting GSSName name will also be a MN.
The GSSName interface defines public static Oid objects representing
the standard name types. Structurally, an exported name object
consists of a header containing an OID identifying the mechanism that
authenticated the name, and a trailer containing the name itself,
where the syntax of the trailer is defined by the individual
mechanism specification. Detailed description of the format is
specified in the language-independent GSS-API specification
[GSSAPIv2-UPDATE].

Note that the results obtained by using the equals method will in
general be different from those obtained by invoking canonicalize and
export, and then comparing the byte array output. The first series
of operation determines whether two (unauthenticated) names identify
the same principal; the second whether a particular mechanism would
authenticate them as the same principal. These two operations will
in general give the same results only for MNs.

It is important to note that the above are guidelines as how GSSName
implementations should behave, and are not intended to be specific
requirements of how names objects must be implemented. The mechanism
designers are free to decide on the details of their implementations
of the GSSName interface as long as the behavior satisfies the above
guidelines.

4.14. Channel Bindings

GSS-API supports the use of user-specified tags to identify a given
context to the peer application. These tags are intended to be used
to identify the particular communications channel that carries the
context. Channel bindings are communicated to the GSS-API using the
ChannelBinding object. The application may use byte arrays to
specify the application data to be used in the channel binding as
well as using instances of the InetAddress. The InetAddress for the
initiator and/or acceptor can be used within an instance of a
ChannelBinding. ChannelBinding can be set for the GSSContext object
using the setChannelBinding method before the first call to init or
accept has been performed. Unless the setChannelBinding method has
been used to set the ChannelBinding for a GSSContext object, "null"
ChannelBinding will be assumed. InetAddress is currently the only
address type defined within the Java platform and as such, it is the
only one supported within the ChannelBinding class. Applications
that use other types of addresses can include them as part of the
application specific data.

Conceptually, the GSS-API concatenates the initiator and acceptor
address information, and the application supplied byte array to form
an octet string. The mechanism calculates a MIC over this octet
string and binds the MIC to the context establishment token emitted
by init method of the GSSContext interface. The same bindings are
set by the context acceptor for its GSSContext object and during
processing of the accept method a MIC is calculated in the same way.
The calculated MIC is compared with that found in the token, and if
the MICs differ, accept will throw a GSSException with the major
code set to BAD_BINDINGS, and the context will not be established.
Some mechanisms may include the actual channel binding data in the
token (rather than just a MIC); applications should therefore not use
confidential data as channel-binding components.

Individual mechanisms may impose additional constraints on addresses
that may appear in channel bindings. For example, a mechanism may
verify that the initiator address field of the channel binding
contains the correct network address of the host system. Portable
applications should therefore ensure that they either provide correct
information for the address fields, or omit setting of the addressing
information.

4.15. Stream Objects

The context object provides overloaded methods which use input and
output streams as the means to convey authentication and per-message
GSS-API tokens. It is important to note that the streams are
expected to contain the usual GSS-API tokens which would otherwise be
handled through the usage of byte arrays. The tokens are expected to
have a definite start and an end. The callers are responsible for
ensuring that the supplied streams will not block, or expect to block
until a full token is processed by the GSS-API method. Only a single
GSS-API token will be processed per invocation of the stream based
method.

The usage of streams allows the callers to have control and
management of the supplied buffers. Because streams are non-
primitive objects, the callers can make the streams as complicated or
as simple as desired simply by using the streams defined in the
java.io package or creating their own through the use of inheritance.
This will allow for the application's greatest flexibility.

4.16. Optional Parameters

Whenever the application wishes to omit an optional parameter the
"null" value shall be used. The detailed method descriptions
indicate which parameters are optional. Methods overloading has also
been used as a technique to indicate default parameters.

5. Introduction to GSS-API Classes and Interfaces

This section presents a brief description of the classes and
interfaces that constitute the GSS-API. The implementations of these
are obtained from the CLASSPATH defined by the application. If Java
GSS becomes part of the standard Java API's then these classes will
be available by default on all systems as part of the JRE's system
classes.

This section also shows the corresponding RFC2743 functionality
implemented by each of the classes. Detailed description of these
classes and their methods is presented in section 6.

5.1. GSSManager class

This abstract class serves as a factory to instantiate
implementations of the GSS-API interfaces and also provides methods
to make queries about underlying security mechanisms.

A default implementation can be obtained using the static method
getInstance(). Applications that desire to provide their own
implementation of the GSSManager class can simply extend the abstract
class themselves.

This class contains equivalents of the following RFC2743 routines:

gss_import_name Create an internal name from 6.1.9-
the supplied information. 6.1.12

gss_acquire_cred Acquire credential 6.1.13-
for use. 6.1.15

gss_import_sec_context Create a previously exported 6.1.18
context.

gss_indicate_mechs List the mechanisms 6.1.6
supported by this GSS-API
implementation.

gss_inquire_mechs_for_name List the mechanisms 6.1.8
supporting the
specified name type.

gss_inquire_names_for_mech List the name types 6.1.7
supported by the
specified mechanism.

5.2. GSSName interface

GSS-API names are represented in the Java bindings through the
GSSName interface. Different name formats and their definitions are
identified with universal Object Identifiers (oids). The format of
the names can be derived based on the unique oid of each name type.
The following GSS-API routines are provided by the GSSName interface:

RFC2743 Routine Function Section(s)

gss_display_name Covert internal name 6.2.7
representation to text format.

gss_compare_name Compare two internal names. 6.2.3, 6.2.4

gss_release_name Release resources associated N/A
with the internal name.

gss_canonicalize_name Convert an internal name to a 6.1.11,
mechanism name.

gss_export_name Convert a mechanism name to 6.2.6
export format.

gss_duplicate_name Create a copy of the internal N/A
name.

The gss_release_name call is not provided as Java does its own
garbage collection. The gss_duplicate_name call is also redundant;
the GSSName interface has no mutator methods that can change the
state of the object so it is safe for sharing.

5.3. GSSCredential interface

The GSSCredential interface is responsible for the encapsulation of
GSS-API credentials. Credentials identify a single entity and
provide the necessary cryptographic information to enable the
creation of a context on behalf of that entity. A single credential
may contain multiple mechanism specific credentials, each referred to
as a credential element. The GSSCredential interface provides the
functionality of the following GSS-API routines:

RFC2743 Routine Function Section(s)

gss_add_cred Constructs credentials 6.3.12
incrementally.

gss_inquire_cred Obtain information about 6.3.4,6.3.5
credential.

gss_inquire_cred_by_mech Obtain per-mechanism 6.3.5-6.3.10
information about
a credential.

gss_release_cred Disposes of credentials 6.3.3
after use.

5.4. GSSContext interface

This interface encapsulates the functionality of context-level calls
required for security context establishment and management between
peers as well as the per-message services offered to applications. A
context is established between a pair of peers and allows the usage
of security services on a per-message basis on application data. It

is created over a single security mechanism. The GSSContext
interface provides the functionality of the following GSS-API
routines:

RFC2743 Routine Function Section(s)

gss_init_sec_context Initiate the creation of a 6.4.3,
security context with a peer. 6.4.4

gss_accept_sec_context Accept a security context 6.4.5,
initiated by a peer. 6.4.6

gss_delete_sec_context Destroy a security context. 6.4.8

gss_context_time Obtain remaining context 6.4.37
time.

gss_inquire_context Obtain context 6.4.29 to
characteristics. 6.3.42

gss_wrap_size_limit Determine token-size limit 6.4.9
for gss_wrap.

gss_export_sec_context Transfer security context 6.4.18
to another process.

gss_get_mic Calculate a cryptographic 6.4.14,
Message Integrity Code (MIC) 6.4.15
for a message.

gss_verify_mic Verify integrity on a received 6.4.16,
message. 6.4.17

gss_wrap Attach a MIC to a message and 6.4.10,
optionally encrypt the message 6.4.11
content.

gss_unwrap Obtain a previously wrapped 6.4.12,
application message verifying 6.4.13
its integrity and optionally
decrypting it.

The functionality offered by the gss_process_context_token routine
has not been included in the Java bindings specification. The
corresponding functionality of gss_delete_sec_context has also been
modified to not return any peer tokens. This has been proposed in

accordance to the recommendations stated in RFC2743. GSSContext
does offer the functionality of destroying the locally-stored context
information.

5.5. MessageProp class

This helper class is used in the per-message operations on the
context. An instance of this class is created by the application and
then passed into the per-message calls. In some cases, the
application conveys information to the GSS-API implementation through
this object and in other cases the GSS-API returns information to the
application by setting it in this object. See the description of the
per-message operations wrap, unwrap, getMIC, and verifyMIC in the
GSSContext interfaces for details.

5.6. GSSException class

Exceptions are used in the Java bindings to signal fatal errors to
the calling applications. This replaces the major and minor codes
used in the C-bindings specification as a method of signaling
failures. The GSSException class handles both minor and major codes,
as well as their translation into textual representation. All GSS-
API methods are declared as throwing this exception.

RFC2743 Routine Function Section

gss_display_status Retrieve textual 6.8.5, 6.8.6,
representation of error 6.8.8, 6.8.9
codes.

5.7. Oid class

This utility class is used to represent Universal Object Identifiers
and their associated operations. GSS-API uses object identifiers to
distinguish between security mechanisms and name types. This class,
aside from being used whenever an object identifier is needed,
implements the following GSS-API functionality:

RFC2743 Routine Function Section

gss_test_oid_set_member Determine if the specified oid 6.7.5
is part of a set of oids.

5.8. ChannelBinding class

An instance of this class is used to specify channel binding
information to the GSSContext object before the start of a security
context establishment. The application may use a byte array to
specify application data to be used in the channel binding as well as
use instances of the InetAddress. InetAddress is currently the only
address type defined within the Java platform and as such, it is the
only one supported within the ChannelBinding class. Applications that
use other types of addresses can include them as part of the
application data.

6. Detailed GSS-API Class Description

This section lists a detailed description of all the public methods
that each of the GSS-API classes and interfaces must provide.

6.1. public abstract class GSSManager

The GSSManager class is an abstract class that serves as a factory
for three GSS interfaces: GSSName, GSSCredential, and GSSContext. It
also provides methods for applications to determine what mechanisms
are available from the GSS implementation and what nametypes these
mechanisms support. An instance of the default GSSManager subclass
may be obtained through the static method getInstance(), but
applications are free to instantiate other subclasses of GSSManager.

All but one method in this class are declared abstract. This means
that subclasses have to provide the complete implementation for those
methods. The only exception to this is the static method
getInstance() which will have platform specific code to return an
instance of the default subclass.

Platform providers of GSS are required not to add any constructors to
this class, private, public, or protected. This will ensure that all
subclasses invoke only the default constructor provided to the base
class by the compiler.

A subclass extending the GSSManager abstract class may be implemented
as a modular provider based layer that utilizes some well known
service provider specification. The GSSManager API provides the
application with methods to set provider preferences on such an
implementation. These methods also allow the implementation to throw
a well-defined exception in case provider based configuration is not
supported. Applications that expect to be portable should be aware of
this and recover cleanly by catching the exception.

It is envisioned that there will be three most common ways in which
providers will be used:

1) The application does not care about what provider is used (the
default case).

2) The application wants a particular provider to be used
preferentially, either for a particular mechanism or all the
time, irrespective of mechanism.

3) The application wants to use the locally configured providers
as far as possible but if support is missing for one or more
mechanisms then it wants to fall back on its own provider.

The GSSManager class has two methods that enable these modes of
usage: addProviderAtFront() and addProviderAtEnd(). These methods
have the effect of creating an ordered list of <provider, oid> pairs
where each pair indicates a preference of provider for a given oid.

The use of these methods does not require any knowledge of whatever
service provider specification the GSSManager subclass follows. It is
hoped that these methods will serve the needs of most applications.
Additional methods may be added to an extended GSSManager that could
be part of a service provider specification that is standardized
later.

6.1.1. Example Code

GSSManager mgr = GSSManager.getInstance();

// What mechs are available to us?
Oid[] supportedMechs = mgr.getMechs();

// Set a preference for the provider to be used when support is needed
// for the mechanisms "1.2.840.113554.1.2.2" and "1.3.6.1.5.5.1.1".

Oid krb = new Oid("1.2.840.113554.1.2.2");
Oid spkm1 = new Oid("1.3.6.1.5.5.1.1");

Provider p = (Provider) (new com.foo.security.Provider());

mgr.addProviderAtFront(p, krb);
mgr.addProviderAtFront(p, spkm1);

// What name types does this spkm implementation support?
Oid[] nameTypes = mgr.getNamesForMech(spkm1);

6.1.2. getInstance

public static GSSManager getInstance()

Returns the default GSSManager implementation.

6.1.3. getMechs

public abstract Oid[] getMechs()

Returns an array of Oid objects indicating mechanisms available to
GSS-API callers. A "null" value is returned when no mechanism are
available (an example of this would be when mechanism are dynamically
configured, and currently no mechanisms are installed).

6.1.4. getNamesForMech

public abstract Oid[] getNamesForMech(Oid mech)
throws GSSException

Returns name type Oid's supported by the specified mechanism.

Parameters:

mech The Oid object for the mechanism to query.

6.1.5. getMechsForName

public abstract Oid[] getMechsForName(Oid nameType)

Returns an array of Oid objects corresponding to the mechanisms that
support the specific name type. "null" is returned when no
mechanisms are found to support the specified name type.

Parameters:

nameType The Oid object for the name type.

6.1.6. createName

public abstract GSSName createName(String nameStr, Oid nameType)
throws GSSException

Factory method to convert a contiguous string name from the specified
namespace to a GSSName object. In general, the GSSName object
created will not be an MN; two examples that are exceptions to this
are when the namespace type parameter indicates NT_EXPORT_NAME or
when the GSS-API implementation is not multi-mechanism.

Parameters:

nameStr The string representing a printable form of the name
to create.

nameType The Oid specifying the namespace of the printable name
supplied. Note that nameType serves to describe and
qualify the interpretation of the input nameStr, it
does not necessarily imply a type for the output
GSSName implementation. "null" value can be used to
specify that a mechanism specific default printable
syntax should be assumed by each mechanism that
examines nameStr.

6.1.7. createName

public abstract GSSName createName(byte name[], Oid nameType)
throws GSSException

Factory method to convert a contiguous byte array containing a name
from the specified namespace to a GSSName object. In general, the
GSSName object created will not be an MN; two examples that are
exceptions to this are when the namespace type parameter indicates
NT_EXPORT_NAME or when the GSS-API implementation is not multi-
mechanism.

Parameters:

name The byte array containing the name to create.

nameType The Oid specifying the namespace of the name supplied
in the byte array. Note that nameType serves to
describe and qualify the interpretation of the input
name byte array, it does not necessarily imply a type
for the output GSSName implementation. "null" value
can be used to specify that a mechanism specific
default syntax should be assumed by each mechanism
that examines the byte array.

6.1.8. createName

public abstract GSSName createName(String nameStr, Oid nameType,
Oid mech) throws GSSException

Factory method to convert a contiguous string name from the specified
namespace to an GSSName object that is a mechanism name (MN). In
other words, this method is a utility that does the equivalent of two
steps: the createName described in 6.1.7 and then also the
GSSName.canonicalize() described in 6.2.5.

Parameters:

nameStr The string representing a printable form of the name
to create.

nameType The Oid specifying the namespace of the printable name
supplied. Note that nameType serves to describe and
qualify the interpretation of the input nameStr, it
does not necessarily imply a type for the output
GSSName implementation. "null" value can be used to
specify that a mechanism specific default printable
syntax should be assumed when the mechanism examines
nameStr.

mech Oid specifying the mechanism for which this name
should be created.

6.1.9. createName

public abstract createName(byte name[], Oid nameType, Oid mech)
throws GSSException

Factory method to convert a contiguous byte array containing a name
from the specified namespace to a GSSName object that is an MN. In
other words, this method is a utility that does the equivalent of two
steps: the createName described in 6.1.8 and then also the
GSSName.canonicalize() described in 6.2.5.

Parameters:

name The byte array representing the name to create.

nameType The Oid specifying the namespace of the name supplied
in the byte array. Note that nameType serves to
describe and qualify the interpretation of the input
name byte array, it does not necessarily imply a type
for the output GSSName implementation. "null" value

can be used to specify that a mechanism specific
default syntax should be assumed by each mechanism
that examines the byte array.

mech Oid specifying the mechanism for which this name
should be created.

6.1.10. createCredential

public abstract GSSCredential createCredential (int usage)
throws GSSException

Factory method for acquiring default credentials. This will cause
the GSS-API to use system specific defaults for the set of
mechanisms, name, and a DEFAULT lifetime.

Parameters:

usage The intended usage for this credential object. The
value of this parameter must be one of:
GSSCredential.ACCEPT_AND_INITIATE,
GSSCredential.ACCEPT_ONLY, GSSCredential.INITIATE_ONLY

6.1.11. createCredential

public abstract GSSCredential createCredential (GSSName aName,
int lifetime, Oid mech, int usage)
throws GSSException

Factory method for acquiring a single mechanism credential.

Parameters:

aName Name of the principal for whom this credential is to
be acquired. Use "null" to specify the default
principal.

lifetime The number of seconds that credentials should remain
valid. Use GSSCredential.INDEFINITE_LIFETIME to
request that the credentials have the maximum
permitted lifetime. Use
GSSCredential.DEFAULT_LIFETIME to request default
credential lifetime.

mech The oid of the desired mechanism. Use "(Oid) null" to
request the default mechanism(s).

usage The intended usage for this credential object. The
value of this parameter must be one of:
GSSCredential.ACCEPT_AND_INITIATE,
GSSCredential.ACCEPT_ONLY, GSSCredential.INITIATE_ONLY

6.1.12. createCredential

public abstract GSSCredential createCredential(GSSName aName,
int lifetime, Oid mechs[], int usage)
throws GSSException

Factory method for acquiring credentials over a set of mechanisms.
Acquires credentials for each of the mechanisms specified in the
array called mechs. To determine the list of mechanisms' for which
the acquisition of credentials succeeded, the caller should use the
GSSCredential.getMechs() method.

Parameters:

aName Name of the principal for whom this credential is to
be acquired. Use "null" to specify the default
principal.

lifetime The number of seconds that credentials should remain
valid. Use GSSCredential.INDEFINITE_LIFETIME to
request that the credentials have the maximum
permitted lifetime. Use
GSSCredential.DEFAULT_LIFETIME to request default
credential lifetime.

mechs The array of mechanisms over which the credential is
to be acquired. Use "(Oid[]) null" for requesting a
system specific default set of mechanisms.

usage The intended usage for this credential object. The
value of this parameter must be one of:
GSSCredential.ACCEPT_AND_INITIATE,
GSSCredential.ACCEPT_ONLY, GSSCredential.INITIATE_ONLY

6.1.13. createContext

public abstract GSSContext createContext(GSSName peer, Oid mech,
GSSCredential myCred, int lifetime)
throws GSSException

Factory method for creating a context on the initiator's side.
Context flags may be modified through the mutator methods prior to
calling GSSContext.initSecContext().

Parameters:

peer Name of the target peer.

mech Oid of the desired mechanism. Use "(Oid) null" to
request default mechanism.

myCred Credentials of the initiator. Use "null" to act as a
default initiator principal.

lifetime The request lifetime, in seconds, for the context.
Use GSSContext.INDEFINITE_LIFETIME and
GSSContext.DEFAULT_LIFETIME to request indefinite or
default context lifetime.

6.1.14. createContext

public abstract GSSContext createContext(GSSCredential myCred)
throws GSSException

Factory method for creating a context on the acceptor' side. The
context's properties will be determined from the input token supplied
to the accept method.

Parameters:

myCred Credentials for the acceptor. Use "null" to act as a
default acceptor principal.

6.1.15. createContext

public abstract GSSContext createContext(byte [] interProcessToken)
throws GSSException

Factory method for creating a previously exported context. The
context properties will be determined from the input token and can't
be modified through the set methods.

Parameters:

interProcessToken
The token previously emitted from the export method.

6.1.16. addProviderAtFront

public abstract void addProviderAtFront(Provider p, Oid mech)
throws GSSException

This method is used to indicate to the GSSManager that the
application would like a particular provider to be used ahead of all
others when support is desired for the given mechanism. When a value
of null is used instead of an Oid for the mechanism, the GSSManager
must use the indicated provider ahead of all others no matter what
the mechanism is. Only when the indicated provider does not support
the needed mechanism should the GSSManager move on to a different
provider.

Calling this method repeatedly preserves the older settings but
lowers them in preference thus forming an ordered list of provider
and Oid pairs that grows at the top.

Calling addProviderAtFront with a null Oid will remove all previous
preferences that were set for this provider in the GSSManager
instance. Calling addProviderAtFront with a non-null Oid will remove
any previous preference that was set using this mechanism and this
provider together.

If the GSSManager implementation does not support an SPI with a
pluggable provider architecture it should throw a GSSException with
the status code GSSException.UNAVAILABLE to indicate that the
operation is unavailable.

Parameters:

p The provider instance that should be used whenever
support is needed for mech.

mech The mechanism for which the provider is being set

6.1.16.1. Example Code

Suppose an application desired that the provider A always be checked
first when any mechanism is needed, it would call:

GSSManager mgr = GSSManager.getInstance();
// mgr may at this point have its own pre-configured list
// of provider preferences. The following will prepend to
// any such list:

mgr.addProviderAtFront(A, null);

Now if it also desired that the mechanism of Oid m1 always be
obtained from the provider B before the previously set A was checked,
it would call:

mgr.addProviderAtFront(B, m1);

The GSSManager would then first check with B if m1 was needed. In
case B did not provide support for m1, the GSSManager would continue
on to check with A. If any mechanism m2 is needed where m2 is
different from m1 then the GSSManager would skip B and check with A
directly.

Suppose at a later time the following call is made to the same
GSSManager instance:

mgr.addProviderAtFront(B, null)

then the previous setting with the pair (B, m1) is subsumed by this
and should be removed. Effectively the list of preferences now
becomes {(B, null), (A, null),
... //followed by the pre-configured list.

Please note, however, that the following call:

mgr.addProviderAtFront(A, m3)

does not subsume the previous setting of (A, null) and the list will
effectively become {(A, m3), (B, null), (A, null), ...}

6.1.17. addProviderAtEnd

public abstract addProviderAtEnd(Provider p, Oid mech)
throws GSSException

This method is used to indicate to the GSSManager that the
application would like a particular provider to be used if no other
provider can be found that supports the given mechanism. When a value
of null is used instead of an Oid for the mechanism, the GSSManager
must use the indicated provider for any mechanism.

Calling this method repeatedly preserves the older settings but
raises them above newer ones in preference thus forming an ordered
list of providers and Oid pairs that grows at the bottom. Thus the
older provider settings will be utilized first before this one is.

If there are any previously existing preferences that conflict with
the preference being set here, then the GSSManager should ignore this
request.

If the GSSManager implementation does not support an SPI with a
pluggable provider architecture it should throw a GSSException with
the status code GSSException.UNAVAILABLE to indicate that the
operation is unavailable.

Parameters:

p The provider instance that should be used whenever
support is needed for mech.

mech The mechanism for which the provider is being set

6.1.17.1. Example Code

Suppose an application desired that when a mechanism of Oid m1 is
needed the system default providers always be checked first, and only
when they do not support m1 should a provider A be checked. It would
then make the call:

GSSManager mgr = GSSManager.getInstance();

mgr.addProviderAtEnd(A, m1);

Now, if it also desired that for all mechanisms the provider B be
checked after all configured providers have been checked, it would
then call:

mgr.addProviderAtEnd(B, null);

Effectively the list of preferences now becomes {..., (A, m1), (B,
null)}.

Suppose at a later time the following call is made to the same
GSSManager instance:

mgr.addProviderAtEnd(B, m2)

then the previous setting with the pair (B, null) subsumes this and
therefore this request should be ignored. The same would happen if a
request is made for the already existing pairs of (A, m1) or (B,
null).

Please note, however, that the following call:

mgr.addProviderAtEnd(A, null)

is not subsumed by the previous setting of (A, m1) and the list will
effectively become {..., (A, m1), (B, null), (A, null)}

6.2. public interface GSSName

This interface encapsulates a single GSS-API principal entity.
Different name formats and their definitions are identified with
universal Object Identifiers (Oids). The format of the names can be
derived based on the unique oid of its namespace type.

6.2.1. Example Code

Included below are code examples utilizing the GSSName interface.
The code below creates a GSSName, converts it to a mechanism name
(MN), performs a comparison, obtains a printable representation of
the name, exports it and then re-imports to obtain a new GSSName.

GSSManager mgr = GSSManager.getInstance();

// create a host based service name
GSSName name = mgr.createName("service@host",
GSSName.NT_HOSTBASED_SERVICE);

Oid krb5 = new Oid("1.2.840.113554.1.2.2");

GSSName mechName = name.canonicalize(krb5);

// the above two steps are equivalent to the following
GSSName mechName = mgr.createName("service@host",
GSSName.NT_HOSTBASED_SERVICE, krb5);

// perform name comparison
if (name.equals(mechName))
print("Names are equals.");

// obtain textual representation of name and its printable
// name type
print(mechName.toString() +
mechName.getStringNameType().toString());

// export and re-import the name
byte [] exportName = mechName.export();

// create a new name object from the exported buffer
GSSName newName = mgr.createName(exportName,
GSSName.NT_EXPORT_NAME);

6.2.2. Static Constants

public static final Oid NT_HOSTBASED_SERVICE

Oid indicating a host-based service name form. It is used to
represent services associated with host computers. This name form is
constructed using two elements, "service" and "hostname", as follows:

service@hostname

Values for the "service" element are registered with the IANA. It
represents the following value: { 1(iso), 3(org), 6(dod),
1(internet), 5(security), 6(nametypes), 2(gss-host-based-services) }

public static final Oid NT_USER_NAME

Name type to indicate a named user on a local system. It represents
the following value: { iso(1) member-body(2) United States(840)
mit(113554) infosys(1) gssapi(2) generic(1) user_name(1) }

public static final Oid NT_MACHINE_UID_NAME

Name type to indicate a numeric user identifier corresponding to a
user on a local system. (e.g. Uid). It represents the following
value: { iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) generic(1) machine_uid_name(2) }

public static final Oid NT_STRING_UID_NAME

Name type to indicate a string of digits representing the numeric
user identifier of a user on a local system. It represents the
following value: { iso(1) member-body(2) United States(840)
mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3) }

public static final Oid NT_ANONYMOUS

Name type for representing an anonymous entity. It represents the
following value: { 1(iso), 3(org), 6(dod), 1(internet), 5(security),
6(nametypes), 3(gss-anonymous-name) }

public static final Oid NT_EXPORT_NAME

Name type used to indicate an exported name produced by the export
method. It represents the following value: { 1(iso), 3(org), 6(dod),
1(internet), 5(security), 6(nametypes), 4(gss-api-exported-name) }

6.2.3. equals

public boolean equals(GSSName another) throws GSSException

Compares two GSSName objects to determine whether they refer to the
same entity. This method may throw a GSSException when the names
cannot be compared. If either of the names represents an anonymous
entity, the method will return "false".

Parameters:

another GSSName object to compare with.

6.2.4. equals

public boolean equals(Object another)

A variation of the equals method described in 6.2.3 that is provided
to override the Object.equals() method that the implementing class
will inherit. The behavior is exactly the same as that in 6.2.3
except that no GSSException is thrown; instead, false will be
returned in the situation where an error occurs. (Note that the Java
language specification requires that two objects that are equal
according to the equals(Object) method must return the same integer
result when the hashCode() method is called on them.)

Parameters:

another GSSName object to compare with.

6.2.5. canonicalize

public GSSName canonicalize(Oid mech) throws GSSException

Creates a mechanism name (MN) from an arbitrary internal name. This
is equivalent to using the factory methods described in 6.1.9 or
6.1.10 that take the mechanism name as one of their parameters.

Parameters:

mech The oid for the mechanism for which the canonical form
of the name is requested.

6.2.6. export

public byte[] export() throws GSSException

Returns a canonical contiguous byte representation of a mechanism
name (MN), suitable for direct, byte by byte comparison by
authorization functions. If the name is not an MN, implementations
may throw a GSSException with the NAME_NOT_MN status code. If an
implementation chooses not to throw an exception, it should use some
system specific default mechanism to canonicalize the name and then
export it. The format of the header of the output buffer is
specified in RFC2743.

6.2.7. toString

public String toString()

Returns a textual representation of the GSSName object. To retrieve
the printed name format, which determines the syntax of the returned
string, the getStringNameType method can be used.

6.2.8. getStringNameType

public Oid getStringNameType() throws GSSException

Returns the oid representing the type of name returned through the
toString method. Using this oid, the syntax of the printable name
can be determined.

6.2.9. isAnonymous

public boolean isAnonymous()

Tests if this name object represents an anonymous entity. Returns
"true" if this is an anonymous name.

6.2.10. isMN

public boolean isMN()

Tests if this name object contains only one mechanism element and is
thus a mechanism name as defined by RFC2743.

6.3. public interface GSSCredential implements Cloneable

This interface encapsulates the GSS-API credentials for an entity. A
credential contains all the necessary cryptographic information to
enable the creation of a context on behalf of the entity that it

represents. It may contain multiple, distinct, mechanism specific
credential elements, each containing information for a specific
security mechanism, but all referring to the same entity.

A credential may be used to perform context initiation, acceptance,
or both.

GSS-API implementations must impose a local access-control policy on
callers to prevent unauthorized callers from acquiring credentials to
which they are not entitled. GSS-API credential creation is not
intended to provide a "login to the network" function, as such a
function would involve the creation of new credentials rather than
merely acquiring a handle to existing credentials. Such functions,
if required, should be defined in implementation-specific extensions
to the API.

If credential acquisition is time-consuming for a mechanism, the
mechanism may choose to delay the actual acquisition until the
credential is required (e.g. by GSSContext). Such mechanism-
specific implementation decisions should be invisible to the calling
application; thus the query methods immediately following the
creation of a credential object must return valid credential data,
and may therefore incur the overhead of a deferred credential
acquisition.

Applications will create a credential object passing the desired
parameters. The application can then use the query methods to obtain
specific information about the instantiated credential object
(equivalent to the gss_inquire routines). When the credential is no
longer needed, the application should call the dispose (equivalent to
gss_release_cred) method to release any resources held by the
credential object and to destroy any cryptographically sensitive
information.

Classes implementing this interface also implement the Cloneable
interface. This indicates the the class will support the clone()
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容