0N/A<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
0N/A<html>
0N/A<head>
0N/A<!--
2362N/ACopyright (c) 2000, 2006, Oracle and/or its affiliates. All rights reserved.
0N/ADO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
0N/A
0N/AThis code is free software; you can redistribute it and/or modify it
0N/Aunder the terms of the GNU General Public License version 2 only, as
2362N/Apublished by the Free Software Foundation. Oracle designates this
0N/Aparticular file as subject to the "Classpath" exception as provided
2362N/Aby Oracle in the LICENSE file that accompanied this code.
0N/A
0N/AThis code is distributed in the hope that it will be useful, but WITHOUT
0N/AANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
0N/AFITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
0N/Aversion 2 for more details (a copy is included in the LICENSE file that
0N/Aaccompanied this code).
0N/A
0N/AYou should have received a copy of the GNU General Public License version
0N/A2 along with this work; if not, write to the Free Software Foundation,
0N/AInc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
0N/A
2365N/APlease contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
2365N/Aor visit www.oracle.com if you need additional information or have any
2365N/Aquestions.
0N/A-->
0N/A
0N/A</head>
0N/A<body bgcolor="white">
0N/A
0N/A This package presents a framework that allows application developers to
0N/A make use of security services like authentication, data integrity and
0N/A data confidentiality from a variety of underlying security mechanisms
0N/A like Kerberos, using a unified API. The security mechanisms that an
0N/A application can
0N/A chose to use are identified with unique object identifiers. One example
0N/A of such a mechanism is the Kerberos v5 GSS-API mechanism (object
0N/A identifier 1.2.840.113554.1.2.2). This mechanism is available through
0N/A the default instance of the GSSManager class.<p>
0N/A
0N/A The GSS-API is defined in a language independent way in
0N/A <a href=http://www.ietf.org/rfc/rfc2743.txt>RFC 2743</a>. The Java
0N/A language bindings are defined in
0N/A <a href=http://www.ietf.org/rfc/rfc2853.txt>RFC 2853</a><p>
0N/A
0N/A An application starts out by instantiating a <code>GSSManager</code>
0N/A which then serves as a factory for a security context. An application
0N/A can use specific principal names and credentials that are also created
0N/A using the GSSManager; or it can instantiate a
0N/A context with system defaults. It then goes through a context
0N/A establishment loop. Once a context is established with the
0N/A peer, authentication is complete. Data protection such as integrity
0N/A and confidentiality can then be obtained from this context.<p>
0N/A
0N/A The GSS-API does not perform any communication with the peer. It merely
0N/A produces tokens that the application must somehow transport to the
0N/A other end.<p>
0N/A
0N/A<h3>Credential Acquisition</h3>
0N/A<a name=useSubjectCredsOnly>
0N/A The GSS-API itself does not dictate how an underlying mechanism
0N/A obtains the credentials that are needed for authentication. It is
0N/A assumed that prior to calling the GSS-API, these credentials are
0N/A obtained and stored in a location that the mechanism provider is
0N/A aware of. However, the default model in the Java platform will be
0N/A that mechanism providers must obtain credentials only from the private
0N/A or public credential sets associated with the
0N/A {@link javax.security.auth.Subject Subject} in the
0N/A current access control context. The Kerberos v5
0N/A mechanism will search for the required INITIATE and ACCEPT credentials
0N/A ({@link javax.security.auth.kerberos.KerberosTicket KerberosTicket} and
0N/A {@link javax.security.auth.kerberos.KerberosKey KerberosKey}) in
0N/A the private credential set where as some other mechanism might look
0N/A in the public set or in both. If the desired credential is not
0N/A present in the appropriate sets of the current Subject, the GSS-API
0N/A call must fail.<p>
0N/A
0N/A This model has the advantage that credential management
0N/A is simple and predictable from the applications point of view. An
0N/A application, given the right permissions, can purge the credentials in
0N/A the Subject or renew them using standard Java API's. If it purged
0N/A the credentials, it would be sure that the JGSS mechanism would fail,
0N/A or if it renewed a time based credential it would be sure that a JGSS
0N/A mechanism would succeed.<p>
0N/A
0N/A This model does require that a {@link
0N/A javax.security.auth.login JAAS login} be performed in order to
0N/A authenticate and populate a Subject that the JGSS mechnanism can later
0N/A utilize. However, applications have the ability to relax this
0N/A restiction by means of a system property:
0N/A <code>javax.security.auth.useSubjectCredsOnly</code>. By default
0N/A this system property will be assumed to be <code>true</code> (even when
0N/A it is unset) indicating that providers must only use the credentials
0N/A that are present in the current Subject. However, if this property is
0N/A explicitly set to false by the application, then it indicates that
0N/A the provider is free to use any credentials cache of its choice. Such
0N/A a credential cache might be a disk cache, an in-memory cache, or even
0N/A just the current Subject itself.
0N/A</a>
0N/A
0N/A<h2>Related Documentation</h2>
0N/A<p>
0N/AFor an online tutorial on using Java GSS-API, please see
0N/A<a href="/technotes/guides/security/jgss/tutorials/index.html">Introduction to JAAS and Java GSS-API</a>.
0N/A</p>
0N/A
0N/A<!--
0N/A<h2>Package Specification</h2>
0N/A
0N/A##### FILL IN ANY SPECS NEEDED BY JAVA COMPATIBILITY KIT #####
0N/A<ul>
0N/A <li><a href="">##### REFER TO ANY FRAMEMAKER SPECIFICATION HERE #####</a>
0N/A</ul>
0N/A
0N/A<h2>Related Documentation</h2>
0N/A
0N/AFor overviews, tutorials, examples, guides, and tool documentation, please see:
0N/A<ul>
0N/A <li><a href="">##### REFER TO NON-SPEC DOCUMENTATION HERE #####</a>
0N/A</ul>
0N/A
0N/A-->
0N/A
0N/A@since 1.4
0N/A</body>
0N/A</html>