|
Préférences
Moteurs de recherche
|
|||||||||||||||||||||
JavaTM 2 Platform Std. Ed. v1.6.0
Package org.ietf.jgssThis 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:
Package org.ietf.jgss DescriptionThis 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 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 AcquisitionThe 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 Related DocumentationFor an online tutorial on using Java GSS-API, please see Introduction to JAAS and Java GSS-API.
Copyright 2003 Sun Microsystems, Inc. All rights reserved
|